为什么我喜欢技术债

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

我喜欢技术债的坏原因

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

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

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

我喜欢技术债的好原因

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

这意味着什么？

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

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

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

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

如果它被记录下来，我们就成功了一半。作为一个安全人员，我知道我不能强迫所有出厂的东西都满足我想要的所有要求——但高可用性团队、用户体验团队、性能团队等等也是如此。

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

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

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

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

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

^*** 请配合一下。

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

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

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

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

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