Best software practices: architecture

Autor: Damian Chodorek • Opublikowany: 23 lutego 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.

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany.