Best software practices: architecture

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.