24 | 技术债务：是继续修修补补凑合着用，还是推翻重来？
该思维导图由 AI 生成，仅供参考
什么是技术债务？
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
软件项目中的技术债务是一种常见问题，它指的是对架构质量和代码质量的透支。技术债务会导致代码臃肿、系统效率低下，难以维护和新增功能。本文介绍了识别技术债务的方法，包括观察开发速度、单元测试覆盖率、代码规范检查的错误率以及Bug数量等指标。在识别出技术债务后，需要选择处理策略，包括重写、维持和重构。实施策略时，需要将任务落实成开发任务，作为项目计划的一部分。此外，文章还强调了预防技术债务的重要性，提出了预防措施，如预先投资、不走捷径和及时还债。总的来说，管理技术债务需要充分了解项目中的债务情况，并制定相应的策略，以控制债务在可接受的范围内。文章提供了读者思考的问题，引发了对技术债务管理的深入思考。
《软件工程之美》，新⼈⾸单¥59
全部留言(22)
- 最新
- 精选
bearlu明白了为什么不要接到一个需求就马上写代码。没有经过设计的代码，后期维护成本极高。作者回复: 是这样子的，磨刀不误砍柴工
2019-04-2318
clever_P对技术债务有深刻的感触，但凡对技术有深刻理解的人都会采取预防的策略。 对于已经欠下的技术债务，如果软件生命不会很快结束，维持的策略长期来看是不可取的，债务只会越来越多，问题也会越来越多，在业务紧的情况下，不只是透支研发成本，还会透支工程师的健康。对于重构的策略，个人理解是从局部到整体的，在输出结果不变的情况下，改善内部设计，但是对于大的结构设计缺陷，有时局部重构也不太好做，整体结构会有很多限制。对于重写，要对原有系统的业务功能和业务特点有细致的理解，对业务发展有较为清晰的认识，最最重要的是能够清楚识别原有系统的设计问题，有针对性的提出解决方案来处理这些问题，不然重写就真的只是重写一遍了。作者回复: 预防是最好的方法，也是要求最高的。 技术债务的问题确实是没有万能的解决方案，还是要先识别，然后理性客观的做一个方案，再有计划的去实施。
2019-04-2311
易林林在研发过程中，产生技术债务的时候，稍微有点技术功底的人，或多或少都会有感觉的。比如：有重复代码的时候，会意识到好像已经写过了；函数命名的时候，会意识到好像有个相似的名称已经命名过；函数行数过多的时候，自己心里会感觉不舒服等等。更有甚者，你去整理这些问题还会被同事标上“强迫症”患者的称号，还是放弃吧。技术债务就这样在外部和内部双重压力下自然而然的产生了。 那么如何产生有利的技术债务呢？我觉得应该从公司制度、研发流程、个人素质培养三方面入手。公司制度实际上是为领导层准备的，领导层以身作则去影响下面的员工，员工就没有冒犯的理由，比如：合理的奖惩制度，要做到公平合理，一视同仁；研发流程主要是让团队成员知道自己什么时候该做什么事情，如何去按照指定的约束去做好自己的事情，除此之外，还应该给予明确的成长上升空间；员工素质的培养则需要从一个人的职业素质，技能优化，团队协作方面着手，让他们拥有积极努力的心态参与到工作中去，这基本上就能解决最基础的技术债务问题（领导决策错误产生的技术债务另当别论）。 在我遇到过的技术债务中，主要由领导决策、产品业务逻辑、技术最初选型、技术更新换代、团队综合素质中的一种或几种导致。对此，我只能说个人能力达到什么层次就应该去解决什么层次的技术债务，不能去推诿和落井下石，在你手中的技术债务就应该当成自己欠下的技术债务来解决，这样才能持续性的做好自己分内和分外的事情，工作起来才能得心应手。作者回复: “在你手中的技术债务就应该当成自己欠下的技术债务来解决，这样才能持续性的做好自己分内和分外的事情，工作起来才能得心应手。”👍👍 说的真好，偿还技术债务，从自己做起！
2019-04-236
Joey请教宝玉老师： 1.如何更好地推广SonarLint白盒扫描工具。 2.如何要求各开发团队更好地，有效地做代码走查，而不流于形式。（我们现在使用Gerrit） 3.如何要求开发人员有效实施单元测试。 我们一个研发部门人数1000左右，由于历史原因，大家根本不重视单元测试、代码走查以及白盒扫描，或者说这只是留于形式，走流程。久而久之，开发人员觉得我不关心这些东西，也没有出现很严重的事情啊，反正有测试人员对质量把最后一道关，我为什么要浪费时间呢？ 但是现在随着业务越来越多，系统越来越复杂，要从研发过程上加强质量，面临以上三个很突出的问题，请宝玉老师支支招，多谢老师解答！作者回复: 这种开发流程问题肯定还是要自上而下推才能推得动。 我觉得首先应该先找一两个小项目组试点，摸索出一套适合你们的最佳实践，形成流程规范，比如说基于Github Flow，把CI（持续集成）环境搭建起来（如果没有的话），把你说的SonarLint、自动化测试加入到CI流程中。 再就是逐步扩大范围，在更多项目组推行最佳实践和流程规范，并且改进流程规范。 最后就必须要借助行政手段强制推行了。 因为我对你的情况不是很了解，先简单回复一下，你有后续问题可以继续留言。
2019-05-164
纯洁的憎恶技术债务不全坏，与金融债务一样，需要具体问题具体分析。轻率&有意的债务要避免。谨慎&有意的债务有收益。轻率&无意的债务要警惕。谨慎&无意的债务要改变。识别债务防患于未然。根据成本收益分析，决定重写（一次性还款）、维持（只还利息）还是重构（分期付款）。作者回复: 突然感觉我们是金融行业从业者😄
2019-04-234
白泗小林产品经理讲完产品文档，留给开发的时间根本不够写文档。相信很多小公司的开发都有同感作者回复: 很多开发人员对于开发设计文档有个误区，认为文档需要有特定格式，需要美观大方，文字优美，插图形象生动，所以裹足不前，不敢写不会写，或者认为时间不够。 其实开发文档最核心的两个目的： 1. 帮助你自己想清楚 2. 帮助别人搞清楚你是怎么想的 搞清楚目的后，怎么写反而不重要，只要能让你自己把设计想清楚，只要能让其他人搞清楚你的想法，至于是画图还是文字还是手书，都不重要。 比如我在拿到一个需求后，会写一个简单设计文档，一般就用Keynote写几页Slides，没有多少文字，花几个框框图表达模块关系，在找相关人约着开个会，就Slides讨论一下，就能把很多问题确认下来，并不需要花多少时间在文档上面。
2020-03-153
Mr.Chen看了几次项目管理金三角后，发现有意思的是，这个图里，时间和成本的缩减，都会引起三角形面积减少，也就是质量变差，范围缩减也会引起三角形面积减少，但它应该是提升质量吧。😄作者回复: 这个三角形，更多的是反应各个因素的影响关系，不完全对应几何上的反应 😛
2019-07-253
果然如此最近遇到一些Bug 数量越来越多技术债务，而且都是同一类问题，因为数据准确性关系到月月末统计工资，所以临时解决方案是修复已知的错误数据。由于这个模块以前是其他同事做的，我在本周花了几天时间研究，得出结论是原设计没考虑到业务变化后的相关联数据如何跟着同步变化，导致了很多相关统计报表错误。 这个债务临时解决办法只是头疼医头脚疼医脚，最终还要抽出时间根本解决数据同步变化问题。作者回复: 👍技术债务最重要的一步就是识别出来问题在哪，然后再有一个稳妥的方案。 你这个问题，我建议你先把相应的自动化测试代码补上，然后保证有一定测试覆盖之后，再逐步用新模块替换旧模块，最终完全替换。
2019-04-263
WL老师能不能具体讲讲重构有哪些原则和要注意的地方，感觉一直得不到要领作者回复: 重构的要领我觉得两点： 第一：你要先写一部分自动化测试代码，保证重构后这些测试代码能帮助你检测出来问题 第二：在重构模块的时候，老的代码先保留，写新的代码，然后指向新代码，或者用特定开关控制新旧代码的指向（这样上线后可以自己先测试，有问题也可以及时关闭），然后让自动化测试通过，再部署测试，新代码没问题了，删除旧代码
2019-04-233
hua168像我们公司有老系统，十年了，程序员都换完了，用perl写的，基本上都没有几个人懂perl 无法重写、也无法重构怎搞？作者回复: 需要综合评估一下，如果很稳定也不重要，那就别动了，补一点文档。 如果很重要又不稳定，建议对其立项，用开源产品或者商业产品或者新技术实现同样的需求，然后换掉。
2019-04-282
