标签（空格分隔）： 翻译
原文地址：Do Not Let Technical Debt Get Out of Control
译者：这篇文章应该可以算是敏捷开发和MVP思想的一个小花絮，着重讲解所谓的技术债会对团队造成什么样的影响，以及我们应该如何去对待技术债。
以译者的经验来看，当我们执着于快速开发可用软件的同时，一定会伴随着产生很多垃圾代码，因为我们不得不写出一些潦草的代码，只是为了快速实现功能而已。当技术债积累到一定量的时候就会变得异常的危险，我们在每次写新代码前，都需要先去了解那些稀奇古怪代码的来龙去脉，加新功能成了一件越来越痛苦的事情。事实上，在适当的时机清理这些技术债（无论你是使用重构，还是小修小补），才是符合敏捷思想的。否则，用了敏捷开发后，反而会使得软件的质量越变越差，生命周期变得越来越短。
当然，如何选择什么是适当的时机清理技术债，以及如何清理，就是得要看团队的经验了。
技术债这个词是用来比喻那些为了快速的新增功能并发布产品时，编码上使用了一些快速但却很脏的风格。正确的办法当然是使用那些整洁的设计和实现方法，但是这样会花费更长的时间。Martin Fowler打了一个特别贴切的比喻来形容技术债：
在这个比喻中，采用快速肮脏的办法快速的实现某些功能就会导致技术债，这和财务债务很类似。和财务债务类似的是，技术债会导致额外的支付利息，因为选择了快速但很脏的技术实现，在未来的开发里我们就不得不付出额外的工作去修复。
背负技术债应该是一个战略上的决定，所有的负责人都必须明白潜在的风险。就像所有的财务债一样，它不应该被无视，必须明白利息必须按时支付才能避免罚息。
尽管技术债务有负面的含义，它却是很多软件工程不可避免的现实。在敏捷开发的入门书籍《Ruby面向对象练习》一书里，Sandi Metz写道：
有时，立即实现某些需求的价值远远超过了再未来增加的成本。如果因为缺失某一功能而导致我们现在失去某单生意，那么就不要多虑它在将来会给代码维护增加多少成本。你必须全力以赴做好眼下的。
为了争取某些商机我们会累积很多的技术债，我们会试着在一切尘埃落定时去偿还这些。但是有的时候事与愿违。至少我遇到过两个项目技术债多到失控的状态，实现一个新功能成了一个极其复杂和痛苦的过程，不仅仅是对于码农，还包括测试和运维团队。（译者：才两个就抱怨，估计国内一半以上的码农就没见过技术债不失控的项目）。需求变化接踵而至，我们却不断犯错，不得不承认我们已经累积了太多的技术债，它们已经严重的拖慢了我们的进度。结果？它变成了巨大的负担，不得不额外干很多工作才能维持系统正常的运转下去。
但是，最大的意外并不是效率问题；它是一个团队的文化和士气问题。人如果无法从他们的工作里感到荣誉感，就难以激发出动力。他们不会很有创造力或是主动学习，也不会想办法去寻找创造性的思路工作。因为项目都要求系统的知识去了解一些细小的技巧，我们就不得不把这些已经缺乏动力的团队仍然聚在一起，在不再出现这种问题以前，不得不停止新的研发以去做主要的重构和测试，一些团队认为，当面临这种窘境的时候，就得从零开始重写，其实这是另一个大错。
我们可以学到的课程如下所示：
1. 坦率的面对问题
技术债务是不可避免的，如果被忽视在将来就一定会变成一个大问题。我们在取悦客户的时候会把技术问题放在次要位置，于是就不承认或者根本没意识到我们正在积累技术债务，而这些债务有可能会在稍后导致很多的问题，以及拖慢我们增加新功能的能力。
2. 有策略的做出决定:明白短期vs长期的结果
在你的职业生涯里，应该经常都会为了争取一个市场优势而发布低于平均水平的系统给用户。事实上，这是一个错误。在初创阶段，我们往往会犯一个相反的错误，就是不及时的发布最小可行产品。结果就是，我们会失去很多至关重要的反馈。这里就需要技巧，所有的负责人都必须清楚的明白，并平衡好是速度优先还是质量优先。非技术的负责人经常都不明白这些概念，Steve McConnell给出了一些好建议,技术人员可以用这些去教育他们：
技术人员可以从商业的角度向商务人士打比喻解释，如果他们背负短期的技术债务，他们会需要付出现金，否则就项目会死于长期的商务支出。举个例子：比如我们可以增加功能A,B,C，可我们需要花费X周在这个特殊的架构上。尽管工作本身没有立竿见影的好处，可是它会使得再接入其它有可能更有商业价值的工作更容易。 现在这个问题就变成了一个可以见到效益的讨论，我们就给了商务人员一个接受的理由。
3. 不要让它失控： 还债
拖延的越久，付的利息就更多。如果你让技术债务积累到付不起的阶段，将来的开发会被一再拖延，代码质量堪忧，参与的人员必须得了解很多小的细节才能工作，参与项目的人员士气低落。制定个还清技术债务的计划，以避免在将来得付出更多的利息。它应该是你正常的开发流程的一部分。
背负技术债务是一件很危险的事情：它会带来短期利益，但长期看了就一定要还债的。利息的多少取决于你拖延了多久，攒了多少债。处理技术债不是一个轻松的事情：上层高管经常都看不到做这件事情的价值因为它又不是新功能（译者：这可真是个普世的价值）；打断手头的工作不说，还有可能会扔掉一些代码。因此你必须得有坚定的信念，清除技术债务是一件正确的事情，它会使得你的系统保持更好的形态。
网友评论