More on this book
Community
Kindle Notes & Highlights
Read between
May 19 - June 11, 2019
A good architecture comes from understanding it more as a journey than as a destination, more as an ongoing process of enquiry than as a frozen artifact.
The only way to go fast, is to go well. —Robert C. Martin
When software is done right, it requires a fraction of the human resources to create and maintain. Changes are simple and rapid. Defects are few and far between. Effort is minimized, and functionality and flexibility are maximized.
Tortoise and the Hare.
“Slow and steady wins the race.” • “The race is not to the swift, nor the battle to the strong.” • “The more haste, the less speed.”
These developers buy into a familiar lie: “We can clean it up later; we just have to get to market first!” Of course, things never do get cleaned up later, because market pressures never abate.
And so the developers never switch modes. They can’t go back and clean things up because they’ve got to get the next feature done, and the next, and the next, and the next.
The fact is that making messes is always slower than staying clean, no matter which time scale you are using.
The developers may think that the answer is to start over from scratch and redesign the whole system—but that’s just the Hare talking again.
Their overconfidence will drive the redesign into the same mess as the original project.
The dilemma for software developers is that business managers are not equipped to evaluate the importance of architecture.
This!
Therefore it is the responsibility of the software development team to assert the importance of architecture over the urgency of features.
This!
FIGHT FOR THE ARC...
This highlight has been truncated due to consecutive passage length restrictions.
The development team has to struggle for what they believe to be best for the company, and so do the management team, and the marketing team, and the sales team, and the operations team. It’s always a struggle.
Effective software development teams tackle that struggle head on. They unabashedly squabble with all the other stakeholders as equals. Remember, as a software developer, you are a stakeholder.
Dijkstra once said, “Testing shows the presence, not the absence, of bugs.” In other words, a program can be proven incorrect by a test, but it cannot be proven correct.
Single Responsibility Principle
Conway’s law:
The best structure for a software system is heavily influenced by the social structure of the organization that uses it so that each software module has one, and only one, reason to change.
Open-Closed Principle
Bertrand Meyer
software systems to be easy to change, they must be designed to allow the behavior of those systems to be changed by adding new code...
This highlight has been truncated due to consecutive passage length restrictions.
Liskov Substitution Principle
Barbara Liskov’s
Interface Segregation Principle
software designers to avoid depending on things that they don’t use.
Dependency Inversion Principle
The code that implements high-level policy should not depend on the code that implements low-level details. Rather, details should depend on policies.
A module should have one, and only one, reason to change.
Software systems are changed to satisfy users and stakeholders; those users and stakeholders are the “reason to change”
A module should be responsible to one, and only one, actor.
That word “cohesive” implies the SRP. Cohesion is the force that binds together the code responsible to a single actor.
SYMPTOM 1: ACCIDENTAL DUPLICATION
SYMPTOM 2: MERGES
A software artifact should be open for extension but closed for modification.
if simple extensions to the requirements force massive changes to the software, then the architects of that software system have engaged in a spectacular failure.
Excessive tests maintenance is a symptom of violation of this principle?
All the other components are dealing with peripheral concerns. The Interactor deals with the central concern.
Barbara Liskov, “Data Abstraction and Hierarchy,” SIGPLAN Notices 23, 5 (May 1988).
This is the primary reason that dynamically typed languages create systems that are more flexible and less tightly coupled than statically typed languages.
We tolerate those concrete dependencies because we know we can rely on them not to change.
It is the volatile concrete elements of our system that we want to avoid depending on. Those are the modules that we are actively developing, and that are undergoing frequent change.
How we can know before hand what component is stable enough ?
It also puts severe constraints on the creation of objects and generally enforces the use of Abstract Factories.
Or injecting dependencies?
Don’t force users of a component to depend on things they don’t need.
Node.js npm libraries violates this?
For example, early in the development of a project, the CCP is much more important than the REP, because develop-ability is more important than reuse.
Depend in the direction of stability.
Stand a penny on its side. Is it stable in that position? You would likely say “no.” However, unless disturbed, it will remain in that position for a very long time. Thus stability has nothing directly to do with frequency of change.
Stability is related to the amount of work required to make a change.
I = Fan-out / (Fan-in + Fan-out).
s/,/\//
The SDP says that the I metric of a component should be larger than the I metrics of the components that it depends on. That is, I metrics should decrease in the direction of dependency.
