不要让其他人的技术债务影响到你

ゞ浴缸里的玫瑰 2022-08-24 14:12 147阅读 0赞

本文来源于我在InfoQ中文站原创的文章，原文地址是：[http://www.infoq.com/cn/news/2014/01/dont-let-other-technical-debt][http_www.infoq.com_cn_news_2014_01_dont-let-other-technical-debt]

[Jim Bird][]是一位经验丰富的软件开发经理、项目经理与CTO，专注于软件开发与维护、软件质量与安全等领域中疑难问题的解决。在过去的15年间，Jim曾管理过团队建设并主导过高性能的财务系统的建设。他的主要兴趣在于如何提升小团队的效率以构建真正的软件：高质量、安全、可靠、高性能及适应性强。近日，Jim撰写了一篇[博文][Link 1]，谈到了与技术债务相关的主题，特别是如何不要让其他人的技术债务影响到自己，希望文中的观点能给各位读者带来一些启示。

目前有不少人已经写过关于技术债务的文章：[何为技术债务][Link 2]、[技术债务的不同类型][Link 3]、在设计、编码与修改代码时[如何避免引入技术债务][Link 4]、组织要为技术债务付出多少代价、以及为何、如何、何时来偿还这些技术债务等等。

不过所有这一切都忽略掉了系统中这样一些技术债务与风险，即这些债务与开发者的设计、编码实践以及单元测试等并没有什么关系。这些文章没有澄清的一点就是系统中那些并非由你编写的代码所带来的技术债务，要远远超过你所编写的代码所带来的债务。

就像西班牙、希腊和葡萄牙等国家的金融负债会拖累全球经济一样，其他人所编写的软件中的债务问题也会拖累你，即便你在自己的代码中对债务的管理保持着非常负责的态度也是如此。

来自Oracle、IBM、微软的软件以及开发者从网上下载的开源软件中的问题将成为你自己的问题。如果使用其他人所开发的软件（我们都会这么做），那么你就需要为这些人的错误、疏忽或是在稳定性以及安全性等方面的决策失误问题埋单。你自己会受到他们在开发、测试与安全等问题上的牵制，也会受到这些开发者所使用的第三方软件和开源软件的影响。

他们的Bug会成为你的Bug，他们的安全漏洞会成为你的安全漏洞，他们的错误决定会成为你的错误决定。

你所使用的其他软件的代码量（以及由此产生的技术债务）可能会非常大，甚至超过你自己所编写的代码量。根据Sonatype的一项调查显示，80%的Java应用都是由开源组件与框架装配起来的，一个大型系统甚至会使用30多个不同的库或组件。

**你承担了多少其他人的技术债务？**

这种技术债务要比你自己代码中的债务更加难以理解和管理。由于你可能没有理解这些代码、看不到代码有多么糟糕，或是可以看到但你却没有看，因此这些代码是你所无法控制的，特别是那些由多个系统共享的一般性平台技术，人人都在使用这些技术，不过却没有人对他们负责。你可能压根儿就不知道这些代码的存在，这些代码可能是由其他人下载的，成为了系统的一部分，不过却没有人知道这回事。

要想了解这种债务问题的严重性，你需要审查代码中使用了哪些第三方和开源包与依赖。大公司可能会使用Black Duck、Palamida或OpenLogic来扫描和构建开源库与组件的目录清单，检查相关许可，并及时追踪这些软件所报告出来的各种问题。

小公司可能就是手工做这件事了，也许会使用WhiteSource（一款SaaS扫描平台，对于初创公司和小公司免费），它提供了一个名为JNinka的免费源代码扫描器，可以探查许可等信息。

**减少技术债务**

一旦清楚了其他人的软件会对你造成何种影响，你就需要评估由此所带来的风险和问题了，并且需要紧密追踪这些软件的补丁、升级信息及Bug报告等，这看起来确实不太容易。

OWASP曾提到过：

> 从理论上来说，搞清楚你当前是否在使用任何易受攻击的组件或库应该是很容易的事情。不过遗憾的是，攻击报告有时并不会以标准、清晰的方式明确指出组件的哪个版本会受到攻击。此外，并非所有的库都使用了版本化的系统。更糟的是，并不是所有的攻击信息都会被写到易于搜索的地方。

**补丁与升级**

知道问题的严重性是一方面，修复问题则是另一方面。

对最新的发布打补丁并非易事。最好能在外围打补丁，因为补丁并非总是适合于你使用软件的方式：Apache、Tomcat、Web Service库、客户端组件等。我们要更加谨慎地管理后端代码。如果每当出现一个Linux或是Oracle RDBMS补丁时你就需要立刻打上，那就说明你的架构可能有些问题。

升级更是一个大问题了，升级到最新的OS、RDBMS、VM等都涉及到很高的代价与风险。你需要承担起这个工作，因为供应商会要求你这么做，你能获得他们支持的唯一方式就是升级到最新的版本上。

虽然可以通过升级的方式获得在可伸缩性、管理性及新特性等方面的一些优势，不过升级项目还需要更加关注一些潜在的问题：功能回归、兼容性问题、操作流程的变化、对其他系统的依赖变化等等。升级之后，大多数软件会变得更大而不是更好，也许会加入很多新特性，不过你可能压根就用不上这些特性，这也意味着需要花更多的时间进行安装、配置和测试。你需要搞清楚所有变化的地方，重新进行测试和调优。

**这只是冰山一角**

就像造成泰坦尼克号沉没的冰山一样，很多技术风险都处于隐藏状态，当发现时已经为时太晚。你得清楚风险的大小，采取负责的态度来管理这些风险。

拥有资源并能对厂商施加影响的大公司会更加主动。比如说，Veracode就为那些想要对第三方代码进行扫描来查找风险和Bug的企业提供了第三方的扫描服务。

我们所要做的就是检查我们所使用的软件，知道其作者是谁，紧跟缺陷与Bug报告，清楚地知道使用其他人的软件有什么风险。我们无法准确预测风险，也没法评估风险的代价，但这并不是说我们就可以忽略掉他们了；相反，我们还是要对其持有谨慎的态度。

[http_www.infoq.com_cn_news_2014_01_dont-let-other-technical-debt]: http://www.infoq.com/cn/news/2014/01/teaching-best-way-learning
[Jim Bird]: http://www.blogger.com/profile/17371102366836131341
[Link 1]: http://swreflections.blogspot.ca/search?updated-max=2013-11-08T08:17:00-08:00&max-results=7
[Link 2]: http://c2.com/cgi/wiki?TechnicalDebt
[Link 3]: http://martinfowler.com/bliki/TechnicalDebt.html
[Link 4]: http://blogs.ripple-rock.com/SteveGarnett/2013/03/05/TechnicalDebtStrategiesTacticsForAvoidingRemovingIt.aspx