Understanding technical debt

原文：http://www.nczonline.net/blog/2012/02/22/understanding-technical-debt
翻译：http://yukun.im/news/382

开发一个网站，会有好几个团队参加，产品经理或者市场代表负责功能和设计，用户界面设计师负责视觉效果，最后开发人员负责落实到最终产品。这些团队中，开发最容易被问到为什么这个不能做，为什么这个不应该做，会被问的有些恼火。出现这种情况是因为自觉或者不自觉的，开发人员要处理项目的技术债。

技术债，简单点说就是项目中待完成的技术工作。这种事情很难量化，通常只是在特定的时间里存在一个或者几个开发人员的脑子里的东西。一开始会跟经理估计要花几个小时或者几天还技术债，之后，每一个技术决策都伴随着某一种技术债。

截止时间很少跟开发时间对得上，所以开发一路伴随着技术上的折中妥协，先用短期的解决方案跑起来，以后再回头重新写个长久的方案，不了解的人会觉得这样做项目有些草率，但是只有这样才能按期发布，缺点是会积累技术债。

技术债不存在项目规划中，所以开发人员都把这些工作附加在其他功能开发上。极少的组织中，有头脑的经理会为技术债买单，但这不是惯例。那些做决定的人通常不会给时间还技术债，在他们脑子里，花时间却没有完成任何功能，为什么要给你时间做忙完了却没有增加新功能的事呢？

最坏的时候，累积的技术债可能会导致一个Web项目失败。典型的技术债就是可扩展性，一开始的目标是建立一个Web应用并运行起来。但建立一个100用户的程序和建立一个1,000,000人用的程序是不同的。为增加可扩展性，开发人员的脑子里会列出一大串需要去做的事，减少访问数据库的次数，多层缓存，减少请求大小，更快的处理等等。

跟金钱债务一样，解决技术债的最好方法就是在变得太大承受不住之前解决掉。定期清理技术债就好像代码卫生（code hygiene）。 如果你十年都没去看过牙医，没准你会因为平时不注意口腔卫生得到一个大惊喜。代码也是一样的，驾驭你的技术债意味着有时间就定期深入解决问题。良好的代码卫生需要你定期：

• 删除无用代码 – 我常说， 删掉多行代码的一天是美好的一天， 是对得起你薪水的一天。 无用的代码不应该存在代码库，因为这东西就像细菌， 一遇到机会就会造成很大的问题。 如果觉得有些代码已经没用了， 验证一下删掉它们。 要立即处理，不要想着以后处理，那会造成更多的技术债。 更少的代码意味着更少的出错机会和更快的构建，部署。
• 重构代码 – 重构的时机就是你意识到有问题的时候。 不要让邋遢的糟糕代码继续出现在代码库。 代码会有自己的方式自我复制。 比如新开发人员来找一个例子， 找到了糟糕代码， 拷走， 现在就有两份糟糕代码了， 造成更多的技术债。 提交之前确保自己的代码可以被复制到别的地方而不会造成未来的技术债。 在已有的代码基础上工作时， 评估期间就应该考虑到重构的时间。
• 重写代码 – 很少有人用重写的方式修改代码， 但这是代码卫生的必要组成部分。 好的代码用该能运行5年而不用重写【注】； 糟糕的代码发现的时候就应该尽快重写， 可以先尝试重构， 重构不行就重写， 在商业环境中重写代码很困难，不过你可以把重写绑到新功能开发上， 这样就更有机会得到需要的时间。

技术债是每个项目的一部分， 需要有关各方参与其中， 每一个版本发布都考虑到代码卫生是个不错的方法， 可以用多种形式： 代码大扫除（bug bashes）, 每个人抽出一两天只处理bug； 工程师驱动（engineering-driven），而不是由终端用户决定做那些功能；代码审查（code reviews），就是工程师相互检查对方的代码， 都是保证技术债不失控比较好的实践。

声明：任何在这篇文章中的观点和意见都是作者自己的。不要以任何方式联想到作者的雇主，同事，或其他。

注：五年是根据自己的经验：一般来说人们倾向于约五年从头重写他们的软件。 通常开发需要18个月（不是部署，而是做成你想要的样子）。 接下来18个月应该很容易维护， 之后就会有人开始想从头做了。 但是知直到过一两年，软件的地基上也开始出现裂缝的时候才会做出商业上的决定。 在第四年或者第五年的关头上， 一般新工程师已经不熟悉原有的架构了， 也不知道该怎样修改新出现的问题的时候。 新的解决方案就是： 重写它！