什么是技术债务
是一个的隐喻，可以是在软件体系结构和软件开发中最终产生结果是差劲的代码。债务可以被认为是工作之前必须完成特定的工作。从演化代码开始，经常有需要对变化做出协调的，同时也包括其他部分的代码或文档，也被认为是在一些在未来必须支付的债务。
它是：
在重构中(消除重复/冗余代码)，随着时间的推移让代码质量恶化。正如金融债务，这是在短期内容易做到的事情。然而随着时间推移，有趣的是你的支付是巨大的，这些债务是有利息的，恶心的代码是不容易维持或修改它，已经变得重写程序是更加可行的解决方案。所以，问题是你是否要付一点现在解决的小问题或要付出更多的时间在N个月之后，代码已经变成侏罗纪公园2。
技术债务的常见原因包括：
商业压力，在所有完整的需求情况下，业务需求需要软件提前发布的，包括那些未完成的需求变化。
缺乏软件过程或理解，企业对技术债务的概念是盲目的，并做出决定，而不考虑的影响。
缺乏构建松散耦合的组件，功能模块是硬编码的，当业务需求发生变化时，该软件缺乏灵活性。
缺乏测试组件，它鼓励快速和低风险的打补丁的方式来修正Bugs。
缺少文档，其中的编码没有一个必要文档支持。这些支持文档代表是这项工作必须支付的债务。
缺乏协作，周围团队没有共享知识从而工作效率受到影响。同时对两个或两个以上的代码分支并行开发，可能会导致成为的技术债务，因为最终工作是将合并成一个单一源代码库。这时可能有更多的变化需要进行隔离，债务越积越多。
推迟重构。随着项目发展，需求变化，部分代码已经变得笨拙，变得必须进行重构，以应对未来的需求。重构推迟的时间越长，就需编写更多的代码，更多的债务堆起来，必须花费更多支付的时间来完成重构。
最近我一直在讨论技术债务负面反馈。 我一直在试图探索，在我的脑海，为什么它会被认为是负面的，它是一种消极的东西？是什么时候产生的想法？ 我真的不能找出为什么它会被认为是不好的，有技术方面的债务，而不是试图找出人们为什么会认为这是一件坏事。所以，我会尽力透露了一些关于在现实中是什么技术债务。
我要开始说技术债务的东西，所有的项目都有，无论是最近创建项目。 事实上，我可能会认为我们将在每天上所有的软件项目的技术债务。 但在此之前，我想花时间去列举并归类为技术债务的东西。
/ / TODO
你曾经看到那些反感的代码，你真的无法修复，因特定时间情况下，其也涉及其当前项目的架构，将不允许你这样做，或许它是直接很简单的，但你没有时间，因为接下来你将某个Sprint结束后做DEMO演示。 你用 / / TODO 在代码中注释，试想在稍后阶段重新审视这些问题。 你可能甚至不知道什么时候陷入了技术债务。 甚至可以说，任何注释的代码，使代码变成技术债务，原因是 - 该代码是自己太理解的和需要注释来解释它是什么做的。
遗留代码
几乎所有的系统在那里构建的，他们要处理一些数据模型，你不能摆脱一些旧的模块。 处理遗留代码艺术是保持遗留代码可以工作并尝试提取出一个反腐化层。 但是，即使这个地方，有时难做到事滴水不漏。 这样的事情，你真的不希望在您的新模式可能引发新问题，也可能是任何东西，从一个简单属性错误名称导致您的新模式大的概念被歪曲。 所有这些都可以被归类为技术债务。
工作中软件
软件开发是在我看来，很像是在高速列车真的没有目标，但是有铁路岔道口，使软件的轨迹变化。 这可能是团队想要拥抱做事情新方式。 这可能是团队需要的新知识，是他们以前没有的，这将使软件更好地向前发展。当时的一切留下都代表技术债务。他们是理想的团队需要去Fix的，但往往由于时间关系，他们不能现在就去做。
复杂性
另一个警示标志使我的警钟熄灭是当发现某些东西是很难跟踪的。 除非你发送到月球或其他行星的太空船，我也很难相信软件应该是很难做到理解或遵循的。 做的好，一切都应该是很简单的。 超长的Method，大的Class有一个以上的职责，所有这些都是导致软件的复杂性，很难让别人明白了。 事实上，我认为写那些代码的家伙很难回到自己的复杂代码中。 这是一个典型的情况是团队想有它的另一种方式，因此，应归类为技术债务。
Bugs
那么，什么是Bugs。 这是有趣的是东西，不属于个别特殊的东西。 Bugs是软件的缺陷，功能没有按预期工作。 当然，这可能是一个连锁效应，多数人造成的Bugs，或发生冲突的Bugs，基于系统其他部分的技术债务。 但是，那么你应该尝试找出真正的问题和修复，隔离时，可以分类为技术债务。
现在该怎么办？
不要跳进恐慌，只是还没有，只是因为你实现你从一个或多个上述问题似乎遭受的项目。 我们该如何应对呢？ 好了，首先 - 是诚实的。 当涉及到一般的软件开发和生活中，我已经取得了巨大的成功，只是实话实说。 对自己和你的团队要诚实，说实话，不管是谁的Case，在每一天结束的时候， 你都有技术方面的债务。还好，它实际上是一件好事，这意味着该系统是不断变化的，你作为一个开发人员是不断变化的，而且很可能就更好为其所谓的进步。 你只需要知道技术债务，把它写下来的地方- 不是在代码 ---- 是整个团队可以看到的某个地方。 把它写下来，在规划过程中看一眼，这使得更加容易在后面过程，每一个开发人员心中都有实际处理的债务，需要花费的时间，而使进度渐渐向前迈进，并开始开发新的功能或修正Bugs。就个人而言，我更喜欢简单的方式处理这个问题。 一个项目，我们开始只是把技术债务的形式化后，贴在墙壁上。 慢慢地进化到使用Trello画板 ，并且所有的时间已经显示在一个42英寸的屏幕。 通过这样做，面对我们的技术债务时，不是坐在办公室里，而是把它在42“屏幕上显示，使它成为焦点。 重点围绕团队的事情，所有的时间，保持眼睛能看到这些债务 - 慢慢偿还。
另一个方面，我觉得重要的是，不仅技术债务，但一般不是使你的代码个性化。 它不是一个对自己的表现，它是代码。 该代码被提交到库中，它不再是你的，但属于整个团队。 要有这个想法，你将永远保持它仅仅是愚蠢的(KISS原则)，你可能会辞掉你的工作，或更糟糕的事情可能发生。 在这个意义上的代码不是你的写。
如果因为任何原因，在您的团队中，技术是一个意味深长的长期债务，你可能要考虑别的东西。 在您的解决方案中不要假装你没有提到的内容，只是因为它是一个意味深长的词。 这类似任何会出现您的团队和工作中 “耻辱墙” 一样东西。
结论
不要让技术债务吓唬你，试图避免承认的事实是技术债务。 我们每个人都有，大家都有助于它，唯一重要的事情是，它是在我们的议程上，我们需要一种方式偿还。 建立您自己的债务管理计划，无论是在你工作中的工作项目的跟踪软件，然后在出现于墙上或适合你的东西。 把它弄出来，在开放的，它并不可怕 - 事实上，我认为相反更可怕是不知道什么是债务级别。
更多引用参考:
http://blog.dolittle.com/2012/12/02/time-for-a-debt-management-plan/
http://www.c2.com/cgi/wiki?TechnicalDebt
作者：Petter Liu
出处：http://www.cnblogs.com/wintersun/
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。
该文章也同时发布在我的独立博客中-Petter Liu Blog。
