评论专栏:Kyle Brown

偿还技术债务

Comments

系列内容:

此内容是该系列 # 部分中的第 # 部分: 评论专栏:Kyle Brown

敬请期待该系列的后续内容。

此内容是该系列的一部分:评论专栏:Kyle Brown

敬请期待该系列的后续内容。

创建技术平衡

去年,美国人的消费习惯发生了巨大的改变,这一改变是我们大多数人始料未及的,至少没想到它会发生在我们这一生中。几年来,美国的个人储蓄第一次开始出现增长而不是减少,这标志着消费者最终开始认识到您是不能只借 不还 的。相应地,我希望整个行业也能认识到,同样的规律也适用于技术债务,正如对金融债务一样。

这个比喻对某些人来说也许有点难以接受,但事实上,这个观点早在 15 年前就第一次由 Ward Cunningham 正式提出,2005 年由 Joshua Kerievsky 进一步发展(详见 参考资料)。

简单来说,当一个开发团队为了完成其他项目,想要推迟完成一项重要软件开发时,就会出现技术债务。虽然常见的打算就是他们会稍后回来完成这个延迟的项目,但这些打算往往没有付诸行动。这些被推迟的活动可能是像编写文档这样基础的工作,或者像修改一段代码使其更容易理解或者维护这样棘手的工作,再或者是更新一个过时的设计文档。

最近几个月来,我一直在处理几个客户解决方案。其间我感觉我更像一个消费者债务顾问,对象是具有过多抵押贷款,不断提升信用卡余额,还有个即将出世婴儿的夫妻。每个案例中,虽然几乎被技术债务压倒,但我们总不得不找到某些方法来减少债务 —— 同时继续开发新的特性,不断前进。我通过一系列实践所得出的步骤和信用顾问建议他的客户所采用的步骤基本一致。

