Every project had its own build script and produced a JAR file that was a dependency of at least a half-dozen or so other projects. I worked at a company once with about twenty developers and more than sixty different active projects in the SVN repository. This is one of the symptoms of over-modularization.
Are circular references between projects really a big deal or am I blowing it out of proportion? This seems like a situation that should be avoided, but not a situation that poses any appreciable threat.
The binaries aren't stored in version control at any point, which only makes me more worried. That argument falls a little flat to the "practical" people I work with since it seems highly unlikely that we will lose all copies of our binaries simultaneously. This seems like a very bad practice to me because there is no way to build either project from source without having the DLLs first. This has led to at least one circular reference in the codebase that has gone unnoticed for over 3 years. Visual Studio is perfectly happy to let you do this, but now the source won't compile as-is without one of the binaries.Īt my place of work it is standard procedure to copy-and-paste binaries when doing development and then only building the projects you're working on. Then, some time later, someone decides that they want the Utilities class to send an e-mail and adds a reference to Email.dll. Instead of adding both projects to a single solution, a new solution is created and a reference to Utilities.dll is added. Then, an E-mail class is created that depends on Utilities.
CIRCULAR STUDIO 2.5 CODE
Why are circular references in Visual Studio a bad practice?įirst, I will describe an example of how this can happen using C# in Visual Studio, since VS will typically inform you if you have a circular reference and prevent it.įirst, a Utilities class is created relying only on the code given to you by Visual Studio and.
0 kommentar(er)
