With modern tools, Is a solution\project structure important?

In the post I would like to discuss importance of the solution (project) structure nowadays. So, is it really so important to create and maintain a well structured solution when you have such a powerful IDE like VS.NET and a ReSharper plugin installed. ReSharper for sure improves development work and minimizes development effort. I‘ve seen number of times people saying that project structure is not important because such tool as ReSharper allows you to easily: navigate thru solution, project, classes ect… refactor code with no pain without knowing where the classes are used, find any class, .dll, usages, inheritor, base… within entire solution, and many, many other cool things… even it will purpose to add a .dll reference if a class is in another project.

 OK... VS.NET + ReSharper are powerful... but that is enough?

 Let’s see… for small business projects in mostly cases importance of a good solution\project structure is not high, because there will not be a very big gain from that structure, same is for design decisions, tool set etc...  

For large projects “ReSharper shortcuts” are not enough. Why?

 Because it can help but it can’t do for you:

  • correctly define number of libraries and granularity
  •  correctly define references(dependencies) between libraries
  •  devise classes in namespaces - create intuitive folder structure
  •  say where fits new class\interface\enum\etc. and how to name it
  •  create project structure conventions (e.g. naming convention)
  •  define a big picture
  •  etc.

enumerated above statements are very important for a larger projects. A correctly set project structure can say a story about the project: where it is now and what future of the project is. By future of the project I mean that is more predictable. Change impact and major changes will more transparent. Self explanatory project structure is very important, not only for beginners in a project but also for persons that works for a module\project\layer separately. It will allow easily decide changes, reuse, and share common language within team members. Most of the development time we “read “ code\module\layer, so in some stage of a project “write” time begins to depends on “read” time, good project structure allows to concentrate only on one thing at a time, decrease “read” time. Code responsibilities are more visible and more isolated(less dependent), increasing reusability.

If a project structure doesn’t say anything about the project or you don’t know where to fit new peace of code then it’s a sign that is something wrong, in this case project should be refactored. Project structure is like a piece of code that should be refactored when it doesn’t meet his needs, Yes, it is not so easy… but is easier to spend hours\days on things that should take considerably less effort?

For small project, project structure it’s not so important, main purpose of small projects is not maintenance but is to finish it quickly and often dirty. As opposite, for large projects any decision is more important and its consequences are more visible, these decisions are reflected in maintenance time, nowadays maintenance is a key for large long term projects. So, project structure is high-level description of a project that has more value for large projects, because it can reduce maintenance costs.

I will not discuss “How to define a project structure” because it is not purpose of the post but I will point to set of principles that can help you to organize a correct project structure, so there a few general principles which are overlooked behind S.O.L.I.D. principles:

1) The Reuse/Release Equivalence Principle (REP) - THE GRANULE OF REUSE IS THE GRANULE OF RELEASE. ONLY COMPONENTS THAT ARE RELEASED THROUGH A TRACKING SYSTEM CAN BE FFECTIVELY REUSED. THIS GRANULE IS THE PACKAGE.

2) The Common Reuse Principle (CRP) - THE CLASSES IN A PACKAGE ARE REUSED TOGETHER. IF YOU REUSE ONE OF THE CLASSES IN A PACKAGE, YOU REUSE THEM ALL.

3) The Common Closure Principle (CCP) - THE CLASSES IN A PACKAGE SHOULD BE CLOSED TOGETHER AGAINST THE SAME KINDS OF CHANGES. A CHANGE THAT AFFECTS A PACKAGE AFFECTS ALL THE CLASSES IN THAT PACKAGE.

4) The Acyclic Dependencies Principle (ADP) - THE DEPENDENCY STRUCTURE BETWEEN PACKAGES MUST BE A DIRECTED ACYCLIC GRAPH (DAG). THAT IS, THERE MUST BE NO CYCLES IN THE DEPENDENCY STRUCTURE.

5) The Stable Dependencies Principle (SDP) - THE DEPENDENCIES BETWEEN PACKAGES IN A DESIGN SHOULD BE IN THE DIRECTION OF THE STABILITY OF THE PACKAGES. A PACKAGE SHOULD ONLY DEPEND UPON PACKAGES THAT ARE MORE STABLE THAT IT IS.

6) The Stable Abstractions Principle (SAP) - PACKAGES THAT ARE MAXIMALLY STABLE SHOULD BE MAXIMALLY ABSTRACT. INSTABLE PACKAGES SHOULD BE CONCRETE. THE ABSTRACTION OF A PACKAGE SHOULD BE IN PROPORTION TO ITS STABILITY.

All the principles can be found here. However, SOLID principles also could be applied for a solution\project structure. Last two principles are described in more details here.

Conclusion

Organizing a project structure we define its: modularity, dependencies, common language, conventions, cohesion level, first face of the application, etc.. how a tool can replace it? It can only help…

 

Thank you,

Artur Trosin

No Comments