技术债务_您的经理为何喜欢技术债务（以及如何处理）-CSDN博客

技术债务

工程师们知道，成功的软件项目不仅仅具有令人眼前一亮的功能。在管理不可避免地随着时间演变的程序的复杂性时，重构和测试与功能同等重要。但是，当最后期限紧迫时，管理人员会倾向于将重点放在功能上。但是，如果这种技术债务开始堆积，该怎么办？

我有幸采访了Caskey L. Dickson ，他即将进行LISA15演讲， 为什么您的经理不喜欢技术债务，以及如何处理 。 Caskey是一位拥有MBA的软件工程师，在在线服务开发方面拥有20多年的经验。他已经看到了障碍的两面，并将谈论工程师和经理如何共同努力开发更好的软件产品。

导致产生技术债务的最常见原因是什么？

我想说最常见的原因是释放压力，但这只是故事的一半。我们被迫以对客户可见的方式显示进度和结果。即便是我们快速开发软件的最佳含义和最有效的方法（我正在看着您，敏捷），也更加强调提供用户可见的功能，而不是提供可持续软件所需的功能。我并不是说敏捷方法不能包含用于解决软件质量问题的积压元素，而无需额外的纪律，就很容易忽略这些项目。实际上，那是故事的另一半。您的积压订单应包括与软件质量有关的可量化内容。 “如果没有模块Y的实例，则无法对模块X进行单元测试，这对创建（或模拟）而言非常昂贵。” 修复类似问题属于您的待办事项列表，但只有在开发人员将其放在此处时，它们才会出现。如果产品管理部门拥有积压的订单，那么开发和运营方面的问题就永远不会神奇地出现。

当然，这提出了这个压力来自何处的问题？直接回答“产品管理”很容易，但是比这复杂得多。没有工程师愿意提供不合格的产品。但是，作为一个物种，软件工程师缺乏耐心和前瞻性。我们希望继续进行下一件很酷的事情，而又不想“吃我们的蔬菜”。作为开发者社区，我们需要认识到管理层中有人直接说“不要做那个测试范围，现在就发货”的次数已经很少了。相反，由于施加在自身上的压力，我们让质量一次下降一天。我们每天都会在严格的纪律方面做出让步。我自由地承认我已经看过某件事，说我应该重构它，然后决定我只是没有情感上的精力去做，因为需要的改变不是那么大 ，所以我采取了简单的方法只是为了确保该功能没有移至下一个冲刺。这些决定在整个开发团队中Swift加总。

在项目中管理技术债务的最佳方法是什么？有可能完全避免吗？

我并不假装知道最好的方法，但是对我来说，归结为找到所谓的技术债务的代理措施，然后使用这些措施将特定的行动推入积压之中。技术债务对您意味着什么？作为开发人员，我们的内心深处隐含着这个模糊的想法，但它涵盖了我们称为-ilities的一堆东西：可维护性，可管理性，可扩展性等等。

我喜欢那句老话，您应该像下一个要从事此工作的人一样编写代码，这是一种杀人的社会变态，并且知道您的住所。一旦提出了一套在代码中有价值的东西，找到一种方法来衡量和观察随时间的变化就是管理债务所需要的。我们对这些功能进行了简单的衡量：每个sprint上的新光泽项目符号列表，产品发布公告，新功能和兼容性大受好评。这些都是衡量我们产品进度的指标。我们还需要针对软件开发过程中缺失要素的措施，这些缺失要素会带来产品风险。

至于完全避免债务：绝对不是。风险是一个连续的过程。一切都有一定程度的风险，绝对值永远不会为零。此外，降低它的成本成倍增加，尝试这样做是愚蠢的。作为工程师，我们有责任在可接受的风险量和为付出的努力而交付的价值之间取得平衡。我们是该过程的积极参与者，需要对所做的决定承担责任。而且，我们不要自欺欺人，有些工程师愿意承担比其他人更大的风险。有时，我们的沮丧不在于管理，而在于我们的开发人员，他们对可接受的风险有不同的想法。这就是为什么能够提出明确的风险衡量标准和商定的阈值如此重要的原因。我觉得需要进行的对话不仅是我们与管理层之间的对话，也是我们内部之间的对话。

您为什么认为管理人员不了解代码库中累积的技术债务风险？

