Technical debt {技术负债 / 技术债}1. Introduction1.1. Self-admitted technical debt (SATD)2. Causes3. Technical debt quadrant4. 避免和解决技术债ReferencesIn software development, or any other IT field (e.g., Infrastructure, Networking, etc.)technical debt (also known as design debt or code debt)is the implied cost of future reworking required when choosing an easy but limited solution instead of a better approach that could take more time.在程序设计及软件工程中技术负债 / 技术债 / 设计负债 / 代码负债是指开发人员为了加速软件开发在应该采用最佳方案时进行了妥协改用了短期内能加速软件开发的方案从而在未来给自己带来的额外开发负担。这种技术上的选择虽然眼前看起来可以得到好处但在未来必须付出额外的时间和精力持续修复之前的妥协所造成的问题及副作用或是进行重构把架构改善为最佳实现方式。技术债是一个指以牺牲长期代码质量为代价来实现短期项目目标的隐喻。技术债是一种透支行为通过牺牲未来来满足当下的一些需求。技术债务是开发速度优先于完美的结果是开发团队做出的所有决定的累积导致代码中的缺陷、疏忽和错误无论是有意的还是无意的。技术债务并不意味着不满足功能或技术要求。1. IntroductionWard Cunningham first drew the comparison between technical complexity and debt in a 1992 experience report:“Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite… The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.”1992 年Ward Cunningham (沃德 坎宁安) 首次对技术复杂性和债务进行了比较交付第一次代码就像欠债一样。只要通过重写及时偿还一点点债务会加速开发。当债务没有偿还时危险就会发生。在不完全正确的代码上花费的每一分钟都算作该债务的利息。整个工程组织可能会因为未整合的实施 (无论是面向对象的实施还是其他实施) 的债务负担而陷入停滞状态。Ward Cunninghamhttps://en.wikipedia.org/wiki/Ward_CunninghamHoward G. Cunningham (born May 26, 1949) is an American computer programmer who developed the first wiki and was a co-author of the Manifesto for Agile Software Development.沃德 坎宁安是美国计算机程序员也是 Wiki 概念的发明者。In his 2004 text, Refactoring to Patterns, Joshua Kerievsky presents a comparable argument concerning the costs associated with architectural negligence, which he describes as “design debt”.Joshua Kerievsky 在其 2004 年的文章 Refactoring to Patterns 中提出了一个类似的论点涉及与架构疏忽相关的成本他将其描述为设计债务。Refactoring to Patterns (重构与模式)Joshua Kerievsky, 2004.Activities that might be postponed include documentation, writing tests, attending to TODO comments and tackling compiler and static code analysis warnings. Other instances of technical debt include knowledge that isn’t shared around the organization and code that is too confusing to be modified easily.可能被推迟的活动包括文档、编写测试、关注 TODO 注释以及处理编译器和静态代码分析警告。技术债务的其他实例包括组织内未共享的知识以及过于混乱而难以轻松修改的代码。In open source software, postponing sending local changes to the upstream project is a form of technical debt.在开源软件中推迟向上游项目发送本地更改是一种技术债务。1.1. Self-admitted technical debt (SATD)开发者有意引入项目中的技术债被称为自承认技术债通常以代码注释的形式存在于软件项目中。2. Causesband-aidn. 急救带急救绷带 adj. 急忙拼凑的Common causes of technical debt include:Ongoing development, long series of project enhancements over time renders old solutions sub-optimal.随着时间的推移持续的开发、一系列的项目增强使得旧的解决方案变得次优。Insufficient up-front definition, where requirements are still being defined during development, development starts before any design takes place. This is done to save time but often has to be reworked later.不充足的事前定义在开发过程中仍在定义需求开发在任何设计发生之前就开始了。这样做是为了节省时间但通常需要稍后返工。Business pressures, where the business considers getting something released sooner before the necessary changes are complete, builds up technical debt involving those uncompleted changes.业务压力即企业考虑在必要的更改完成之前尽早发布某些内容会积累涉及那些未完成的更改的技术债务。Lack of process or understanding, where businesses are blind to the concept of technical debt, and make decisions without considering the implications.缺少流程或理解从而商务上对技术债务不了解不考虑后果就做出决策。Tightly coupled components, where functions are not modular, the software is not flexible enough to adapt to changes in business needs.组件紧密耦合功能不是模块化的软件不够灵活无法适应业务需求的变化。Lack of a test suite, which encourages quick and risky band-aid bug fixes.缺乏测试套件这刺激了快速高风险凑活式的修复 bug。Lack of software documentation, where code is created without supporting documentation.缺少文档写代码但没有必要的支撑性文档。Lack of collaboration, where knowledge isn’t shared around the organization and business efficiency suffers, or junior developers are not properly mentored.缺乏合作。知识没有得到共享对新手缺乏监督辅导。Parallel development on multiple branches accrues technical debt because of the work required to merge the changes into a single source base. The more changes done in isolation, the more debt.在两个或多个分支上平行开发而累积了技术债务。由于工作最终需要合并两个分支的代码拖延越晚需要工作代价越大。Deferred refactoring. As the requirements for a project evolve, it may become clear that parts of the code have become inefficient or difficult to edit and must be refactored in order to support future requirements. The longer refactoring is delayed, and the more code is added, the bigger the debt.推迟重构。随着项目需求的发展可能会发现部分代码变得效率低下或难以编辑必须进行重构才能支持未来的需求。重构拖延的时间越长添加的代码越多债务就越大。Lack of alignment to standards, where industry standard features, frameworks, and technologies are ignored. Eventually integration with standards will come and doing so sooner will cost less (similar to “delayed refactoring”).缺乏与标准的一致性行业标准功能、框架和技术被忽视。最终与标准的集成将会到来而且越早这样做成本就会更低 (类似于延迟重构)。Lack of knowledge, when the developer doesn’t know how to write elegant code.缺少知识开发者并不知道如何写精致的代码。Lack of ownership, when outsourced software efforts result in in-house engineering being required to refactor or rewrite outsourced code.缺少所有权外包的软件最终要让自己的工程师去重构或重写源代码。Poor technological leadership, where poorly thought out commands are handed down the chain of command.技术领导力差未深思熟虑的命令传达下来增加了技术债务而不是减少它。Last minute specification changes. These have potential to percolate throughout a project, but there is insufficient time or budget to document and test the changes.最后一分钟规范变更。这些有可能渗透到整个项目中但没有足够的时间或预算来记录和测试这些更改。Kenny Rubin uses the following status categories:Happened-upon technical debt- debt that the development team was unaware existed until it was exposed during the normal course of performing work on the product.发生的技术债务 - 开发团队不知道债务的存在直到在产品的正常工作过程中暴露出来。Known technical debt- debt that is known to the development team and has been made visible using one of many approaches.已知技术债务 - 开发团队已知的债务并且已使用多种方法之一使其可见。Targeted technical debt- debt that is known and has been targeted for servicing by the development team.有针对性的技术债务 - 已知的债务并且已成为开发团队要偿还的债务。3. Technical debt quadrant技术债务的四象限分类Technical Debt Landscape:4. 避免和解决技术债明确技术规范加强管理团队需要建立相应的技术规范和标准让每个决策都有依据同时加强流程上的管理。持续关注技术发展趋势提前规划架构的演进方向关注新技术的趋势和动向探索是否有更优的解决方案提前规划架构的演进方向。保持技术优化相关投入技术的构建并不是一劳永逸的是需要不断的成本投入来维护的。可视化团队需要将识别到的技术债及时可视化出来判定优先级通过内部流程将技术债的状态进行转移进而解决。References[1] Yongqiang Cheng (程永强), https://yongqiang.blog.csdn.net/[2] Technical debt, https://en.wikipedia.org/wiki/Technical_debt[3] Ward Cunningham, https://en.wikipedia.org/wiki/Ward_Cunningham[4] Technical Debt Quadranthttps://martinfowler.com/bliki/TechnicalDebtQuadrant.html[5] Refactoring for Software Design Smells: Managing Technical Debt, https://books.google.com.hk/books?id1SaOAwAAQBAJ[6] Managing Software Debt: Building for Inevitable Change, https://books.google.com.hk/books?idLYQlOaRwpnEC[7] Managing Technical Debt in Software Engineering, https://drops.dagstuhl.de/opus/volltexte/2016/6693/pdf/dagrep_v006_i004_p110_s16162.pdf[8] What is technical debt?, https://deepsource.com/blog/what-is-technical-debt[9] Technical Debts: Everything you need to know!, https://gauravtiwari.org/technical-debts-basics/[10] Technical Debt, https://www.martinfowler.com/bliki/TechnicalDebt.html[11] The Future of Managing Technical Debt, https://insights.sei.cmu.edu/blog/the-future-of-managing-technical-debt/[12] Technical debt (技术负债 / 技术债), https://mp.weixin.qq.com/s/H9Ds3RT_00NWx0gRewbGDQ