@程序员，欠下的技术债怎么还？

私信我或关注微信 ：狮范课，回复：学习，获取免费学习资源包。

在软件工程领域中，“技术债务”是一个贬义词。人们在使用这个词的时候常常表达出某种遗憾，过去犯下的错误，最终需要通过重构来弥补。

然而，金融债务却没有遭遇到众口一词的谴责。比如你的朋友抵押贷款够买了新房子，你会说什么？肯定会说：“恭喜！”债券是基础设施和公共事业标准的融资形式。企业使用了各种债务，而华尔街却对股价上涨充满了信心。

技术债务与金融债务之间的不同之处在于意图——如果技术债务也并非总是意外，或者由错误的假设和意外情况导致，那会怎么样？你会如何处理技术债务的贷款呢？

如果我们将技术债务定义为将来必须完成的工作，那么就可以根据将来所需要花费的工作时间来计算开销。我们也可以选择现在就“投入”时间来完成这些工作。

这种心理上的模型可以帮助我避免浪费开销，或承担起力所不及的系统维护工作，同时也让我有机会看到有目的性地使用技术债务的机会。在以下几个案例中，我借助技术债务取得了项目的成功。

脚手架

在划分某个大项目主要功能的优先级时，通常我会首先验证项目中最具风险性的部分。这里的风险我指的是最容易出错的部分，因为这些部分很复杂、难以定义、未得到充分的理解，或者让我嗅到了“危险的气息”。由于这些是最艰难的部分，所以我会赶在代码库尚小且容易扩展的时候，首先构建这些部分。

然而，仅仅构建有风险的组件还远远不够。我需要知道构建这些有风险组件的方式是否正确。然而，实践才能出真知，所以我会全力推动我的代码进入现实世界。这也就意味着我需要在构建应用程序的其余部分之前，找到一种方法有效利用这部分有风险的代码。

最终的产品需要快速可靠地发送数亿封电子邮件，但我们不需要立即实现这个功能。

如下自我实施的指导方针帮助我们顺利地实现了这个脚手架系统：

我们利用这个脚手架填补了依赖项空缺，目的是为了调整应用程序的构建顺序，确保尽早验证应用程序，同时又不会遇到构建组件的问题。

硬编码

最近，我正在开发一个产品的仪表板，其中有一个功能是在某个区域显示最新的消息，比如：“祝所有订阅者节日快乐！”我们团队需要每隔一个月或两个月刷新仪表板在该区域显示的内容。

我们需要一个内容管理系统（CMS），我们的产品经理和设计人员可以通过这个系统自行更新仪表板上的消息。此外，产品经理还希望仪表板能在特定时间点更新，而工程师不希望为了响应这些需求而定时手动更新生产版本。

一种方法是构建数据库支持的CMS，帮助我们团队的各个成员在无需工程师干预的情况下，自行更新仪表板上的内容。

然而，这种方法的成本很高：额外的前端、验证以及数据管理。这些隐藏的成本是沉重的技术债务，将来必然给开发人员带来更多的维护工作，相比这个功能就得不偿失了。此外，仪表板上的消息内容可以持续数周而无需更新，因此即时更新内容的解决方案对我们并没有好处。

为了实现在特定时间发表新内容，我们编写了更多的硬编码，如下所示：

if now >= NEW_CONTENT_DATE（新内容的日期） show new content（显示新内容）else show old content（显示旧内容）

在采用硬编码时，我考虑了以下几个因素：

通常，下面这些设计模式都可以考虑使用硬编码：权限列表、表单字段选项和功能开关等。

无需修复所有的边缘案例

我曾经构建的一个功能允许用户创建最多10个项目，但不允许超过10个。这里面包含一个很常见的竞争条件：如果我们同时发出两个创建项目的请求，那么这两个请求都会计算现有的项目数，然后同时创建两个项目。如果此时我们已有9个项目，那么最终就会创建11个项目——超过了我们的限制。

大多数测试人员会认为这是一个bug，而bug是用户可见的技术债务。

在这种情况，我们本可以利用数据库事务解决这个问题，但我们使用的数据库是不支持事务的NoSQL。读/写锁都没问题，但我们需要在分布式系统中运行，因此需要分布式锁。如果我们编写一堆锁定代码来实现这种“完美”的限制，那么最终可能会引入其他意外的bug。而且我们必须花大量时间编写一堆锁定代码，而且之后的每位开发人员都必须理解这段锁定代码。

似乎我们付出了这么多努力只是为了不会多创建一个项目。那么非技术性的解决方案呢：如果我们故意不修复这种竞争条件，会怎么样？

我说的可不是对这个问题视而不见，留给下一位开发人员来处理！我说的“故意”是说搞清楚以下几个问题：

因此，我们大可以不必理会这笔技术债务。由于创建额外项目的影响很小且易于监控，我们可以将时间花在优先级更高的工作上，无需在这种不是问题的问题上浪费时间。

对于良好的技术债务要做到心中有数

许多沉重的技术债务都是因为构建的功能过多，而且花在维护和改bug上的时间超过了预期。这就好像你购买了太多地产，最终陷入溺水屋的困境（注：按揭买房者所欠银行的钱超过房子本身的价值）。

关键在于你清楚投入的时间，并了解你所承担的成本。由于构建的功能太少而引发的问题并不可怕，因为你随时可以构建更多功能。我们应该构建方便丢弃和替换的功能，这样代码会更加模块化。良好的技术债务的局限性很明显，且众所周知。你可以在代码的注释、README、常见问题解答以及与人的对话中澄清这些局限性。

你可以善加利用良好的技术债务，将时间集中在重要的工作上，加快构建软件的速度。

私信我或关注微信 ：狮范课，回复：学习，获取免费学习资源包。