对技术债务(Technical Debt)的理解技术债务在研发领域类似于“金融债务”的概念,大部分情况下是说因为人为妥协,系统的设计和实现没有遵循最佳实践,所以虽然在短期做到了快速交付,但也制约了系统未来的可扩展性,并且埋下了稳定性的风险隐患。就好比你信用卡分期消费,虽然可以立刻满足自己的购买意愿(得到眼前的好处),但同时也会背上一定的负担,在未来必须得偿还 接触“技术债务”这个概念大部分是读了《重构》这本书,Martin Fowler 曾发表过他对技术债务的定义,即“技术债务象限”。他根据债务产生时的原因,将技术债务从两个维度分成四个象限:即有意(Deliberate)的还是无心(Inadvertent)的,谨慎(Prudent)的还是草率(Reckless)的 简单来讲,就是开发人员是否清楚接下来的设计与实现会造成未来的技术债务,以及在做决策时是否经过慎重的考虑。从过往的经验来看,技术债务“是否已知”是比较关键的,因为往往最难的不是解决问题,是根本不知道这里有问题,而下面两种情况在实际工作中最为普遍
什么是能力不足呢? 比如开发者编写了低质量或者有潜在风险的代码;对系统的实现和运行不了解,重复代码被大量构造,缺少抽象与沉淀;缺少完善的开发机制和流程把控,比如测试、文档等方面做得不到位…… 交付压力(技术妥协) 则被很多 Leader 认为是产生技术债务最关键的原因,因为项目很复杂或排期压力,不得不在系统的架构设计与代码实现上作出妥协,选择最容易的方式而非最好的方式。甚至会跳过方案的详细设计,直接开始 Coding,不深究代码风格、标准、最佳实践,更进一步则会压缩测试方面的时间与投入,只为了尽早上线 而当技术债务产生后,因为系统和项目的惯性,债务会积累并使系统散发出一些“坏味道”,这些坏味道有很多个方面,列了三种最常见的情形,如果你负责的系统中出现类似的情况,那你需要警惕了 为什么你要重视技术债务?1. 影响系统扩展和需求交付结合技术债务产生时的情况,我们不难发现,随着技术债务的累加,系统的负担也不断增加,糟糕的设计与实现导致系统变更时需要处理的代码、考虑的问题越来越多,影响最大的是系统扩展和需求交付 其中对系统可扩展性影响最大的,大部分和架构以及系统链路的设计有关(比如对业务代码缺少抽象,模块间过度耦合、服务间职能边界不清晰等)。当新业务需求出现时,这些问题的改造和修复成本很高,并且大部分问题积重难返,这就使系统迭代非常困难,最终影响项目进展使系统无法按期交付。这也是技术债务对研发而言,最大、最主要的影响,需要你有足够的认识 2. 恶性循环导致人员流失除了影响系统扩展和需求交付之外,技术债务还会导致人员流失。接触的大部分研发者最喜欢的就是搭建从 0 到 1 的新系统,因为没有“历史包袱”可以轻装上阵,最大程度在设计和实现上完善它 接手一个旧系统就不一样了,这样的系统往往运行了很久,出问题影响大,又因为人员变化多、文档缺失严重,谁也说不清楚系统的架构,最终只能一行行读代码来结合业务场景进行理解。并且很多看上去不合理的实现,也许会存在特定的原因,往往想改又不敢改。等你梳理清楚所有的关联与影响后,又发现工作量太大改不动,只能像打补丁一样维持着,等到某些外界因素(组织分工变化、重大事故等)发生变化导致问题不能再拖延时,再通过一次大的重构(实为重做)来解决 不过,与其说研发人员苦恼的是旧系统,不如说是其中沉重的技术债务,它会导致系统未来的迭代愈发困难,迭代困难又会导致交付压力增大,所以只能再次做技术妥协以实现业务优先,这样就会进入恶性循环,研发人员就好似修补一座破屋,每次修好一点,下一次迭代时就被破坏更多,随着时间持续和系统腐化的加剧,研发人员开发的难度越来越大、风险隐患越来越多、自身能力的成长与提高也很有限,自然就容易导致人员流失 所以你一定要清楚,技术债务的恶性循环会影响开发团队的生产力,并降低团队的士气和成员的驱动力,而低生产率导致团队只能优先交付功能,这就推迟了技术债务的解决,从而进一步增加技术债务 如何从循环的债务困境中突围而出?1.债务的 Owner 是技术 Leader大部分技术 Leader 认为是业务节奏导致了技术债务的产生,因为研发资源永远不会 100% 充足。所以一些技术 Leader 觉得委屈,明明业务压迫技术导致的问题,最终还要自己来承担责任 要想解决清楚一个问题,就必须先定义清楚这个问题。 所以我们要先定义清楚技术债务与技术Leader的关联,针对“交付压力 - 技术妥协 - Leader 责任”这个技术债务形成的关系链 我们会下意识地觉得交付压力导致的技术债务和自己无关,因为我们并不是技术债务的“始作俑者”。任何一家成长中的公司,都会存在技术资源与业务发展的矛盾,如果矛盾消失,说明公司业务增长放缓,甚至陷入瓶颈,甚至导致技术资源过剩要裁人。这肯定不是我们追求的结果,大部分情况下,我们追求的是技术与业务之间的 Balance,将它们控制在一个动态适配的状态 当“交付压力产生技术债务”变成一个普遍的现象,而非某种特例后,我们应该认识到这就是发展中的一部分,而解决这类问题,是你的责任和本职工作之一。 换一个角度来说,你是整个团队中最理解技术债务影响、最懂系统架构与迭代能力的人,你不解决这类“技术问题”,难道要靠产品、销售、运营或者管理层来解决吗? 所以非常不建议你一谈到技术债务,就下意识地路由到“交付压力太大、排期太紧、产品设计太复杂”等理由上,这样的“甩锅”只会将你从解决问题的决策者变为服从安排的执行者,不但对解决问题没有任何帮助,还从另一个方面证明了自己失职 那么要想解决技术债务,你需要找到技术与业务的平衡点,经验是“内外双修”
面对选择题时不要只看到可选项,要永远寻找第三条路。 如果实在没有其他选择,在技术妥协的同时,做好沟通,让协作方明白方案的临时性以及对未来的影响,争取到承诺在未来给你足够的空间解决这些问题 2. 通过 CheckList 识别债务除了明确债务的 Owner 是自己之外,技术债务的度量一直是个难题,因为没有很好的量化方式,所以债务的识别以及收益 ROI 的计算都没有什么标准。所以,我们在处理技术债务的第一阶段就是要识别出技术债务,将其从看不到的未知隐患转变为可视的已知问题 学会习惯根据系统的情况,建立一个债务 Review 的 CheckList ,并且不断完善。技术债务从表象上可以做一些细分 通过现象我们就可以反推出一些导致现象的原因,将这些原因结合系统的架构进行分类,就会形成一个个具体的关注点。这些关注点往往是结合我们之前踩过的坑、发生过的问题,以及编码、架构上广为遵守的一些最佳实践所形成的,这样你就可以制定出一个较为详细的 CheckList 用以具体的债务识别 3. 有计划地分级偿债通过 CheckList 将技术债务作出识别后,往往要解决的问题非常多,但是我们又几乎无法停止需求迭代只做还债这一件事,所以此时要对技术债务做一个“轻重缓急”的区分,以确定需要处理的优先级。下面总结了一些分级原则
总的来说,通过对技术债务进行分级,实质上也是一个问题分治的过程,将大问题切分成一个个小问题,这样就可以将它们加入日常的迭代中,形成一个分期偿还技术债务的计划,逐步减少技术债务,减轻负担让团队与系统可以轻装上阵 4. 正视债务做好预防除此之外,预防永远胜于治疗,技术债务汇总预防的关键点在于那些“原本未知”的技术债务要逐渐减少,大家对于实现质量的追求不能止步于“测试没有明显 Bug”,写出能运行的代码是不够的,还要易维护易扩展。可以从几个方面着手
5. 一些常见的误区通过 CheckList 做债务识别,然后定期诊断、水平扫描、债务定级、分期偿还来做技术债务的处理,最终在团队认识、机制氛围、资源保障上下功夫做预防,这就是技术债务管理的核心思路 而这个过程中,有一些问题是日常你很容易走入误区的,简单总结了一下几个注意点
总结技术债务和金融债务有很多类似之处,金融借债往往是为了解决当前的资金压力,从而在商业上赢得先机,着眼于未来的长远收益。技术债务往往也出于同样的目的,通过当前适当的技术妥协换取业务更早的交付上线,尽可能与业务的发展节奏匹配,在业务的发展与变化过程中不断完善而非一开始就追求完美 我们并不能将技术债务单纯看作是“不好的事务”,与金融借债在金融领域中起到货币杠杆的作用类似,适当的技术债务对加速业务发展、推动系统演进是有积极作用的。所以完全没必要谈“债”色变,放眼现实企业中,不能说没有债务的一定是三流企业,但是一流企业基本都有合理的负债 但是对于技术债务而言,怎样的债务才是“适当”的,就非常考验你的能力了。金融借债会产生利息,如果定期还款则不会产生太大影响,而如果不偿还的话,不仅有利息还会产生高额的违约金,并且随着不还款的次数增加,还款将会变得越来越困难,最终可能导致企业破产 同样类比到技术领域的系统项目中,大量的技术债务产生的利息就是系统变得难以扩展和维护,而这些问题没有被及时处理就相当于利息和本金没有按期偿还,那么以事故和交付延期为代表的违约金就不期而至了 所以我们谈及技术债务时,既要清楚它的种种弊端,也要具备正视技术债务的勇气。一方面不能过于追求完美导致因噎废食,另一方面也不能忽略或者无限期推迟技术债务的处理,因为随着时间的推移,技术债务会逐渐积累,最终量变引发质变只能通过休克疗法来解决(暂停一切业务进展,系统推倒重来) 以务实的态度来对待技术债务,团队在技术战略上高度重视、在日常研发节奏和项目中寻求战术上的平衡 |
|
来自: conscience6487 > 《待分类》