我认为说他们不懂是很容易的事。说他们没有得到做出明智的判断所需的信息，这更合适。管理层的工作之一是就风险与结果做出明智的决策。我认为没有为他们提供一种以内在的方式客观评估我们的感受的工具，即，由于代码中的质量缺陷而要承担的实际风险。

我在管理层承担知情风险方面没有任何问题。坦白说，那是他们的工作。我担心的是，目前绝大多数组织都在对其产品的实际质量承担未知的风险。我希望我的电子邮件提供商或我的健康保险公司在产品质量方面承担的风险与我希望自己喜欢的在线游戏承担的风险完全不同。当然，每个人对这些产品的权重都不同。开发人员需要找到以可量化和可操作的方式表达风险的方法。然后，我们可以采取积极措施来达到并保持我们都同意的质量水平。

在无休止的紧急任务积压之中，程序员可以做些什么来使管理层理解重构的重要性？

程序员可以花一些时间来量化自己的挫败感，并将其放入待办事项列表中。质量也是一个特征。正如我的讲话会试图指出的那样，抱怨像技术债务这样的抽象概念太含糊了。可行的想法并不模糊，例如“我们的构建过程可重复性不足”，“我们的单元测试覆盖率太低”，“烟雾测试需要太长时间才能运行”等等。有时，我们自己开明的解决方案会妨碍使用干净的可测试代码。如果由于没有简单的方法来注入模拟的依赖项而无法抽烟测试模块，那么也许是时候重构组件及其依赖项以使其更具可测试性了。这些是可行的项目，可以在商定的质量标准的基础上进行积压。

开发人员需要做的另一件事是坚持原则立场。您拥有的力量比您想象的要多，并且只要您可以就代码质量问题的性质和程度提供合理的论据，您的经理将是您的盟友。您的经理不希望您的产品比您失败更多，但是通常不会给他们关于产品质量的量化信息。此外，当您的经理看您的评估并表示不同意时，请不要感到惊讶。我永远不会忘记咨询代码库，在其生产服务上演示一些基本SQL注入的咨询工作，并且管理层认为修复它的成本不值得（存在风险）。作为一个年轻的开发人员，我感到震惊。十多年后，我看到他们的决定不仅限于所讨论的软件。

管理层的工作是承担风险。因此，让我们为他们提供做出明智决定所需的信息。

您是否认为开源项目不太容易积累技术债务？还是他们遭受同样的问题？

这是一个棘手的问题。任何项目都有能力承担技术债务。区别在于，开源项目一旦陷入困境，很少会积累大量债务。只有当您拥有大量的俘虏开发人员，他们不得不向代码库添加功能而没有参与的选择时，您才可以达到真正的糟糕的代码质量水平。当一个项目是开源项目时，开发人员只需继续进行下去，当它变得难以处理且项目终止时就继续前进。

我认为成功的开源项目通过积极的重构，坚持质量诱使的行为（如代码审查，单元测试覆盖率标准）以及不良的代码库饿死了开发人员的生态系统来管理其技术债务。愿意为开源做贡献的人很少，并且由于选择了一个不错的，干净的代码库，并且选择了一个复杂而复杂的意大利面条，所以大多数人都可以从事更高质量的项目。对于优秀的开源项目而言，这是一个良性循环，并且暗中惩罚了劣质项目。一个好的OSS项目的黄金标准之一就是贡献指南。您内部组织的项目是否有贡献者指南？如果您公司中的另一位工程师想要为您修复错误，那么他们需要一个工作的开发环境花费多长时间？

也就是说，我经常在非开源项目中看到的最糟糕的代码是在孤立的开发环境中。就像在政治中一样，阳光是最好的消毒剂。我知道我有一些支持和玩具项目，任何人看到我都会感到羞愧。这就是为什么我绝对爱上“内部开源”运动的原因。使用开放源代码的方法来使代码在组织内可见并且可以广泛地编辑，只能做些改进。好的内部项目不仅可以作为应做的事的典范，而且不好的项目也可以看到，并且可以表达更多的声音来应对内部的担忧。

当然，将内部开放源代码与开发人员在项目之间自由移动的能力结合在一起，您已成为圣杯。再一次，让产品经理陷入困境，而这名经理却把袋子留在了关键业务的意大利面条项目上。

如果您本月要参加在华盛顿特区举行的LISA15 ，则可以在2015年11月13日（星期五）上午11:45收听Caskey的演讲。