震惊！产品上市操之过急能拖垮企业？技术债务竟是那最后一根稻草！

技术债务，指的是团队为了短期的项目利益故意做了欠佳的技术，而日后必须要花长时间来解决的技术漏洞问题。但是，这对整个企业到底意味着什么呢？

技术债务和其他债务没什么两样，我们不妨以买房子来进行比较。大多数人银行账户上里都没有几十万美元可以够套房子。所以呢，人们会选择抵押贷款。买家必须在未来15到30年内偿还本金和利息。如果买家没能够按时还款，那么他们就会失去房子。

技术债务也是如此，它允许公司更快地开发软件，但是他们也有心理准备，未来开发软件的速度会减慢。相比最初开发最好的解决方案所花的时间，公司最终将不得不花更多的时间来偿还技术债务。

任何软件工程问题的最佳解决方案通常需要大量的预先投资。你会在很长一段时间里写着看不到结果的代码，并且在实际实现稳定和可扩展的结果之前这些代码已经写完。

技术债务会为开发人员带来极大麻烦，并阻碍长期的可扩展性。但几乎所有的创业公司都存在技术债务。很多公司将其用作短期发展的催化剂。因此，技术债务并不总是坏事。

怎么分辨技术债务？

技术债务不单是一些抽象的概，。它也可以用具体语言和图片方式来解释。一个非常好的比喻就是大O算法复杂性。随着代码库不断扩大，我们可以衡量添加新功能和/或代码所需的工作量。

所有位于蓝色线性曲线O（n）上方的结尾技术债务，下方的都不是。这意味着随着代码越加越多，技术债务会使得代码的编写越来越复杂。

蓝色曲线下方的可扩展解决方案通常为抽象元素、数据库和工具，使构建软件更为容易。比如，可以构建应用程序特定的功能，如内部仪表，到利用React和Docker一类的数据库和工具。合适的工具和抽象元素可以影响乘数，而技术债务则是影响除数。

如图所示，技术债务最初可能为最佳路径，但如果应用功能要能成功，则需要快速重构。这也解释了创业公司应以最快速度发布最小可行产品，随后迅速迭代改进该产品这一创业原则。

首先，弄清楚那些创意有牵引力，然后迭代构建它们，使其变得可扩展。一个功能可以通过在代码库（技术债务）上施加O（n²）复杂性来实现，但是可能会随着时间推移重构为O（n）和O（log n）。O（log n）允许个人或小团队以硬性方式获得与大型团队一样的结果。

公司规模和代码库规模都到一定程度时，你便达到了我所定义的可扩展性阙值点。在这一点上，你开发的工具与其产生的报酬相比，需要的工作量比线性方式要来得少。在越过这个阙值之后，你就不能再在线性方法之上开发软件。相反，对代码的投资可以让你以更少的人力和工作量获得更多的成果。

理论上，线性O（n）的解决方法不是技术债务。对于你每增加的一小时人力，你会获得等同的收益。但是，实际情况并非总是如此。时间、金钱和人的意志力都是有限资源。你能雇佣的员工最终会达到极限，员工也会在重复性的工作渐渐失去动力。看似成正比扩展的软件解决方案，在需要人力构建它们时就成了技术债务。

现实案例

假如你现在正在开发一款革命性的新服务，叫做Citybrook，这项服务可以为城市创建简介。选择五个你感兴趣的市场，比如旧金山、西雅图、奥斯汀、纽约和纳什维尔。然后再用纯HTML和CSS创建一些简单的网页，接着为产品找到市场契合点。

假设用户很喜欢你的内容，所有美国城市都在请求你为他们创建网页。同时，你也发现，你的亚马逊云服务（AWS）费用将暴涨，因为你收到的流量过于庞大。因此，你决定在每个网页上投放广告，不同的城市投放不同商家的广告链接。很快，你发现这些简单的HTML解决方案无法扩展。这就是O（n²）复杂性，因为你无法可行地为每个城市构建和维护一个具有独特内容的HTML页面。

为了解决这个问题，你打算用React来构建模板化页面，并呈现动态内容。这时候，你已经减少了技术债务，并且使得公司的扩张更加可行。你现在可以分配时间来生产更好的内容，而不是为费时间为每一个城市构建独特页面。

你和团队奋力工作，计划在几个月内为每一个城市创建一个页面。但是，不知不觉之中你却成了自己成功的牺牲品。其他国家的竞争对手也开始推出他们的网页，然而对于扩张你却是心有余而力不足。

你试着快速招聘，但还是跟不上节奏。有些城市要求你更新内容，但是广告商因为不断增加的流量而无力支付广告费，因此他们的广告需要撤走。手动创建和更新每个城市的页面不再合适，而且也没有足够的人力来跟上如此快速的规模扩张。

因此，你决定创建一个面板，来允许每个城市创建并更新他们自己的页面。在开发期间，网站上的所有页面数量暂停增长，但好在你的知名度为你抱住了这些客户。面板开发完成后，增加新的城市就变得无比简单轻松。你的团队现在不再需要花几小时的时间来写代码了，相反，他们只需维护并开发支持你的客户的工具就可以了。

随着你的团队发展，你有了更多能力可以编写安全代码，并偿还当初让你取得今日之成就的技术债务。

技术债务会带来其他更多的技术债务。基于技术债务的开发和/或增加更多的技术债务，往往带来不良代码的指数级增长。也就意味着，增加更多的功能会使得日后越难以还清该技术债务。

什么时候技术债务可接受？

消费者才不会关心的你代码是什么样子的，他们只需要你的产品。即使设想了一个完美的功能，但从来没有机会发布并且失败了，那么其结果等于零。这就远远比不上一家有着不少能够吸引用户的功能的刚起步创业公司。

这种蓬勃发展的创业公司可以在接下来的时间里迭代这些功能，获得牵引力并改进其功能，使得他们可扩展性更好，一旦刚起步的创业公司获得成功，他们就可以构建自己的工程团队，整理偿还过去的技术债务。这将为他们带来未来更大的成功。

技术债务的回报必须高于债务本身。就是说，不管你通过技术债务能够实现何种结果，该结果带来的影响必须大于技术债务本身。

技术债务不是懒惰的借口。技术债务的使用，应从长远角度来考虑。创业公司需要快速发展，在市场上测试他们的创意。一旦创意得到验证，他们需要努力去了解问题并寻找合适的抽象元素来扩展它。接着，公司就要偿还当初留下的技术债务。

跟普遍的观点相反，很多情况下，使用技术债务其实是最佳的决策。Facebook多年来的座右铭曾是“快速行动、打破常规”。Facebook之所以能有今日之成就与它最初使用的技术债务有很大关系。但这也带来一个问题，即Facebook的规模使其维护变得十分困难。但是，技术债务并没有阻碍Facebook发展的原因在于，Facebook总能够以比债务累加速度更快的节奏发展。

保持技术债务在可控范围，需要经验、错误和沟通。但是，你也需要明白，正确管理技术债务，可以使其成为公司发展的强大催化剂。很多时候，技术债务是前进的最好道路。不过，当技术债务不再适用的时候，它将会成为发展的最大阻碍。

了解技术债务，控制技术债务，并将其当做工具来使用，它便能够帮助你的创业公司蓬勃发展。