A few cheat codes and tips from experienced Software Architects

 Having clean software architecture and staying conform to pre-defined design principles from start of the project is one of the best ways to avoid possible technical debt in the future of that software system. Clean Software Design is a key point for an effective software product.

Let us have a look at some important principles, rules, guidelines that ensure a clean software design:

Principles:

1. Loose Coupling — if classes use each other, they are coupled together. The less classes are coupled, the easier is to change them.
2. High Cohesion — degree to which elements of a whole belong together. Components of the class should be highly cohesive.
3. Locality — Changes, maintenance, extensions are only local. This leads to no harming whole environment.
4. Removeable — Software Components should be easily removeable.
5. Small Components — software system should be only of small components ideally each doing only one task.

Class Design:

1. Single Responsibility Principle (SRP) — class should do only one task.
2. Open Closed Principle (OCP) — class should be extended not modified.
3. Liskov Substitution Principle (LSP) — child classes must be able to replace their super classes.
4. Dependency Inversion Principle (DIP) — dependeny is reversed: high level components are free of low-level components.
5. Interface Segregation Principle (ISP) — interfaces should be small: classes should not implement unnecessary methods.

Cohesion Principles:

1. Release Reuse Equivalency Principle (RREP) — only together releaseable components should be bundled together.
2. Common Closure Principle (CCP) — classes that change together should be bundled together.
3. Common Reuse Principle (CRP) — classes that are used together should be bundled together.

Coupling Principles:

1. Acyclic Dependencies Principle (ADP) — no dependency cycles.
2. Stable Dependencies Principle (SDP) — depend on direction of stability.
3. Stable Abstractions Principle (SAP) — the more abstract, the more stable.

High-Level Architecture:

1. Keep Configurable Data at High Levels — constants or config datas should be kept in high level.
2. Don’t Be Inconsistent— have a convention, principle, rule or guidelines and always follow them.
3. Prefer Polymorphism To If/Else or Switch/Case.
4. Separate Multi-Threading Code — isolate multi-thread from rest of the code.
5. Only one level of Abstraction per layer — stay conform to existing abstraction layers.
6. Fields Not Defining State — fields holding data that does not belong to the state of the instance but are to hold temporary data. Use local variables or extract to a class abstracting the performed action.
7. Micro Layers — avoid unnecessary design layers.
8. Singletons / Service Locator — Make use of dependency injection.
9. Base Classes Depending On Their Derivatives — Base classes should work with any derived class.
10. Feature Envy — The methods of a class should be interested in the variables and functions of the class they belong to, and not the variables and functions of other classes. Using accessors and mutators of some other object to manipulate its data, is envying the scope of the other object ©.
11. Unused Coupling — avoid unused dependencies, be greedy.
12. Hidden Coupling — make sure that order of calls to different methods are correct.
13. Transitive Navigation — (Law of Demeter), write isolated code. Classes should have access to only its direct dependencies.

Environment:

1. Project Build Requires Only One Step.
2. Executing Tests Requires Only One Step.
3. Source Control System — Always use a source control system.
4. Continuous Integration — Assure integrity with Continuous Integration.
5. Overridden Logs— Do not override warnings, errors, exception handling