In software development , We always encounter a scene , It's about changing or adding a feature that we're not creating , Not familiar , In the code that is not related to the part of the system that you are responsible for , We're going to have trouble , At this time, the heart is even more broken .
that , Face the code left by former programmers , Do you want to change ? Rewrite old code , How to avoid leaving a hole ?
Published in 《 programmer 》 Of 《 Mysterious programmers 》 A cartoon
for a long time , There is a conventional taboo in the industry ： If you hate a programmer , Let him maintain the old code in disrepair ! Mention old code , Believe that all programmers have something to say .
Maybe every programmer has an ambition to expand his territory , So after the entry, there are redundant and complex old codes , I hope to overthrow everything again . After all, code structure
Bug, Slow operation or over challenge of aesthetics , It's easy to get mad . But for a software company , Old code is the symbol of assets , It is the core and important competitiveness accumulated over the years .
For software products , It's very common for people to maintain code in successive waves . If you rewrite the new technology , A new language or framework does not bring a qualitative leap to the product , Why do technology leaders agree to rewrite project code ? Let alone the break of capital chain in the process of maintenance , The existence of core programmers' turnover and other emergencies .
Based on the above considerations , For old code, whether we move or not ? There are voices of approval and opposition in the industry ：
Of course you can , But generally, the code of a project is relatively large , If the coupling is high , The risk of revision is bound to be high .
make snap , Push it all over again , When there's nothing to do .
Can old code move , It depends on the old code , For example, some open source frameworks , Many of the basic codes in it do not need to be moved or simply add code related to new business logic . If the old code is not based on the coding specification , There must be a lot of thunder in it , Who tramples on who dies . Here is a question , Every code merge must have code review, Having all developers of the project agree on the code , The longer such old code can last .
Before the time comes for revolution, you will be killed ; When it's time to make a revolution, it's time for you to make a revolution .
Break away from business requirements , Break away from the support of the top , Break away from a generous period of time , Don't dismantle thunder , It's not a dime , If you fail, you will be a sinner forever .
@ Wang Haiyang's blog ：
Variable name without number of points , Sometimes it says "fight back" ; Interface depends on magic number , I'm afraid to see it ; Private and public , Agency is also confused ; All over the world , A lot of delegation methods ; No source for the third party Library , Change without notes ; Single object multi responsibility , Sorrow flows back into a river ; Sudden new functions of products , One line of code becomes a God ; Here comes the task , It's too much to write one more line .
What do you think of the old code ? Welcome to express your opinions , Share your love hate entanglement with old code in the message area .