Programmer should know--technical debt _ documentation

The word "debt", I believe that we have been deeply aware of it, especially like me as a "house slave" people, every month to go to the bank to pay money, that is debt ah.

In the process of software development, we tend to borrow, people call it technical debt, in fact, in order to quickly solve the problem, and the adoption of the nonstandard plan. For example, to write a condition to death, and then take some shortcuts to achieve the purpose, which is only a special case, can not be applied to other modules.

For a mortgage, you're sure to remember it every month, but for technical debt, people seem to be less concerned about it, it is not necessarily who borrowed who also, may be a person's code in the production of technical debt, and then because the burden is too heavy, the flash, there is no way, this debt will be pressed on the successor to work, As the old saying goes: "The father of the debt, do not know what this should be called."

However, the ultimate commitment of technical debt is the owner of the system, or the developer of the system. And, the technical debt has a fatal trait, unlike our mortgage, which is the same as a terrible loan-what we call usury-and that is arbitrage. Imagine if we owed a technical debt in a class, and then the program later extended and modified the class, after the program has made a larger expansion of the program, or later the program in some function of the wording of the reference to the debt of the class, then this debt will generate very large interest, Even more than the debt itself. If we don't have much time, we will find that we are unable to repay the technical debt.

The above mentioned is only the technical debt in the functional, I feel that the technical debt is all over our system development process. Say:

There is also a technical debt in the code specification, and if a programmer fails to comply with code specifications for rapid development or modification of a feature, then the code-specification debt is owed. If not repaid quickly, then the changes based on the program, there will be a great possibility of non-compliance with code specifications, which is the embodiment of the broken window theory. In this way, the maintainability of the program will be greatly reduced until it is not maintainable.

There are also technical debts on the document. Now many development teams still have technical documentation, like detailed design or something. If in one development, because time is tight, only modifies the code, but does not modify the related document, then will cause the document and the actual code function inconsistency. The consequence of this is that after a while, we will find that the document is simply not sufficient for reference, because sometimes not only will not help us, but also can cause misleading, so that everyone has lost confidence in the document.

From the above we can see that, due to technical debt, and neglect of changes, the consequences will be very serious, then we should do it. In fact, the truth is very simple, first of all, try not to owe the technical debt, and secondly, once the debt has been forced to pay, should be repaid at the fastest speed. The mortgage we borrowed in the bank, 5 years and 20, the interest will vary a lot, and for technical debt, too, if repaid as soon as possible, it will not pay too much, and it is within our ability to withstand, but if the delay is too long, the debt will become more and more, until we are unable to repay.

Therefore, as a programmer, in addition to concern about their own life in the debt, but also to the technical debt to raise vigilance.