这是一个创建于 281 天前的主题，其中的信息可能已经有所发展或是发生改变。
技术债务是指开发人员为了加速软件开发，在应该采用最佳方案时进行了妥协，改用了短期内能加速软件开发的方案，以至于未来给自己带来额外的开发负担。
软件工程师 Ward Cunningham 首次将技术的复杂比作为负债。 简单来说，技术债务类似于金融债务，软件开发就像是去银行 “贷款”，而技术债务就像是贷款的“利息”。“利息”是需要以未来额外的时间来偿还的，所以重构才相当于支付“本金”。
表面上，软件的应用程序看起来质量很高且状况很好，但是这些问题却隐藏在下面。如果没有很好地管理并设法降低这些技术债务，那么程序编写和维护的代价最终将会超过它对客户的价值。
这些技术债务到底是从何而来？为什么某些团队在 Scrum 开发过程中会导致技术债务的积累呢？我们该如何解决技术债务呢？
一、 Scrum 环境产生技术债务的原因
为了满足 Sprint 冲刺目标、发布功能和不断变化的需求，开发人员可能会更加关注短期收益，而忽视长期代码质量和可维护性。 因此，开发人员会在必要的修改没有完成时就匆匆发布，权宜之计在不知不觉中就产生技术债务。
技术债务会导致 Scrum 团队产生生产力下降、代码质量下降、项目风险增加等多种影响。 虽然在下一个迭代中偿还技术债务是可行的，但团队需要关注每个迭代的新需求，不可能永远都在救火。
那么我们该如何偿还技术债务？或者该如何避免产生技术债务呢？
二、技术债务如何还债
在 Scrum 环境中，偿还技术债务是一个重要的任务，以确保软件的可持续发展和质量。下面是一些偿还技术债务的方法：
- 识别技术债务
首先，团队需要识别和记录技术债务。这可以通过代码审查、静态代码分析、系统性能监测等方式来发现潜在的问题和改进点。技术债务可以包括代码质量问题、未完成的任务、过时的技术选择等。
- 优先级排序
一旦技术债务被识别，团队需要对其进行优先级排序。这可以基于影响业务价值、风险和复杂性等因素来确定。团队可以与利益相关者协商，以确保优先处理对业务和用户最重要的技术债务。
- 制定计划
根据优先级排序，团队可以制定一个技术债务偿还计划。这个计划应该包括具体的任务、时间估计和分配给团队成员的工作量。团队可以将这些任务添加到产品待办列表中，并在每个迭代中分配一定的时间来处理技术债务。
- 项目结构化
减少技术债务的有效方式之一是通过更好地构建项目来最大程度地减少技术债务。使用项目管理工具（如禅道）可以帮助团队跟踪开发状态，保持进度，并提高团队的整体协作效率。
- 自动化测试
在偿还技术债务的过程中，团队可以优先考虑编写自动化测试来确保代码的正确性和稳定性。自动化测试可以帮助团队及时发现和解决问题，并减少未来的技术债务积累。 禅道团队自研了开源的自动化测试框架 ZTF 和通用数据生成器 ZenData ，加上禅道项目管理软件构成了专业的自动化测试解决方案，可以帮助用户实现规模化自动化测试，提升测试效率。
- 分配固定重构时间
重构相当于贷款需要偿还支付 “本金”，所以 每个 Sprint 中分配固定的时间进行重构。这可以是若干小时数、若干故事点数，如一个团队可以为重构预留 30 个小时、4 个故事点等。在 Scrum 环境中，持续改进是一个核心原则，只有定期回顾和评估偿还技术债务的进展，才能够一定程度上避免技术债务带来的消极影响。 通过遵循这些策略， Scrum 团队可以有效地管理和减少技术债务，从而产生更高质量的软件产品并提高团队生产力。
三、写在最后
正如电影《无间道》所说 “出来混，迟早要还的”，技术债是无法避免的，只是产生技术债务多少的问题，但如果不及时处理技术债务就会产生破窗效应。 团队欠下太多技术债务，必然导致影响后期的代码质量下降，这也会间接影响到完全没有关联的其他用户故事的研发。
因此，从现在开始把偿还技术债务纳入待办事项中，把避免产生技术债务作为工作准则！
 |
1
tikazyq 281 天前
将技术债保持在可控范围内，最开始就要在开发团队中养成好的习惯：
1. 代码规范（ Coding Standard ） 2. 自动化测试（ Automated Testing ） 3. 代码审查（ Code Review ） 4. 健康迭代速度（ Healthy Velocity ） 否则，就会导致屎山、加班、甩锅之类的有毒文化 |
 |
2
42joker 281 天前  1
更可悲的是,新入职的员工就要面对这些屎山,最后还要被负责人说跟不上进度
|
 |