因为有那么多项目都面临着技术债务问题,就让我们检查这些步骤,看看它们是如何应用的 —— 以及它们是怎么帮助我们的。

  1. 搞清楚您欠了多少债务

    清算您的状况是第一步,也是最重要的一步。一旦您的团队意识到技术债务是必须偿还的(这当然是不容易实现的,而且还需要和业务部门进行合作),您就不得不算出事实上您到底欠了多少债务。我找到的完成这项工作的方法就是对代码和设计进行一个从顶层到底层的审查。

    从查看您的设计文档开始:它是否需要更新?它是否获取了您设计中最重要的部分?然后,您或许想要通过检查代码的哪个部分给您造成最大的麻烦,来对代码进行一个有优先排列的审查:哪部分是最难修改的?哪部分出错率最高?哪部分对您的业务最重要?回答这些问题会帮助您列出为了改善状况,您必须进行的活动。

    您的系统还有比代码和文档更重要的问题,而且其它这些部分也会造成技术债务。例如,操作性债务:您是否正在类似 IBM® WebSphere® Application Server 这样的平台软件的最低标准上运行?您的运作团队是否正在费时费钱地手动进行那些应该自动进行的任务?您是否在适合的位置设置了监视,能在问题导致网站故障之前将其发现,而不是把时间浪费在事后分析上?

    最好的方法就是,请外部的专家来帮您清算项目状态,仅仅根据您的解决方案的优点做出一个估计,不受办公室政治或者任何个人和代码关系的干扰。

    最后的评估需要包括根据优先级进行排列的需要修改部分的描述,还有如何进行整改的建议,所列出的每个整改项目的成本估计。掌握了这几个方面以后,您就可以开始和业务所有人进行磋商,讨论哪些债务需要偿还,按什么顺序偿还。

  2. 停止制造新的债务

    虽然步骤 1 是这个大计划中最重要的一步,步骤 2 常常导致业务方面最困难的讨论。这个过程中最困难的部分就是学会改变您的组织文化,这样您就不会积累超过自己合理服务能力的债务。参考先前的金融债务类比,改变您的消费习惯,只用信用卡购买您所需的(而不是想要的)东西是很困难的一课,同时也是最难养成的习惯。

    想要解决您在步骤 1 中确定的问题,您必须花点时间来实施这些改变。这就意味着在这些问题解决之前,您需要先搁置新的开发项目。做到这点没有十全十美的方法,无论您选择用什么方法都需要和业务进行协调,来保持技术债务减少和新的开发项目之间的合理平衡。这里我会介绍一些曾对很多团队都有效的策略:

    • 债务减少活动和您正在实施的客户案例结合在一起,作为一个敏捷开发方法的一部分。和业务部门进行协作,来保证步骤 1 中确定的活动已经包括在每个开发周期中。麻烦的部分就是平衡债务减少活动和涉及相同代码区域的新开发活动。例如,假设您正在开发一个电子商务网站,然后您发现您的大部分问题都在签出组件中。您或许想要仅在那个范围内推迟新的开发,同时在该部分内偿还技术债务(进行代码重构,更新文档等等)。在这种情况下,进行签出改变的同时,增加新的促销或者改变您的产品页面会是有效的新开发活动。
    • 采用一个测试策略。如果您构建的基础设施是为了维持两个网站 —— 一个是您的主网站,另一个是 “测试” 网站 —— 那么您就能够在测试网站上进行新的开发,同时重构主要的代码流。这么做的好处就是不会降低任何新开发的速度,但是,随后当这些测试网站的更改必须和主网站集成的时候,会产生更麻烦的集成成本。
  3. 选定您的债务减少策略

    有了债务减少策略,您可以考虑两种不同的方式来确定您的 “偿还方式” 的优先顺序:

    • 第一个可能的策略就是类似于 “最高利率优先” 的方法。在金融领域内,这个策略意味着您首先要偿还那些利率最高的信用卡,因为它们是让您花费最多的。在技术世界里,这就意味着您首先要着手的任务是有最大影响力的那个任务。把那些任务解决掉,通常意味着为其他改变清理了道路 —— 还可能在性能,可维护性等方面提供最大的回报。
    • 另一个策略就是 “最低余额优先” 的方法。在金融领域内,这就意味着首先要偿还那些余额最低的信用卡,这可以让您获得一种成就感,觉得已经迅速取得了某种实质性的进展。在技术债务方面,这就意味着首先处理那些工作量最小的任务。如果您必须使业务或者管理部门信服偿还技术债务的价值,这个方法也是非常有效的。或者您的公司文化非常看重结果,展示快速的进展对于为更大的努力维持资金非常重要。
  4. 严格执行计划

    这里的关键就是将正在进行的债务减少作为一项长期的活动。这不是一朝一夕的活动;很多公司因为最近的流行语,比如重构,而变得很失望(参见 参考资料),因为他们希望从那些长期投资角度来看最好的过程中得到短期效果预期。不可避免的事实是,您经常会造成新的债务;解决技巧是确保您可以合理地偿还债务,而不是任其积累。

  5. 跟踪和重估您的进展

    最后,您需要能够报告债务偿还活动中取得的进展。获取指标也是很重要的,它们能帮助您向业务和管理部门证明花费在这些项目上的时间是合理的。例如,您需要对代码进行几次重构才能改善其性能;掌握正确的数据,显示重构是如何改善用户体验,这也是很重要的。同样地,跟踪您将新特性添加到一个简化代码基的速度进展,这也是一个很重要的指标,它可以向业务部门显示其价值。

当然,跟随这些步骤不能全部解决您的所有技术债务,但是它们至少能使您有条不紊地确定需要做什么,这些改变会给这个开发流程带来什么样的价值,以及它们解决问题的效果如何。如果您能持续进行这项工作,那么您就应该可以使您的开发工件更易于维护,使您的开发流程更容易进行。

致谢

作者感谢 Rachel Reinitz 给本文提供有见解、有帮助的评论。


相关主题


评论

添加或订阅评论,请先登录注册

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=WebSphere
ArticleID=490378
ArticleTitle=评论专栏:Kyle Brown: 偿还技术债务
publish-date=05202010