No. article first appeared in public preserved egg blackboard
Recently such a thing happened to me. I am responsible for content creation, provides a logical interface written, but check the chain for a check Source space including the domain name, you can understand the business name space is a location, space related to the refinement of cost management. User interfaces found in the written test failed because the picture is not legitimate. That in that case, if you are, you provide a picture of another chain transfer services? Or to determine whether he was writing and then call it a special treat for its picture? Or stressed specification and then let the users themselves solve it?
Interface consumers feel this transformation should not be borne by them, we should not be unduly concerned about the internal details of the service provider, after all, the pictures are uploaded Jingdong picture. But then, if handled by me, check chain change is a tricky thing, or check its source release pictures alone, this is a very individual needs. As I said before, the interface should not be for individual services. Also, the caller does not obey my constraint specification, in response to abnormal normal. Po po said, the public that goes. Finally, the organization stakeholders to discuss about it, the conclusion is the first of its short-term sources of content without any trial machine, to check on long chain transformation.
You see, it is easy because the project urgent compromise on quality, introducing technology in collaboration debt. There is not a long-term plan? Do not complacent too early, demand is endless, you may no time to reform them, or to forget these things. Over time, finally difficult to maintain.
That technical debt how to manage it?
Let's take the next definition of technical debt. I have a bad design by introducing a very short time to solve the impossible thing. Like to buy a house than the borrower. But we know that poor internal quality of a software system, then, whether caused accidentally or due to capacity problems caused, it will allow us in the software to modify or add new features, far more than the required hours of work estimates. That economic and technical debt debt, are to be repaid, interest paid extra working hours just mentioned is repaid.
When in fact, it has indicated that the following definition of how to deal with, is that we can devote some extra hours reconstruct the corresponding bad code. Like the same deal with financial debt, little by little pay back. With the financial interest and principal repayment of thinking, we can easily identify which need to get rid of bad design. If there is a system sucks, and we do not need their building blocks, this bad design is not an issue, that is to say, only need to modify the code of the old system, only the technical debt interest thing. Bad design but stable no problem code does not need adjustment, contrast, those high-frequency region of the modified code needs to be particularly sensitive reconstruction, as these interest rates are quite steep. The more the code changes, the greater the risk of introducing bad design.
In short, because there are technical debt, if the subsequent need to add the urgent needs of the case, or technical debt honestly to manage it! By restructuring and strengthening of code quality code review, so that fewer and fewer defects to be solved! So that product managers and project managers schedule devoted to technical debt!
Source: www.liangsonghua.me
Author: Jingdong Senior Engineer - Liang Songhua, in-depth understanding of the stability of security, agile development, JAVA advanced, micro-service architecture