Best software practices: architecture
Autor: Damian Chodorek • Opublikowany: 23 lutego 2019 • Ostatnia aktualizacja: 13 kwietnia 2019 • Kategoria: Good practices
Best architecture and design practices. Gathered from various sources.
- Architecture reflects organisational communication model, reverse is true.
- When teams aren’t aware of their architecture (don’t have the big picture), it tends to degrade.
- The goad of software architecture is to minimaze the human resources required to build and maintain the required system.
- The measure of design quality is the measure of effort required to meet the needs of the customer.
- SOLID – applies to method/class/module/service level
- Single responsibility principle – one should have only a single responsibility.
- Open/closed principle – open for extension, but closed for modification.
- Liskov substitution principle – one should be replaceable with instances of its subtype without altering the correctness of that program.
- Interface segregation principle – many client-specific interfaces are better than one general-purpose interface.
- Dependency inversion principle – one should depend upon abstractions, not concretions.
- Importance
- Composition over inheritance.
- Convention over configuration.
- Principle over practices.
- Simplicity over familiarity.
- Explicit over magic.
- Duplication over poor abstraction.
- Packaging principles
- Screaming Architecture – project structure should tell us very clearly what the system is about, not what framework is used.
- Go for High Cohesion (group items with functions that are similar in many aspects).
- Go for Low Coupling (a module is said to be loosely coupled if a module is independent of any other modules).
- The Release Reuse Equivalency Principle – the granule of reuse is the granule of release.
- The Common Closure Principle – classes that change together are packaged together.
- The Common Reuse Principle – classes that are used together are packaged together.
- The Acyclic Dependencies Principle – the dependency graph of packages must have no cycles.
- The Stable Dependencies Principle – depend in the direction of stability.
- The Stable Abstractions Principle – abstractness increases with stability.
- Separate
- Stable from unstable.
- Permanent from temporary.
- Synchronous from asynchronous.
- Similar from different.
- Symmetrical from asymmetrical.
- Construction from operation.
- Content from presentation.
- Easy from complex.
- Stateless from stateful.
- Application-level code from system-level code.
- Methods that read from methods that write.
- One from Many, Many from Many.
- Scalability
- DRY
- YAGNI – don’t write code until you actually need it, and remove any code that isn’t being used.
- Ignorance limits on ability of a software to scale.
- Good enough for each part is often best for the whole system.
- Group together things that change at the same time for the same reasons.
- Legacy code is a code without tests.
- Adopt „fits in my head” principle.
- Smaller is not necessarily better, more replaceable is better.
- Be only as generic as you know you need to be right now.
- Restrict the scope of data to the smallest possible
- Complexity is a prison; simplicity is freedom.