3
wu67 281 天前
说的这一堆, 是针对有规范、团队有足够人手、老板对技术有一定程度的认知和对重构耗时有一定程度的容忍的前提下的说的, 不然还不如提桶跑路来得快, 公司活不活得了那么久还不一定
|
 |
4
maggch97 281 天前 via iPhone
赚钱就能解决所有问题，没见过哪家公司是被所谓技术债拖累死的。
|
 |
5
shyrock 281 天前 1
写这么多还是在考虑怎么擦屁股，为什么不是从根本上解决导致债务问题的非理性冲动和妥协呢？
就算形势所迫必须妥协，也应该列入待办工作，而不是时候再来识别债务吧？ |
 |
6
jones2000 281 天前
只要项目能持续盈利， 前期技术债务在多也不怕。 业务模式跑通，重新招一波人重构都没有问题。 务实才是最重要的。整一堆流程，有什么用，不赚钱就是不赚钱。
|
 |
7
twofox 281 天前 2
楼上说的太轻松了，技术债是无可避免的
一行代码写下去的时候，你认为它可能会在将来会成为技术债，那它 99%的可能会成为技术债 但是你觉得成就满满，认为自己的代码写的精炼、健壮，简直完美无瑕了的时候，这部分代码以后就不会成为技术债的一部分吗？ 不是，随着业务发展，可能回过头来看，这部分代码不够灵活，不能满足业务需求了。但是耦合度已经太高了。 你改起来很麻烦，这就是技术债 实际情况更多是，进度催得紧，代码敷衍一下吧，以后优化 新技术没用过，先用旧的技术栈过渡一下吧 实习生新来的，代码写的一坨答辩，但是没办法了，没空帮他 review 技术债实际上还是**业务变化**导致的，你一个产品做出来，以后不再迭代了就没有什么技术债可言 |
 |
8
1145148964 281 天前
好的代码真的意味着自己可以随时被替代。
|
 |
9
param 281 天前 via Android
其实是要平衡的，不能光满足业务，也不能光追求技术完美。这之间的权衡是种艺术。要去评估每项的「利息」，看看哪些债务可以借，哪些不该借，哪些该还了。
|
 |
10
shyangs 281 天前
@maggch97
Netscape Navigator (网景导航者)比 IE 5.0 慢。IE 獲得第一次瀏覽器大戰勝利。 Nokia 抱著 Symbian 不放，Nokia 公司沒倒，但賣出手機業務和品牌。 |
 |
11
archxm 281 天前
花式宣传自家产品
|
|
14
maggch97 281 天前
@shyangs nokia 手机业务的失败是他的商业模式造成的，同样他的技术也是服务他的商业模式。
功能机到智能机时代为什么全球厂家集体洗牌了，没有一家传统厂商幸免？因为本质是整个商业模式都变了。不要总是盯着微观的技术。 |
|
16
shyangs 281 天前
@maggch97
你錯了，傳統廠商華為活了下來，華為在 2003 年成立了手機業務部. (那時候 Android 還沒出了，因此早期華為ˋ是傳統手機) 你已經開始瘋狂轉進了。下一步你要說華為是國家支持的? |
|
17
shyangs 281 天前
@ZZ74
google 英文文章 "Technical Debt" + "Symbian". 老外說到技術債的經典案例. https://www.flashover.blog/posts/technical-debt |
 |
18
morgan1freeman 281 天前
@twofox 本质上这还是一个商业成本问题，国内人力价格便宜，给 1 万，让你去屎山里面吃，你吃不？你肯定吃，让你把屎山 翻新一遍都行，国外人力成本高，重写代码不易，当然要搞规划，提出技术债务这个概念，国内哪有这个概念，历史遗留代码，我觉得新码农们都应该去烧香，要不是这些狗屎代码，哪里来的这么多的代码工作
|
|
19
morgan1freeman 281 天前
|
 |
20
royalknight 281 天前
学到很多，感觉现在要陷入债务深坑
|
|
21
param 281 天前 via Android
@morgan1freeman 你这样极端的思路肯定不行。很多技术债的偿还「利息」可能都不止 6 倍，而且债务是「复利」的模式指数级增长的，对于很多情况，人力再便宜都划不来。
|
|
22
twofox 280 天前
@morgan1freeman 成本是能不能解决技术债的问题所在。快速迭代的商业竞争环境才是罪魁祸首
今天竞品新出了两个功能，你下个版本就得抄进去，而且不能耽误自己原有的功能开发。 在这种进度特别赶的情况下，你给多少钱给程序员，他们照样会写出带有技术债的代码 而解决技术债就要投入成本，包括人力成本、时间成本。很多项目要综合考虑的。时间充足，又不缺钱，技术总监就可以让你花时间去重构代码 如果是时间一直都很赶，就算是不怎么花成本，他都不让你进行重构 |
 |
23
xuanbg 280 天前
作为成年人，我们的选择当然是：不还技术债。甚至直接否认技术债的存在。
|
Select Language