为什么我喜欢技术债务

我想，这不一定是你期望的文章标题，^* 但我是 技术债务 的粉丝。 这有两个原因：一个坏理由和一个好理由。 我将首先坦率地说明坏理由，然后解释为什么即使这样也不是真正喜欢它的理由。 然后我将处理好理由，你会点头同意。

我喜欢技术债务的坏理由

那么，我们就把这个坏理由说清楚吧？ 坏理由是，嗯，技术债务真的很多，它很有趣，它让我的工作有保障，而且作为一名安全架构师，它总是为我提供一个理由去参与^** 可能给我一些新东西看的项目。 我想这些并不都是坏事。 但它也可能有点令人沮丧，因为技术债务总是那么多，它并不总是那么有趣，有时我需要参与其中，即使我可能有更好的事情要做。

更糟糕的是，它几乎总是与安全相关，而且它总是存在。 这是糟糕的部分。

我们都知道，安全通常是被遗漏的部分，或者在最后才加上去，或者只用了一半的时间来完成，或者由只懂一半的人来完成，但他们并没有完全掌握它。 在这一点上我应该明确一点：我并不是说这最后一个原因是那些人的错。 人们知道他们需要安全这非常棒。 如果我们（安全人员）或我们（组织）没有做好充分的工作，提供足够的安全资源——无论是人员、培训还是可见性——给那些需要它的人，那么他们正在努力的事实是很棒的，我们可以为此努力。 让我们称之为积极的。 或者至少是希望的理由。^***

我喜欢技术债务的好理由

让我们继续讨论另一个理由：合法的理由。 当技术债务被命名时，我喜欢它。

这意味着什么？

我们都明白技术债务是一件坏事。 当你出于务实的原因做出决定，这些决定很可能会在项目生命周期的后期反噬你时，就会发生这种情况。 以下是一些与安全相关的经典示例：

• 未能对可能在某个时候公开的 API 应用身份验证或授权控制。
• 将功能捆绑在一起，导致以后难以分离出适当的角色。
• 以不允许最初考虑的方式自定义使用应用程序的人员的方式硬编码角色。
• 为加密协议硬编码密码套件，而不是将它们放在配置文件中，以便以后可以更改或选择。

当然还有更多，但这些只是我想到的一些，也是我多年来看到的。 技术债务意味着做出决定，这些决定意味着以后需要做更多的工作来修复它们。 这不好，不是吗？

在前面的段落中有两个词应该让我们高兴：它们是“决定”和“务实”。 因为，为了让某件事被命名为技术债务，我认为，它必须经过有意识的决策，并且必须做出权衡——希望是出于理性的原因。 这些原因可能有很多种——缺乏合格的资源；项目截止日期；缺乏足够的需求定义——但如果这些决定是有意识地做出的，那么技术债务就可以被命名，如果技术债务可以被命名，它就可以被记录下来。

如果它被记录下来，我们就成功了一半。 作为一名安全人员，我知道我无法强迫所有交付的产品都满足我想要的所有要求——但高可用性工程师、用户体验团队、性能人员等等也是如此。

我们需要的——我们所有人都需要的——是关于为什么做出决定的文档，因为当我们回到问题时，我们会知道这个问题已经被考虑过了。 而且，更重要的是，这些信息的记录甚至可能进入产品文档。“此 API 旨在在受保护的环境中使用，不应暴露在公共互联网上”是一份很棒的文档。 它可能不是客户正在寻找的东西，但至少他们知道如何部署产品，而且，至关重要的是，这是一个让他们可以返回给产品经理并说“我们真的很想以这种方式部署该特定 API。 你能把它添加为功能请求吗？”的机会。 产品经理喜欢这样。 非常喜欢。^****

不过，最好的事情不仅仅是命名的技术债务是可见的技术债务，而且如果你鼓励你的开发人员在代码中记录决策，^***** 那么他们很有可能会记录下一些关于未来应该如何做这件事的想法。 如果你真的幸运，他们甚至可能会在代码中添加一些钩子，使其更容易（API 上的“auth”参数，在当前版本中未使用，但会使 API 兼容性在新版本中如此简单；或者配置文件中的密码条目，目前只接受一个选项，但至少由代码检查）。

我知道，通过将技术债务定义为命名的技术债务，我有点不真诚。 但老实说，如果它没有被命名，那么你就无法知道它是什么，在你不知道它是什么之前，你就无法修复它。^******* 我的建议是：当你在进行发布收尾时（或在你的每周例会上——每次每周例会上），安排一个议程项目来记录技术债务。 命名它，记录它，感到自豪，晚上睡个好觉。

^* 嗯，除了显而易见的标题党原因——为此我（有点）抱歉。

^** 我差点写成“插手管”。

^*** 请理解我的意思。

^**** 如果你是软件工程师/程序员/黑客，这里有一个建议：学会像对待真人一样与产品经理交谈，并善待他们。 当你需要确定功能优先级或做出棘手的权衡时，他们（至少是更好的那些）是不可估量的盟友。

^***** 这样做。 就这样做。 至少在代码中没有镜像的文档不是真正的文档。^******

^****** 不相信我？ 与开发人员交谈。 “谁会阅读产品文档？” “哦，规范？ 我浏览了一下。 几个版本前。 我想。” “我在头文件中查找过；在那里找不到它。”

^******* 或者决定不修复它，这也可能是一个完全合适的决定。

本文最初发表在 Alice, Eve, and Bob – a security blog 上，并经许可转载。