This is a creation in Article, where the information may have evolved or changed.
This author, Kent Beck Kent Beck, was one of the first to study the model and reconstruction of software development, one of the pioneers of agile Development, the founder of Extreme programming and test-driven development, and the author of Smalltalk and JUnit, Has a profound impact on software development in today's world. Now Facebook is working.
I've been working on my Facebook code this week, and I like the job. I've compiled thousands of hours of code in my career, and I have a set of rules that make this sort of thing safer, more fun, and more efficient.
The finishing work is done through a series of short and safe steps. In fact, rule one is that if it's hard, don't do it. I used to do crossword puzzles at night. If I get stuck, I go to bed, and the next night, the clues that are not found are often easy to spot. Instead of trying to make a big one, stop when you meet resistance.
Finishing will get into the feeling that what you miss is more than what you get from one success (later on). The second rule is to start when you are full of energy and stop when you are tired . Get up and walk. If the spirit is not restored, the day's work will be done.
Only when the other changes are carefully tracked (I mix it up with the latest differences), the finishing work can be synchronized with the development. The third rule is to complete the work of each link immediately . Unlike feature development, feature development is only meaningful when a chunk of work is done, and finishing is done in a little bit of time.
It only takes a lot of effort to organize in any step, so I'll give up when any of the steps are in trouble. Therefore, rule four is two times after the failure to recover . If I clean up the code, run the test, and encounter a test failure, I'll fix it right away. If my repair fails, I will immediately revert to the last known good state.
Even without the vision of a shiny new design, finishing is useful. However, sometimes I want to see how things will develop, so the fifth one is practice . Perform a series of grooming and restores. The second time will be faster and you will be more familiar with avoiding which pits.
Only when the risk of collateral damage is low, the cost of reviewing the changes is lower. Rule six is to isolate the arrangement . If you miss the opportunity to sort through your code, then it can be difficult. Either finish and then organize, or restore, organize, and modify.
Try these. Move the temporary declared variable to the position it was used for the first time, simplifying the Boolean expression ( return expression == True ? ), extract a helper that narrows the range of logic or state to where it is actually used.
Rules
- Rule one, if it's hard, don't do it.
- Rule two, start when you're full of energy, stop when you're tired
- Rule three, immediately complete each link work
- Rule four, two times after failure recovery
- Rule Five, practice
- Rule VI, isolation and collation
End
I have changed the architecture and extracted the framework through a rigorous reorganization. This approach can make significant changes safely. I think this is because, although the cost of each finishing is constant, but the return is a number of levels, but I need data and models to explain the hypothesis.
via:https://www.facebook.com/notes/kent-beck/the-life-changing-magic-of-tidying-up-code/1544047022294823/
Author: KENT BECK Translator: GEEKPI proofreading: Wxy
This article was compiled by LCTT original, Linux China honors launched