Chapter 6: When you are coding
Of this chapter and what we do now often closely related and need a good understanding of understanding.
Pragmatic programmers to think critically about all the code, including our own. We continue to see room for improvement in our processes and design. In the "reconstruction", we will discuss a - some even if we are still in the mid-project, can also help us fix existing code technology.
As long as you make the code, you should remember that one day you have to test it. This way you will increase the likelihood of it actually passed the test.
How thoughtful programming
We want to make writing code spend less time, you want to grab as much as possible and fix errors early in the development cycle, you want less manufacturing error at the beginning. If we can thoughtfully programmed, that would help us:
● always aware of what you are doing. Fred let things slowly out of control, until finally cooked, like "stone soup with boiled frog" in the frog.
● Do not blindly programmed. Trying to build an application that you do not fully understand, or you are not familiar with the use of technology, it is
I want to be a coincidence misleading.
● act in accordance with the plan, whether the plan is in your mind, in the back of a cocktail napkin. Or in a CASE tool to generate the wall so much output.
● rely on reliable things. Do not rely on coincidence or assumptions. If you can not tell the difference between each particular case, it is assumed to be the worst.
● establish document your assumptions. "Programming by contract" helps to clarify assume that in your mind, and helps to convey them to others.
● Do not just test your code, but also to test your assumptions. Do not guess; to actually try it. Written assertion to test your assumptions. If your assertion is correct, you'll improve code documentation. If you find that your assumption is wrong, then we will consider themselves fortunate.
● Prioritize your work. Spend time on important aspects; most likely, they are the hardest part.
● Do not be a slave to history: Do not let existing code govern future code, no longer applies if all of the code can be replaced. Even in a program, do not let the things you've done your next step bound to do a ready for reconstruction.
Select the appropriate algorithm.
Reconstruction: rewrite, redo and re-structure the code
Wherein the code refactoring: repeating, non-orthogonal design, outdated information, performance.
How to reconstruct:
Not to increase functionality;
Before you begin remodeling, make sure you have a good test;
Steps to take short, deliberate
Code easier to test
The testability built into the software, and connecting together the various portions of each part be thoroughly tested before
Need to write the test unit tests the test code is easy to find; treated with test equipment common operations; build test window to provide various views of the internal state of the module, without using a debugger.
Test equipment should have the following features:
● specify a standard way to set up and clean up (setup and cleanup) of.
● for selecting individual or all of the available test methods,
● analyze whether the output means is expected (or unexpected) results.
● fault reporting format standardized.
Testing should be combined; that is, the test may test combinations by the sub-sub-assembly to any depth. Through this - characteristics, we can use the same tools, the same easily test the entire system or selected parts of the system.