More on this book
Community
Kindle Notes & Highlights
Processor speed and network bandwidth can deliver a harsh verdict on a system’s performance.
Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change.
If you think good architecture is expensive, try bad architecture.
The only way to go fast, is to go well.
The architecture rules are the same!
The code just hasn’t changed that much.
The rules of software architecture are the rules of ordering and assembling the building blocks of programs.
It doesn’t take a huge amount of knowledge and skill to get a program working.
Getting software right is hard.
When software is done right, it requires a fraction of the human resources to create and maintain.
It is far more common to fight your way through terrible software designs than it is to enjoy the pleasure of working with a good one.
The low-level details and the high-level structure are all part of the same whole.
The goal of software architecture is to minimize the human resources required to build and maintain the required system.
The measure of design quality is simply the measure of the effort required to meet the needs of the customer.
Most modern developers work their butts off.
Of course, things never do get cleaned up later, because market pressures never abate.
Just as the Hare was overconfident in its speed, so the developers are overconfident in their ability to remain productive.
The bigger lie that developers buy into is the notion that writing messy code makes them go fast in the short term, and just slows them down in the long term.
The fact is that making messes is always slower than staying clean, no matter which time scale you are using.
The only way to go fast, is to go well.
To take software architecture seriously, you need to know what good software architecture is.
Every software system provides two different values to the stakeholders: behavior and structure.
To fulfill its purpose, software must be soft—that is, it must be easy to change.
I have two kinds of problems, the urgent and the important. The urgent are not important, and the important are never urgent.
Those things that are urgent are rarely of great importance, and those things that are important are seldom of great urgency.
The first value of software—behavior—is urgent but not always particularly important.
The second value of software—architecture—is important but never ...
This highlight has been truncated due to consecutive passage length restrictions.
Software architects are, by virtue of their job description, more focused on the structure of the system than on its features and functions.
Paradigms are ways of programming, relatively unrelated to languages.
Structured programming imposes discipline on direct transfer of control.
Object-oriented programming imposes discipline on indirect transfer of control.
Functional programming imposes discipline upon assignment.
The paradigms tell us what not to do, more than they tell us what to do.
Science does not work by proving statements true, but rather by proving statements false.
Those statements that we cannot prove false, after much effort, we deem to be true enough for our purposes.
Ultimately, we can say that mathematics is the discipline of proving provable statements true. Science, in contrast, is the discipline of proving provable statements false.
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. All that tests can do, after sufficient testing effort, is allow us to deem a program to be correct enough for our purposes.
The reason encapsulation is cited as part of the definition of OO is that OO languages provide easy and effective encapsulation of data and function.
OO certainly does depend on the idea that programmers are well-behaved enough to not circumvent encapsulated data.
Inheritance is simply the redeclaration of a group of variables and functions within an enclosing scope.
It’s fair to say that while OO languages did not give us something completely brand new, it did make the masquerading of data structures significantly more convenient.
The bottom line is that polymorphism is an application of pointers to functions.
OO languages may not have given us polymorphism, but they have made it much safer and much more convenient.
The problem with explicitly using pointers to functions to create polymorphic behavior is that pointers to functions are dangerous.
The fact that OO languages provide safe and convenient polymorphism means that any source code dependency, no matter where it is, can be inverted.
If the modules in your system can be deployed independently, then they can be developed independently by different teams. That’s independent developability.
OO is the ability, through the use of polymorphism, to gain absolute control over every source code dependency in the system. It allows the architect to create a plugin architecture, in which modules that contain high-level policies are independent of modules that contain low-level details.
The low-level details are relegated to plugin modules that can be deployed and developed independently from the modules that contain high-level policies.
Variables in functional languages do not vary.
All race conditions, deadlock conditions, and concurrent update problems are due to mutable variables.
