技术债务是对业务功能缺乏真正的理解 -daverupert.com

20-11-07 banq

技术负债概念提出者Ward Cunningham认为:长期开发一个应用程序时,我们是通过不断添加功能进行的,但是却从未对其进行重新组织以反映我们对这些功能的理解,那么最终该程序将根本不包含任何理解,因而在其上继续工作编程所付出的努力将花费越来越长的时间。

知识管理在组织中是如此重要,但是他们很少经过关键的重构来反映当前的理解。

必要时需要进行大规模重构。如果组织的营业额足够大或产品中的功能不断增加,那么进行重写是最好的选择,这样您的团队对代码有个整体的了解。不能指望人们在繁忙的编程中会实现难以理解的需求,或者在已经离职人的遗留代码中提高工作效率。

 

使用一个通俗解释:如果吃完饭不洗碗不打扫厨房,那么慢慢地就吃不到下一顿饭,重构就是洗碗。

 

技术债务不是写得不好的代码:您编写代码是为了反映您对问题的*当前*理解。如果这种理解是“部分的”,那么您将承担债务,即使如此,您仍会交付软件(以了解更多信息)。但是,您必须偿还债务:您必须将新的知识纳入软件。

这就催生了两个阶段,第一个阶段是你部分理解业务的代码,第二个阶段是你偿还债务纳入新理解的代码,您必须满足第一个紧迫的阶段以后(先交付原型获得客户认可),才能获得后续第二个阶段所需的经济资源(客户肯定你没有走错方向,提供资源让你继续按照这个思路走下去)。因此,您需要做出战略决策,为第一阶段编写次优设计。之后,您可以偿还债务并在第二个阶段之前改进设计。

关键是必须*偿还债务。您支付的能力取决于代码的干净程度(因为您需要重构)。

  • 干净的代码是技术债务的前提。
  • 过度耦合的无法维护的代码库不是技术上的负担。只是一团糟。

但是,根据精益起步创业(Lean Startup)的方法,这种债务对于创业起步公司几乎是强制性的。但是正如您所说,对于科技创业公司来说,有必要编写简洁的代码以偿还债务。 

 

对于开发人员无法消除的诅咒是:您只了解代码,但您却很少是领域专家,因此当按期限要求时,您会假设有关领域的知识,但是这种第一性假设后来被证明是错误的...

 

获得领域的经验确实是一个挑战,并且可以说是构建高质量软件的关键之一。这就是为什么人们喜欢强调领域域驱动设计(DDD)原因。

经验分享:干净整洁代码(clean code)的特点

                   

2
猜你喜欢