100 software-concepts
YAGNI - You ain’t gonna Need it
Don't create things you might need in the future
DRY - Don’t repeat yourself
Encapsulate logic and reuse it
KISS - Keep it simple stupid
Don't overcomplicate things
FCol - Favour Composition over Inheritance
It's better to compose a class instead of inherit from others.
SLA - Single level of abstraction
There are different degrees of abstraction. Those Abstractions at he same degree should be on the same level. Don't mix them with higher or lower abstractions.
TDA – Tell, Don’t Ask
We should bundle the data and the logic, that works upon that data. In OO you tell a methode what to do, instead of asking for their data.
CRC - cards
An approach to collect all the Domain entities, to understand a system, before you start the project.
Avoid Deep Nesting
Don't nest things too much
Fail Fast
Figure out failures as soon as possible
Don’t Mock What You Don’t Own
Only mock the things where you the owner
Information hiding principle
Encapsulate complex logic in Objects
Law of Demeter
Just speak to closely related objects. Don't access sub-sub-sub-objects directly.
Avoid premature optimization
Don't optimize for the future
Root cause analysis
Find always the source of a problem
Boy scout Rule
Leave the code cleaner than you find it
Holywood Principle
Don't call us, we call you. High level objects call low level objects, not the other way around.
SOLID
Acronym for fundamental software principles.
Seraration of concerns
Separate a system into distinctive components
Open close principle
Open for extension, closed for changes
Liskov substitution principle
all subclasses should be substitutable for their base classes
Interface segregation principle
Keep interfaces as small as possible
Dependency inversion principle
High level should not depend on low-level objects (concretions) but on abstractions (like interfaces)
Reuse-Release-Equivalence principle
CCP - Common-Closure principle
CRP - Common-Reuse principle
ADP - Acyclic-Dependencies Principle
SDP - Stable-Dependencies principle
SAP - Stable-Abstract principle
GRASP – General Responsibility Assignment Software Patterns
High Cohesion, Low Coupling
Inversion of Control (IoC)
Framework calls a system-methode not the other way around. (Hollywood Principle)
Hexagonal Architecture / Ports & Adapters
Clean Architecture
A Guideline how to develop clean code
CQRS – Command Query Responsibility Segregation
You Build It, You Run It
A team that creates a software is responsible for its operation and maintenance.
Trunk-based Development
Test Pyramid
Red-Green-Refactor
Principle of Least Surprise
POLA - Principle of Least Astonishment
Make Illegal States Unrepresentable
Code is Communication
Principle of Least Privilege
Encapsulation Principle
Immutability Principle
Design for Extensibility
Zero One Infinity Rule
Don't Break the Chain
90/10 Rule (Pareto-principle)
Occam’s Razor
Postel’s Law (Robustness Principle)
Be strikt waht you do, be open what you accept from others
Chesterton's Fence
Murphy’s Law
Things that can fail, will fail
Hick’s Law
The time a person needs for something, grows expontially with the number of available options
Fitts’s Law
Miller’s Law
CAP-Theorem
Conway’s Law
The system design of a company reflects the communication-structure in this company
Reactive Manifesto
Build-Measure-Learn (Lean Startup)
Fast Feedback
Working Software over Comprehensive Documentation
Shannon’s Informationstheorie
Fail-Safe vs. Safe-Fail
MVC - Model View Controller
MVP - Model View Presenter
Hexagonal Architecture - Ports and Adapters
Onion Architecture
Layered Architecture
Event Sourcing
DDD - Domain Driven Design
TDD - Test Driven Design
BDD - Behaviour Driven Design
Microservice Architecture
CQRS - Command Query Responsibility Segregation
Design Patterns
Reusable patterns in software design
SOA - Service Oriented Architecture
ECS - Entity Component System
Blackboard Architecture
Shared Nothing Architecture
Shared Disc Architecture
SDLC - System Design Lifecycle
Nested Sets
A technique to represent trees in relational databases
Convention over Configuration
Design by Contract
Refactor Mercilessly
SSOT - Single Source of Truth
There should be just a single source for the ground truth
Design for failure
Always assume that something will fail. Design your system to handle unexpected failures.
Immutable Infrastructure
IaC - Infrastructure as Code
Twelve Factor App
Elasticity vs. Scalability
Microkernel Architecture
Pipes and Filters
Architectur, where data is preocessed through a chain of filters
Component Cohesion
Canary Releases
Cyclomatic Complexity (McCybe metric)
Measures the complexity of a method
Bus Factor
What if just a single person who understands the code, is run over by a bus?
Code Ownership Models
Code Smells
Bad designed code stinks
Dependency Injection
dependencies are injected into methods
Fire and Forget