The Way to Neat Code - Reading Notes (5)

The Way to Neat Code

Synopsis:

This book is a summary of the experience of programming guru "Uncle Bob" over 40 years of programming career, explaining what kind of attitude, what kind of principles and what kind of actions are needed to become a real professional programmer. The author takes the detours and mistakes he and his colleagues have made as examples, with the intention of guiding those who come after him and helping them to take a higher step in their careers.

This book is suitable for all programmers and can be used as a reference for all those who want to become professionally literate in the workplace.

Chapter 5 Test-Driven Development (TDD)

What kind of professional is it if you don't even know if all the code works? How can you know that all code works if you don't test it after every change? How can you test your code every time you change it if you don't have automated unit tests with very high coverage? How can you get very high coverage automated unit tests if you don't use TDD?

5.2 The Three Laws of TDD

(1) Don't write any product code until you've programmed a failing unit test.

(2) As soon as one unit test fails, don't write any more test code; not being able to pass compilation is also a failure situation.

(3) Just enough product code to make the currently failing unit test pass, not more.

5.3 Advantages of TDD

Determinism:

If TDD is used as an industry discipline, then dozens of tests have to be written every day, hundreds of tests every week, and thousands of tests every year. At any moment, any change to the code must run all the tests that are on hand.

At any point, once any part of the project has been modified, just run the full unit tests again. If the unit tests all pass, I'm almost sure that my changes didn't break anything. How sure is "almost sure"? I'm pretty sure enough to deliver!

Reduced defect injection rate:

There are a number of reports and studies [3] that claim TDD can significantly reduce defects. From IBM to Microsoft, from Sabre to Symantec, company after company, team after team, have experienced defects dropping to 1/2, 1/5, or even 1/10 of their original size. These numbers cannot fail to move professionals.

Give developers the ability to modify the optimization projectvalor：

When you see bad code, why don't you change it? When you see a messy function, your first reaction is, "What a mess, this function needs to be organized." Your second reaction is, "I'm not touching it!" Why? Because you know that if you go and move it, you risk breaking it; and if you break it, then it haunts you.

But what if you could be sure that you hadn't destroyed anything with your organizing efforts? What if you had the kind of certainty I just mentioned? What if you could just click a button, and then within 90 seconds you could be sure that your changes didn't break anything, but just made the code better? This is where TDD is most powerful. Having a trustworthy set of tests completely eliminates all fear of modifying code. When you see bad code, you can let it go and organize it. The code becomes malleable, and you can be assured of polishing it to a simple and satisfying result.

When programmers no longer fear organizing their code, they do it! Clean code is easier to understand, easier to modify, and easier to extend. The code is cleaner, and there are fewer defects. The entire codebase improves steadily, eliminating the common industry practice of letting code deteriorate without seeing it.

Unit testing is documentation:

If you follow the three laws of TDD, theEach unit test is an example, describing the usage of the system in code. If the three laws are followed, then for each object in the system, unit tests can clearly describe the various ways in which the object is created. For every function in the system, unit tests can clearly describe the various ways in which the function can be called in a meaningful way. For any usage that needs to be known, unit tests provide a thorough description.

Unit tests are documentation. They describe the lowest-level design details of the system design. They are clear and precise, written in a language that the reader can understand, and in a form that can be run. They are the best kind of low-level documentation.

Favorable design:

If you don't write the tests first, you risk the problem of individual functions coupling together to end up in an untestable chunk. If you write tests later, you may be able to test the inputs and outputs of the whole chunk, but it's hard to test individual functions. Therefore, following the rule of three and testing first creates a driving force for loosely coupled designs.

Summary:Using test-driven development is the choice of professionals;

It is a principle that enhances code certainty, gives encouragement to programmers, reduces code defect rates, and optimizes documentation and design. Various attempts at TDD have shown that not using TDD means you may not be professional enough.

Of course, there are occasions when it would seem impractical or inappropriate to follow these three rules. Such situations are rare, but they do exist. If following one of the rules would do more harm than good, then of course a professional developer would not choose it.