Agile Principles, Patterns, and Practices in C# (Robert C. Martin Series)

by Micah Martin

Nothing focuses requirements better than seeing the nascent system come to life.

When you write code in order to make test cases pass, that code is by definition testable. What’s more, there is a strong motivation to decouple modules so that they can be tested independently. Thus, the design of code that is written in this fashion tends to be much less coupled.

The XP rule is that a team is not allowed to work overtime. The only exception to that rule is that in the last week in a release, a team that is within striking distance of its release goal can sprint to the finish and work overtime.

The act of writing a unit test is more an act of design than of verification. It is also more an act of documentation than of verification. The act of writing a unit test closes a remarkable number of feedback loops, the least of which is the one pertaining to verification of function.

By writing the test first, we design the software to be conveniently callable.

Another important effect of writing tests first is that the tests act as an invaluable form of documentation.

The act of writing tests first is an act of discerning between design decisions.

Agile development makes the process of design and architecture continous.

Agile teams apply principles only to solve smells; they don’t apply principles when there are no smells. It would be a mistake to unconditionally conform to a principle just because it is a principle. The principles are there to help us eliminate bad smells. They are not a perfume to be liberally scattered all over the system. Over-conformance to the principles leads to the design smell of needless complexity.

If OCP is applied well, further changes of that kind are achieved by adding new code, not by changing old code that already works.

When considering whether a particular design is appropriate, one cannot simply view the solution in isolation. One must view it in terms of the reasonable assumptions made by the users of that design.3

That is the problem with conventions: they have to be continually resold to each developer. If the developer has not learned the convention or does not agree with it, the convention will be violated. And one violation can compromise the whole structure.