[beauty of software engineering - column notes] 24 | technical debt: continue to make do with it, or overthrow it and start over?

---

Column information

1. Columnist ： The treasure jade

2. Column publishing platform ： Geek time

---

primary coverage

---

There is a very vivid noun called “ Technical debt ”, It is used to describe the quality problems in the above architecture or code .

---

One 、 What is technology debt ？

No reduction in scope , The cost does not increase , I also want to save time and take shortcuts , It will affect the quality . This “ quality ”, Not just product quality , And architecture quality and code quality . This kind of overdraft on quality , It's a debt . And technical debt , It is the overdraft of architecture quality and code quality in software projects .

Technical debt is indeed a vivid metaphor , Let you realize that it is linked to the cost , And technical debt also has some characteristics of financial debt , For example, there is interest , For another example, technical debt also has a good side .

1. Technical debt is interest bearing

   debt “ interest ”, It is when the software is modified later , Need extra time cost .

2. Technical debt is not always bad

   In a software project , Also often deliberately owe some technical debt , Improve the short-term development speed , So that the software can be launched as soon as possible , So as to seize the market ; There are also rapid prototyping models , Rapid development and verification through technical debt , If verification is not feasible , Even this technical debt does not need to be repaid .

---

Two 、 Reasons for technical debt

If someone is in debt in reality , There are probably several reasons ： This person has no plan for debt 、 Forced by life, I have to borrow 、 Borrow temporarily for long-term interests 、 Unknowingly, I owe a debt .

The reasons for technical debt are similar , therefore 《 restructure 》 The author of a Book Martin Fowler The causes of technical debt are divided into two dimensions ：

1. Frivolous （reckless） Or be cautious （prudent）;
2. deliberately （deliberate） Or not （inadvertent）.

• Frivolous / Intentional debt

  This quadrant , It reflects the cost of the team 、 The reason for time , There is no design for intentionally taking shortcuts 、 Not following good development practices , There is no subsequent improvement plan for the debt .

• cautious / Intentional debt

  This quadrant , It reflects that the team clearly knows the benefits and consequences of technical debt , And also made follow-up plans to improve the architecture and improve the quality of the code .

• Frivolous / Unintentional debt

  This quadrant , Reflects the team's ignorance of technical debt , I don't know how to repay the technical debt in the future .

• cautious / Unintentional debt

  This quadrant reflects that the team actually attaches great importance to architectural design and technical debt , But because of business changes , Or other objective factors , Resulting in technical debt .

---

3、 ... and 、 How to manage technical debt ？

Martin Fowler I drew a picture , To vividly describe the design 、 The relationship between time and development speed . Write code without design , In the short run, it really saves time , But after crossing a critical point , The development speed will drop sharply .

The income and interest of technical debt are similar , In the beginning , Low interest and high income , It saves time to owe some technical debt , But beyond a critical point , High interest and low income , It will greatly reduce the development efficiency .

1. Identify technical debt

   If it is a real debt , It is easy to know whether you are in debt by checking your bank account , Technical debt is less intuitive , But identifying technology debt is a critical step , Only find the technical debt in the system , To find the right solution to it . If you watch carefully , We can still find soft through many indicators ：

   • Slow down development
   • Unit test code coverage is low
   • High error rate of code specification check
   • Bug More and more

2. Choose a strategy to deal with technical debt

   • rewrite ： Overthrow comes again , Pay off at one time
   • maintain ： To mend , Just pay interest
   • restructure ： The old and the new alternate , hire purchase

3. Implementation strategy

   When you choose which strategy to use to deal with technical debt , Then you can implement your strategy . Different strategies may be implemented in slightly different ways .

   • For rewritten policies , It should be established as a formal project , Follow the project process ;
   • For refactoring strategies , The whole reconstruction task should be divided into small tasks , Put it in the project plan , Create as Ticket, Put it into the task tracking system to track ;
   • For the maintenance strategy , We should also take the repair work that needs to be done as a task , Put it in the plan , Put it into the task tracking system .

   The key to implementing the strategy is to implement it as a development task , As part of the project plan .

4. Prevention is the best way

---

Four 、 Other excerpts

• But technology borrowing cannot be unlimited , Because the more you borrow , The higher the interest , When the income cannot offset the interest , Will fall into a vicious circle , Resulting in inefficient development , Progress is difficult to guarantee .
• For the debt in the project , We need to know clearly what kind of technical debt , And the income and interest it brings to the project , This can help us manage these debts .
• Refactoring is a relatively eclectic strategy , Just like we use installment payment to repay the loan .

---

summary

For technical debt , Is to continue to make do with , Or overthrow and start again ？ In fact, it depends on which strategy has a better input-output ratio , If overthrow and start again, the price is too high , Then we should consider carefully , It's better to repair or partially restructure first ; If repair is difficult to maintain , Consider rewriting or refactoring .

For technical debt , Or we should have a good awareness in daily development , Don't take shortcuts , Prevent trouble before it happens , Prevent the occurrence of technical debt .