Programmer knowledge-technical debt

I believe everyone has a deep understanding of the term debt. Especially for people like me who are "house slaves", they have to pay back the money at the bank every month, that is, debt.

In the process of software development, we often borrow debts.Technical debtIn fact, it is the nonstandard solution adopted to quickly solve the problem. For example, write a condition to death, or use some shortcuts to achieve the goal. This is only a special case and cannot be applied to other modules.

For mortgages, you will surely remember to pay back every month. But for technical debt, you seem to be not so concerned about it. Indeed, it is not necessarily who borrowed it or paid it back, maybe by someone.CodeThere is a technical debt, and the burden is too heavy, so there is no way, the debt will be placed on the successor who will work later, the old saying: parent debt compensation, I don't know what this should be called.

However, the final undertaker of technical debt is the system owner or the system developer. Moreover, technical debt has a fatal feature. Unlike our mortgages, it is the same as a terrible loan, which we call usury.Roll-out. Imagine if we owe technical debt to a class, and thenProgramThis class has been extended and modified, and the subsequent Program has made greater extensions to the Extended Program, or later programs refer to debt classes in some functional writing, so this debt will produce a very large amount of interest, or even exceed the debt itself. It won't take much time, and we will find that we are unable to pay off this technical debt.

What we mentioned above is only the technical debt in terms of functions. I think the technical debt is distributed throughout our system development process. For example:

Technical debt also exists in code specificationsIf a programmer fails to comply with the code specification during development to quickly develop or modify a function, the programmer will be in debt for the code specification. If you do not pay off the service as soon as possible, subsequent modifications based on the program may also fail to comply with the code specifications, which is also the embodiment of the broken window theory. In this way, the maintainability of the program will be greatly reduced until it cannot be maintained.

Technical debt also exists in the document.Currently, many development teams still have technical documents, such as detailed design. If you only modify the code due to a tight schedule during a development, but do not modify the relevant documents, the document and the actual code functions will inevitably be inconsistent. The consequence of this is that after a period of time, we will find that the document is not enough for reference, because sometimes it will not only help us, but also lead to misleading, as a result, everyone lost confidence in the document.

We can see from the above,If you owe technical debt and neglect to modify it, the consequences will be very serious.So what should we do? In fact, the principle is very simple. First, try not to owe technical debt. Second, if you have to owe a debt, you should pay it as quickly as possible. The loan we borrowed from the bank is still paid off in 5 and 20 years, and the interest will be much different. For technical debt, the same is true. If we pay off the loan as soon as possible, we will not pay too much price, it is within our capacity, but if it takes too long, the debt will become more and more until we are unable to repay it.

as a programmer, besides paying attention to the debts in his life, be cautious with technical debt !