Quotes from Robert C. Martin

Nothing has a more profound and long-term degrading effect upon a development project than bad code. Bad schedules can be redone, bad requirements can be redefined. Bad team dynamics can be repaired. But bad code rots and ferments, becoming an inexorable weight that drags the team down.

WHICH LINES DO YOU DRAW, AND WHEN DO YOU DRAW THEM? You draw lines between things that matter and things that don't. The GUI doesn't matter to the business rules, so there should be a line between them. The database doesn't matter to the GUI, so there should be a line between them. The database doesn't matter to the business rules, so there should be a line between them.

There is no such thing as quick and dirty. Anything dirty is slow. The only way to go fast, is to go well.

Implementation Patterns.

We in this industry sorely need to increase our professionalism. We fail too often. We ship too much crap. We accept too many defects. We make terrible trade-offs. Too often, we behave like unruly teenagers with a new credit card. Martin, Robert C.. Clean Agile (Robert C. Martin Series) . Pearson Education. Kindle Edition.

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.

Software is a compound word. The word "ware" means "product." The word "soft" means easy to change. Therefore, software is a product that is easy to change. Software was invented because we wanted a way to quickly and easily change the behavior of our machines. Had we wanted that behavior to be hard to change, we would have called it hardware.

Agile is a process wherein a project is subdivided into iterations. The output of each iteration is measured and used to continuously evaluate the schedule. Features are implemented in the order of business value so that the most valuable things are implemented first. Quality is kept as high as possible. The schedule is primarily managed by manipulating scope.

Try to write tests that force exceptions, and then add behavior to your handler to satisfy your tests. This will cause you to build the transaction scope of the try block first and will help you maintain the transaction nature of that scope.

In fact, component dependency diagrams have very little do to with describing the function of the application. Instead, they are a map to the buildability and maintainability of the application.

If we tried to design the component dependency structure before we designed any classes, we would likely fail rather badly. We would not know much about common closure, we would be unaware of any reusable elements, and we would almost certainly create components that produced dependency cycles.

the history of software development technology is the story of how to conveniently create plugins to establish a scalable and maintainable system architecture.

You should be able to run all the unit tests with just one command.

Professional developers do not prevent others from working in the code. They do not build walls of ownership around code. Rather, they work with each other on as much of the system as they can. They learn from each other by working with each other on other parts of the system.

Arranging our systems into a plugin architecture creates firewalls across which changes cannot propagate. If the GUI plugs in to the business rules, then changes in the GUI cannot affect those business rules.

The most efficient and effective way to review code is to collaborate in writing it.

Professionals work together. You can't work together while you are sitting in corners wearing headphones. So I want you sitting around tables facing each other. I want you to be able to smell each other's fear. I want you to be able to overhear someone's frustrated mutterings. I want serendipitous communication, both verbal and body language. I want you communicating as a unit.

QA and Acceptance Tests If QA has not already begun to write the automated acceptance tests, they should start as soon as the IPM ends. The tests for stories that are scheduled for early completion should be done early. We don't want completed stories waiting for acceptance tests to be written.

If a component contains software that should be reused, it should not also contain software that is not designed for reuse. Either all the classes in a component are reusable, or none of them are.

Resisting premature abstraction is as important as abstraction itself.

The tests fit the production code like an antibody fits an antigen.

CRP says that classes that are not tightly bound to each other with class relationships should not be in the same component.

the fact that oo languages provide safe and convenient polymorphism means that any source code dependency, no matter where it is, can be inverted

Procedural code (code using data structures) makes it easy to add new functions without changing the existing data structures. OO code, on the other hand, makes it easy to add new classes without changing existing functions.