You know the software is rotting when it starts to exhibit any of the following odors:
Rigidity – The system is hard to change because every change forces many other changes to other parts of the system.
Fragility – Changes cause the system to break in places that have no conceptual relationship to the part that was changed.
Immobility – It is hard to disentangle the system into components that can be reused in the other systems.
Viscosity – Doing things right is harder than doing things wrong. Needless Complexity – The design contains infrastructure that adds no direct benefit.
Needless Repetition – The design contains repeating structures that could be unified under a single abstraction.
Opacity – It is hard to read and understand. It does not express its intent well
Simple Design
Extreme Programming's principle of Simple Design, in order of importance:
- Runs all the tests
- Contains no duplication
- Expresses the intent of the programmer
- Minimizes the number of classes and methods
Truly agile teams don't allow the software to rot:
- Keeping the design clean and simple at all times is the only way to go fast. It makes the design flexible and easy to change.
- Making a mess will always slow you down the next time that you need to read or change the same code.
Architecture
"Architecture is about the important stuff. Whatever that is."
"Architecture is the decisions that you wish you could get right early in a project."
Why do people feel the need to get some things right early in the project?
The answer, of course, is because they perceive those things as hard to change. So you might end up defining architecture as “things that people perceive as hard to change”.
- Big Design Up Front (BDUF), i.e. spinning system designs based on untested hypotheses for many months, is harmful.
- BDUF inhibits adapting to change.
- Little/Enough Design Up Front (LDUF/EDUF) is good.
- With a big project spending a week or even a month thinking about the important things is nothing wrong.
- Agile was a response to BDUF, but not DUF.
- Far from “design nothing,” the XP strategy is “design always.”
- Whatever designs have been done up front, they should always be open for change.
- Let the tests drive the system architecture.
Principles of Modular Design
Cohesion – higher is better
- Cohesion is a measure of how strongly-related or focused the responsibilities of a single module are.
Coupling – lower is better
- Coupling or dependency is the degree to which each program module relies on each one of the other modules.
SOLID Principles
- SRP: Single Responsibility Principle
- OCP: Open Closed Principle
- LSP: Liskov Substitution Principle
- ISP: Interface Segregation Principle
- DIP: Dependency Inversion Principle
(to be continued...)
No comments:
Post a Comment