51CTO六周年贺礼：译文一篇
嗯，这篇内容也没啥我和51CTO的故事，就不参与征文啦。
一霎眼，51CTO六周年了。我去年为51CTO家园写的那篇“赞歌”还历历在目，而现在家园的园长一休已经成为已婚人士，不免让人再次感慨时光的流逝……（呃，一休的已婚跟今天的感慨无关）
嗯，咳咳。总结过去这一年，更新的博客少了，感到惭愧。无论是抱怨51CTO博客无法在ScribeFire上导入也罢，还是因为自己进入了一个沉淀期也罢，但说来说去，终归是人懒。
（不过话说回来，看到一休的博客还停留在去年7月，我又沾沾自喜了起来
）
好吧，其实今天六周年，我没啥好写的。
不过今天看到一篇文章不错，英文的，就顺手翻译过来，当作给51CTO的生日礼物吧～
这篇文章跟技术负债有关。
其实对于技术负债，我也没有系统的研究过；但是无论对于技术团队，编辑团队，或者个人来说，这种“负债”的概念，一定要清楚的认识到。自己应该到什么水平，自己实际上实现了什么水平，没有这种认识，自己过得固然糊里糊涂，又要如何对他人所交托的任务负责呢？
以下就是：
DevOps and Technical Debt: A Debt Crisis in Your Workplace?
开发运维与技术负债：你工作的地方遭遇到负债危机了吗？
（译注：DevOps，开发运维，是这两年在运维领域的一个新生概念，基本理念类似开发领域的敏捷开发。大意就是，运维和开发关注的领域都要有一定的覆盖，才能够互相理解，避免扯皮，提高效率。嗯，跟老杨上周在培训上讲的“双方各跨一步就越界”的概念是一样的）
现在满世界的金融新闻都在讨论负债危机的事情，那么对于IT部门中另一种负债的讨论，倒也是一个很好的时机。
这种负债往往发生在不经意间，而它同样也会带来悲催的结局。这就是我今天要说的：技术负债。
技术负债常在敏捷开发的周期中被提及，这是对于代码质量和完整性缺失程度的一种量化方式，从而加速商业特性的开发流程。所谓“技术负债”的意思，就是用“正确的做法”减去“得过且过的做法”得出的结果。
之所以用到“负债”一词，是因为这个现象所造成的结果，是企业或组织在未来的某个时间段必然要进行一种“偿还”（就是修正的过程）。在开发的过程中，你越是不去理睬这些负债，那么负债则会滚雪球一样增加。正如同金钱上的负债一样，技术负债也会产生相当复杂的化学反应。
下面是我最喜欢的几个比喻：
- 没完善设计就写代码相当于借钱。
- 重构相当于还债。
- 由此造成的开发进度缓慢相当于付利息。
对于技术债务的说明，Ward Cunningham，Martin Fowler和Israel Gat这些大牛们说的相当好了，建议想要了解技术债务的朋友们直接去读他们的东西就行。
那么，这个与DevOps有什么关系？我认为，DevOps要解决的问题，最适合用技术债务的概念去解决并量化。我经常听到团队的人说，“先不要管那么多啦，先把东西弄上线了再来完善我们的流程和自动化设计”。这可是相当于巨额的技术负债，而他们往往缺乏对其进行量化的方法。
那么借用如上的比喻方式，DevOps遇到的问题主要跟自动化实现的粗糙质量息息相关：
- 没有采用自动化，或者设计糟糕的自动化相当于借钱。
- 对自动化脚本进行实施和改良的过程相当于还债。
- 缺失或糟糕的自动化导致的糟糕执行效果相当于还利息。
所以，无论对于开发还是对于运维团队来说，技术负债已经是执行层面一个非常具备说服力的比喻。
------------------------------------------------我是正文结束的分割线------------------------------------------
其实我想说，这个“负债”的概念，用到任何场景都是可以的。虽然说，这样一个比喻默认有一些事情你是“应该”去做的：比如开发必须要先设计好整个的功能体系和架构，部署系统要先做好自动化机制，等等；但实际上，对于我们面对的很多事情，实际上我们很难知道哪一条路才是正确的，这些“概念”大多是前人多年经验积累总结出来的。而这些经验，有些是普适性的，有些则只针对特定的场景。
不过，当负债开始堆积的时候，我们却很容易能够感觉到。比如，在一个系统上添加一个很简单的功能都要缚手缚脚、瞻前顾后、生怕修改了这里会莫名其妙在其他地方出现bug的时候；比如，当我们需要承担更多的责任，却发现自己力不从心的时候。这意味着我们需要进行重构，或者需要将之前因为种种图省事的思想而没做的事情补做回来。
你的团队遭遇到负债危机了吗？你自己遭遇到负债危机了吗？如果是，那么赶紧做好还债和还利息的规划吧。
共勉～