14 | 质量与速度的均衡：让“唯快不破”快得更持久
葛俊
该思维导图由 AI 生成，仅供参考
你好，我是葛俊。今天，我来和你聊聊团队可持续性的快速开发，怎样才能让“唯快不破”快得更持久。
最近几年，一提到开发，很多人想到的都是“天下武功，唯快不破”。也就是说，开发过程越快越好，越快越有竞争力。这的确是软件开发，尤其是互联网行业软件开发的不二法则。也正如我在前面文章中多次提到的，快速开发可以快速得到用户反馈，更快地验证用户价值假设。无疑，这是高效开发的重要原则。
因此，我们在实际工作中，往往会为了快而选择各种“捷径”。比如：
要开发已有功能的一个相似功能，因为时间很紧就先 copy & paste，保证功能按时上线。
需要在一个函数里增加功能，这个函数已经有 800 行了，加上新功能后会有 1000 行。重构这个函数是来不及了，先把功能加上去再说。
说是“捷径”，是因为这些都不是最优解，有点儿投机取巧。它们的确能让我们在短期内保证快速交付，满足业务发展需求。但如果没有任何补救措施的话，时间长了我们就再也快不起来了。
比如，“copy & paste”方式的编程，会导致后续添加功能时，需要在很多地方做类似修改，工作量大且容易出错。再比如，无视函数变大的操作，会导致后续的修改、调试异常困难。
这些问题都会成为开发工作中的技术债，也就是在开发产品或者功能的过程中，没有使用最佳的实现方法而引入的技术问题。无疑，这些技术问题会为将来的产品维护和开发带来额外开销。只有正确地处理技术债，才能让我们的研发持续地快下去。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
团队快速开发中的技术债问题是软件开发中的重要议题。文章提出了处理技术债的两个基本原则：利用技术债的好处，但在适当时候偿还适当部分的技术债；控制技术债，持续重构，解决高优先级技术债。此外，文章还提到了识别技术债的方法和处理技术债的具体步骤。通过案例分析，文章强调了处理技术债对公司业务发展的重要性。文章内容丰富，为团队快速开发和技术债的处理提供了有益的建议。
仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《研发效率破局之道》，新⼈⾸单¥59
《研发效率破局之道》，新⼈⾸单¥59
立即购买
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(10)
- 最新
- 精选
技术修行者
破产保护（bankruptcy protection）： 破产保护是指不管债务人是否有偿付能力，当债务人自愿向法院提出或债权人强制向法院提出破产重组申请后，债务人要提出一个破产重组方案，就债务偿还的期限、方式以及可能减损某些债权人和股东的利益作出安排。这个方案要给予其一定的时间提出，然后经过债权人通过，经过法院确认，债务人可以继续营业。这就是重整的概念，在中文中又叫破产保护。 对于技术债务来说，当积累到一定程度并严重阻碍正常开发的时候，必须要采取和破产保护类似的策略，梳理所有技术债务并做合理的计划，按照优先级去偿还这些债务。 记住一句话，出来混，总是要还的。作者回复: 写的很棒！！ 不过似乎大家都忘了到还有一个借了债不用换的极端情况，比如一个实验项目，或者一个马上要被替换的项目。借再多的技术债也没关系。
2019-09-2316
Raymond吕这篇开眼了，以前只知道技术债就是坏的，学完这节课，才明白需不需要还债要看项目的阶段和组织的意识。不能一概而论，良性的负债有利于快速扩大边界，尝试新方向。作者回复: 我才开始做开发的时候也是觉得技术债都是坏的 ：）
2020-02-178
Jxin
1.试点项目，不怕债务，失败直接不用还。前提条件，有强力的中台背景支撑低成本试点。 2.个人补充一点。债务不是理由。一个项目，要抢站市场，需要快速落地。产生债务是必然，但产生100w的债务和产生1000w的债务是两码事。合理的架构设计和分层，基本的代码规范还是要保证的，做这些并不会拖慢业务落地。但多少人，一句为快速落地牺牲质量，就肆无忌待的瞎搞，最后项目缓慢，失败都归于债高。成功又以债高为由要成本重写。 3.互联网公司发展太快，高层水准层次不齐。作者回复: > 1.试点项目，不怕债务，失败直接不用还。 是的 > 2.个人补充一点...合理的架构设计和分层，基本的代码规范还是要保证的...瞎搞... 补充的很好！！
2019-10-044
李双敢于留债，并定期偿还技术债！作者回复: 简明扼要！
2019-09-233
寒光质量和速度，两手抓，两手都要硬。只要速度不要质量走不远，只要质量不要速度走不动。 我认为技术债也有申请破产保护的福利，因为业务如果发展起来了，就有钱去做重构，把之前的推到重来。而如果因为怕欠技术债，速度没跟上，错过了业务的发展，再好的质量也是白搭。作者回复: 👍👍👍
2019-09-232
bidinggong技术债就是在开发产品或者功能的过程中，没有使用最佳的实现方法而引入的技术问题。正确论述，忽略的问题迟早要还的作者回复: ������������
2020-10-231
丛丛丛前段时间接手了一个项目，技术债相当严重，当时觉得一定要解决技术债的问题，经过讨论，开发团队决定每周要解决100个历史问题单，但实际操作的效果特别不好，因为新的业务需求不断涌上来，开发完以后又会产生新的bug，版本上线后，又产生了新的技术债。 读了您的文章以后，才发现之前的策略是错误的，应该有效的去管理技术债，而不是消灭它。bug bash 很不错。想要了解更多的细节。 另外，关于技术债的破产保护，我认为在实际中是不存在的，所谓破产就是这个项目没有了，资源就会释放掉，怎么还可能去修复遗留的技术债呢。但是从另一方面，遗留的技术债并非完全没有价值，虽然提不上破产保护，但是条件允许下，应该对遗留的技术债进行回顾和分析，考虑它们是怎么形成的，哪些问题在将来还是会存在。这样的回顾是帮助我们在未来做新的项目时积累经验，有些情况就不会重蹈覆辙了。作者回复: Bug bash 基本原则就是一段时间停下feature work，大家集体专注bug修复。可以参考这个文章：https://medium.com/@changbot/running-an-effective-bug-bash-317fafa9d963
2020-03-091
兴国偿还技术债同时也对研发人员提出了要求，要不断的学习新知识，不断优化代码，不断结合自身业务优化架构。所以平常不仅要低头拉车，还要经常抬头看路。作者回复: 是的。如果有环境，我觉得大部分开发人员应该还是愿意学习和提高的。
2019-09-27
麦兜技术债务的累积也是产品生命周期的末期，一个新产品的开端作者回复: 如果产品不维护了，的确是这样的。
2019-09-26
墨灵的确如此，重点认清自己有多少债务，又有多少债务是急需还清的，在保证生产力的同时又不至于被债务压垮。2020-03-241
收起评论
