©2020-2024 ioDraw All rights reserved
1, If you want to add a feature to the program , However, it is found that the code is not easy to change due to the lack of good structure , Then refactor that program first , Make it easier to add this feature , Then add the feature .
2, Refactoring technology is to modify the program at a small pace . If you make a mistake , It's easy to find .
3, A fool can write code that a computer can understand . Only those who can write code that is easy for human beings to understand , Is a good programmer .
4, The test of good code is whether people can easily modify it .
5, If you really look at how most programmers allocate their time , You'll find out , They write code in a fraction of the time . There is time to decide what to do next , Some time is spent on design , however , The time spent debugging is the most . I'm sure , Every reader must remember the experience of spending hours debugging code —— And often all night . Every programmer can say one to fix one bug It took a whole day （ Even longer ） My story . repair bug It's usually faster , But find out bug It's a nightmare . When repairing a bug Time , It often leads to another problem bug, It took a long time to notice it . then , You're going to spend a lot of time locating problems .
6, When you feel the need to write notes , Please try refactoring first , Try to make all comments redundant .
7, A set of tests is a powerful tool bug detector , Can greatly reduce the search time bug Time required .
8, Run tests frequently . For the code you're working on , The corresponding test runs at least every few minutes , Run all tests at least once a day .
9, Don't let the test fail to capture all the data bug Don't write tests , Because tests do capture most of the data bug.
10, Whenever you receive bug report , Please write a unit test to expose this bug.
11, Programming , A lot of it's talking to the computer ： I write code to tell the computer what to do , And its response is to act precisely on my instructions . In a word , All I did was fill in the blanks “ What do I want it to do ” and “ I told him what to do ” The gap between them . The core of programming is “ Say exactly what I want ”. But don't forget , Except for computers , There are other readers ： In a few months, another programmer might try to read my code and make some changes to it . It's easy to forget this reader , But he is the most important . Does the computer spend a few more clock cycles to compile , What does it matter ? If a programmer spends a week modifying a piece of code , That's killing me —— If he understands my code , The change was originally only an hour .
12, Good design must be done before programming begins , Because once you start writing code , Design will only gradually corrupt . Reconstruction has changed the picture .
13, Dirty code has to be refactored , But beautiful code also needs a lot of refactoring .
14, The only purpose of refactoring is to make our development faster , Create more value with less work .
15, Some people try to use it “ Neat code ”“ Good engineering practice ” The necessity of reconstruction is demonstrated by moral reasons , I think it's a trap . The point of refactoring is not to burnish the code base , It's purely economic . Why do we restructure , Because it makes us faster —— Add features faster , repair bug Faster . Be sure to keep that in mind at all times , When communicating with others, we should constantly emphasize this point . Restructuring should always be driven by economic interests . programmer , The more managers and customers understand this ,“ Good design ” The more often that curve will appear .
16, Most people would think that , It's good to have a large legacy , But it's different from the programmer's point of view . Legacy code is often complex , Not enough testing , And most importantly , It was written by someone else （ Shivering ）.
17, If a team wants to refactor , Then every team member needs to master the skills of refactoring , Be able to refactor when needed , It doesn't interfere with other people's work . That's why I encourage continuous integration ： Yes CI, Each member's refactoring can be quickly shared with other colleagues , It will not happen that an interface has been deleted when it is called here ; If a refactoring will affect other people's work , We'll find out soon . Self testing code is also a key part of continuous integration , So these three practices —— Self test code , Continuous integration , restructure —— There is a strong synergy between them .
18, A well constructed program can help this optimization in two ways . first , It gives me plenty of time for performance tuning , Because there's well constructed code at hand , I can add features more quickly , There will be more time for performance issues （ Accurate measurement ensures that I put the time in the right place ）. secondly , Facing well structured programs , I have finer granularity when I do performance analysis . Measurement tools will take me to a smaller code segment , And it's easier to adjust the performance . Because the code is clearer , So I can better understand my choice , It is clearer which adjustment plays a key role .
19, Run tests frequently . For the code you're working on , The corresponding test runs at least every few minutes , Run all tests at least once a day .
20, Is a test set good enough , The best measure is subjective , Please ask yourself ： If someone introduces a bug in the code , How confident are you that it can be picked up by the test set ? This confidence is difficult to quantify , Blind confidence should not be counted , But the whole goal of self-test code , It's about helping you get that kind of confidence . If I refactor the code , Seeing all the tests turn green, you can be confident that no extra tests are introduced bug, such , I'm happy to say that , I've got a set of tests that are good enough .
The above sentences are excerpted from 《 restructure Improve the design of existing code （ The third 2 edition Paperback ）》
[ beautiful ] Martin · Fowler （Martin Fowler） By , Bear day , Lin Congyu translate
This book is a classic 《 restructure 》 publish 20 Update after . The process of reconstruction is clearly revealed in the book , The principle and practice of refactoring are explained , And give when and where to start mining code in order to improve . The book gives an example 60 Multiple feasible refactorings , Each refactoring introduces the motivations and techniques of a proven code transformation approach . The refactoring guidelines proposed in this book will help developers modify code one small step at a time , So as to reduce the risk in the development process .
This book is suitable for software developers , Project management personnel, etc , It can also be used as a reference for teachers and students of computer and related majors in Colleges and universities .
Technology