The old code of the pits, whether or not to change the old code?
In software research and development, we will always encounter a scenario that is to change or add a function to the code which is not part of the system that we are creating, nor familiar with, and more responsible for its own system. It will be in trouble, but the heart will collapse at this time.
So, in the face of the code left by the former programmer, do you want to change it? To rewrite the old code, how can we keep the pit away from it?
For a long time, the industry has been spreading a common taboo: if you hate a programmer, let him maintain the old lost code! Mention the old code and believe that all the programmers have what they have to say.
Perhaps everyone has a border expansion ambitions, so the entry back to the old code redundancy complex, hope everything will overthrow. After all, the code structure Bug, the slow operation is too challenging the aesthetic and so on, it is easy to make people crazy. But for a software enterprise, the old code is the symbol of the assets, the core and the important competitiveness that has been accumulated for many years.
For software products, it is very common for people to maintain code several times. If your new technology, new language or new framework is not able to bring a qualitative leap to the product, why do technical leaders agree to rewrite project code? Not to mention the existence of unexpected conditions such as the break of capital chain and the separation of core programmers during the maintenance process.
Based on the thinking above, do we still move or do not move to the old code? In the industry, there are voices of approval and opposition:
@mostone:
Of course, it can move, but generally, the code of a project is large. If the coupling is high, the risk of modification is bound to be great.
@u013553804:
In a big way, we all push back, when there is nothing to do.
@u012377333:
Whether old code can move or not depends on how old code is written. For example, some open source frameworks, many of the underlying codes do not need to move or simply add new code related to business logic. If the old code is not based on the code code, it is bound to bury a lot of thunder, and who dies. This involves a problem. Every code merge must be code review, so that all developers can agree on the code, so that the old code will become more durable.
@chinglish:
The revolutionary time before you go to the revolution will eventually reform his life; the revolutionary time to go revolution that is what people should break edward.
@dreaper126:
From the business needs, from the upper support from a well-off period, do not open the thunder, the 10 Fen lost benefits, you will become a traitor through the ages.
@ Wang ocean's blog:
Variable names did not point, sometimes write back by mistake; interface magic number, I see on the timid; public private mix, proxy is confused; message everywhere, commissioned a bunch of ways; third party libraries no source, no single object with change notes; many responsibilities and sadness reverse flow into the river; products the sudden increase of new features, a line of code to the task has become great God; commissioned to write a line too much.
What do you think about the old code? Welcome to share your old code each one airs his own views, and the love and hate in the message area.
