Quotes About Software

That's being attentive to every variable name. You should name a variable using the same care with which you name a first-born child.

Regardless of how they are eventually deployed, well-designed components always retain the ability to be independently deployable and, therefore, independently developable.

SRP: The Single Responsibility Principle An active corollary to 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.

LSP: The Liskov Substitution Principle Barbara Liskov's famous definition of subtypes, from 1988. In short, this principle says that to build software systems from interchangeable parts, those parts must adhere to a contract that allows those parts to be substituted one for another.

software artifact should be open for extension but closed for modification.

ISP: The Interface Segregation Principle This principle advises software designers to avoid depending on things that they don't use.

DIP: The 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.

Don't hide side effects with a name. Don't use a simple verb to describe a function that does more than just that simple action.

dynamically linked files, which can be plugged together at runtime, are the software components of our architectures.

So, when and why should we use UML? Diagrams are most useful for communicating with others and for helping you work out design problems.

The Reuse/Release Equivalence Principle (REP) is a principle that seems obvious, at least in hindsight. People who want to reuse software components cannot, and will not, do so unless those components are tracked through a release process and are given release numbers.

Classes and modules that are grouped together into a component should be releasable together. The fact that they share the same version number and the same release tracking, and are included under the same release documentation, should make sense both to the author and to the users.

The architecture of a software system is the shape given to that system by those who build it. The form of that shape is in the division of that system into components, the arrangement of those components, and the ways in which those components communicate with each other.

The Open-Closed Principle (OCP) was coined in 1988 by Bertrand Meyer.1 It says: A software artifact should be open for extension but closed for modification.

Am I suggesting 100% test coverage? No, I'm not suggesting it. I'm demanding it. Every single line of code that you write should be tested. Period. Isn't that unrealistic? Of course not. You only write code because you expect it to get executed. If you expect it to get executed, you ought to know that it works. The only way to know this is to test it.

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.

Part of the art of developing a software architecture is carefully separating those policies from one another, and regrouping them based on the ways that they change.

software has two types of value: the value of its behavior and the value of its structure.

THE ACYCLIC DEPENDENCIES PRINCIPLE Allow no cycles in the component dependency graph.

Transitive dependencies are a violation of the general principle that software entities should not depend on things they don't directly use. We'll encounter that principle again when we talk about the Interface Segregation Principle and the Common Reuse Principle.

O objetivo da arquitetura de software é minimizar os recursos humanos necessários para construir e manter um determinado sistema.

I used to think 2000 lines was a big program. After all, it was a full box of cards that weighed 10 pounds. Now, however, a program isn't really big until it exceeds 100,000 lines.

It doesn't take a huge amount of knowledge and skill to get a program working. Kids in high school do it all the time. Getting it right is another matter entirely. When software is done right, it requires a fraction of the human resources to create and maintain.

THE STABLE DEPENDENCIES PRINCIPLE Depend in the direction of stability.