Software Design
Investment in software design
The idea that investment in software design early and often reduces delivery speed early on, but there is a turning point where delivery speed becomes faster than that with no design.
bliki: DesignStaminaHypothesis
Is High Quality Software Worth the Cost?
The idea that people (often non-technical people) incorrectly apply the tradeable quality hypothesis to software. Here, a distinction is made between external and internal quality.
External quality being quality that can be perceived by the customers of a system, e.g. user-friendliness of the UI.
Internal quality is quality that cannot be perceived by the customers, often relating to the internal design and robustness of a system.
The crux of the issue is that this conflation of quality implies that we can trade off internal quality for pace of delivery. Which is in contrast to the design stamina hypothesis.
bliki: TradableQualityHypothesis
bliki: CannotMeasureProductivity
Object-oriented design
Core Principles
- Tell, Don’t Ask - Tell objects what to do rather than querying state
- Law of Demeter - Encapsulation and data hiding
OO antipatterns
C2 Wiki - Classic OO Anti-patterns
Indirection
C2 Wiki - One More Level of Indirection
Refactoring
Commit notation for signalling the type of change, and perceived risk.
https://github.com/RefactoringCombos/ArlosCommitNotation
Techniques for refactoring when you don’t understand the code
- ENOF (Easiest Nearest Owwie First) - Narrow your focus and fix the easiest unclear thing first
- Defactoring - Inline then extract with better understanding
SOLID
SOLID Principles - Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, Dependency Inversion. Understanding these principles in terms of class invariants.
Composition over inheritance
Composition over Inheritance - Favor “has-a” relationships over “is-a” relationships for flexibility and loose coupling
Invariants
Simple design
YAGNI (You Aren’t Gonna Need It) - Build only what you need now, not speculative features
Kent Beck’s design rules
In XPE Kent gives four criteria for a simple system. In order (most important first):
- Runs all the tests
- No duplication
- Reveals all the intention
- Fewest number of classes or methods
Be messy, but clean up
The trick really boils down to: be messy, but clean up. If you don’t do the seco… | Hacker News
Prefer pure functions
Pure Functions
A pure function only looks at the parameters passed in to it, and all it does is return one or more computed values based on the parameters. It has no logical side effects. This is an abstraction of course; every function has side effects at the CPU level, and most at the heap level, but the abstraction is still valuable. It doesn’t look at or update global state. it doesn’t maintain internal state. It doesn’t perform any IO. it doesn’t mutate any of the input parameters. Ideally, it isn’t passed any extraneous data – getting an allMyGlobals pointer passed in defeats much of the purpose. Pure functions have a lot of nice properties. Thread safety. A pure function with value parameters is completely thread safe.
See also: — Functional Core, Imperative Shell —
Modules should be deep
Learning an interface should save you work, not cost you work.
Along the same lines as my “abstractions need to just justify their existence” thought.
Write less code
The Best Code is No Code At All
Domain Driven Design
Domain services vs Application services
Implementing Domain-Driven Design
DRY (Don’t Repeat Yourself)
DRY (Don’t Repeat Yourself) - About knowledge duplication, not code duplication. Apply the Rule of Three and avoid hasty abstractions (AHA).
Convention over configuration
Convention over configuration (also known as coding by convention) is a software design paradigm used by software frameworks that attempts to decrease the number of decisions that a developer using the framework is required to make without necessarily losing flexibility and don’t repeat yourself (DRY) principles.