本文最初发布于 Nils Norman Haukås 的个人博客。
我认为，我们的眼光不应局限于库和框架，而应该重新发现模式和原则的价值，这样可以减少破坏性变化，让我们构建的东西更持久。
一段时间以来，我一直秉持“编写库而非框架”的理念。最近，我开始思考，似乎可以对这个观点做一个富有成效的扩展，即原则胜过模式，模式胜过库，库胜过框架。
让我们澄清一下这几个术语：
- 框架：这（通常）是别人的代码调用你的代码。为了实现这样的调用，你的代码需要符合框架所定义的约束。通常，这些约束有非常明确的界限，编码时很难绕过。反过来说，在框架的约定和规范下编码，你往往会获得很多有用的功能，加快编码速度。
- 库：这（通常）是从你的代码中调用别人的代码。与框架相比，库对你的代码施加的限制比较少。通过使用一个或多个库，你可以重用别人的代码来解决自己的问题。库更容易组合和互换，而同时使用不同的框架可能会带来麻烦。
- 模式：这是一种描述性的、可重用的代码编写方法（见：软件设计模式）。模式在模糊性、适用性和规定性方面有很大的差异。举例来说，有尽早返回模式、构建者模式、行为者模型、模型 - 视图 - 控制器、洋葱架构、微服务、宏单体、单库和流式架构等。这些只是我能想到的一些模式，涉及编程模式的书很多。
- 原则：这是一些一般指导原则或是以规则形式表达的理念（如经验法则），可以帮助你写好代码。尽管与几千年来一直在建造房屋的木工领域相比，编程是一个非常年轻的领域，但是开发人员已经设法提炼出一些有用的原则来帮助他们开展工作。举例来说，有 SOLID 原则、不要重复代码（DRY）、不要过度设计（YAGNI）、敏捷宣言、迪米特法则、海勒姆法则。还有很多，在我写这篇文章的时候，我刚刚发现了这个收集编程原则的网站，很不错！
这里我必须得补充一句：不要过度使用和 / 或在不适合的情况下使用它们（见：工具法则）。例如，这里有一篇题为“错误的抽象”的文章，开发者 Sandi Metz 对开发人员不惜一切代价应用 DRY 原则的倾向做了精彩的点评。
谁来维护维护者？我在这里并不是说我们应该停止使用框架和库，但我们应该认识到，使用它们是一种权衡，我们付出一些成本并获得一些功能。比如说，保持更新的成本。代码库更新滞后可能会遭受漏洞攻击。相反，如果你不加辨别地安装最新的更新，就为供应链攻击（恶意代码被插入到一个或多个软件包中）打开了大门。
除了与安全有关的成本外，还有一个风险是，你所依赖的代码会因为作者倦怠或内部团队变化而被废弃。显然，一直都有各种各样的东西被停止使用。对此，你可能会反驳说：“它是开源的，我们可以创建分叉。”这倒是，但你会维护它吗？我认为，在添加任何特定的依赖时，问问自己：放弃这个依赖的可能性有多大？如果出现了这样的情况，我应该怎么做？维护它还是换掉它？至少，库往往更容易替换。
我们如何衡量一些代码项目是否有被放弃的风险？我们倾向于看最近的活动，只要试着在 Github 上搜索”is this dead“。面对问题的冲击，作者要么宣布项目破产并将其归档，要么不对问题做出回应并逐步淡出人们的视线，要么加速推出新的功能并扩大代码的适用范围，解决任何用户遇到的任何问题。屈服于这样的功能热，很快就会导致破坏性的变化，需要重构代码，记录升级路径，并对那些拼命想跟上所有变化的开发者的问题做出回应。任何成熟稳定的技术都有可能被宣布“死亡”，并被这个超级敏感的行业所剔除。关于这一点，我在文章“好代码之死”中提到过。
使用他人的代码也会带来隐性的变更成本，升级或放弃都会很痛苦。框架和库通常会引入它们特有的概念。换句话说，如果你决定转到另一个框架或库，那么你通过使用和调试这个工具所积累的所有经验可能都将变得毫无用处。而且，眨眼之间，你所依赖的框架就会发布一个重要的版本升级，删除旧版本中特有的概念，使你辛苦积累的所有经验都失去意义。再加上沉没成本悖论，这种成本很容易在不知不觉间加剧。
超越库和框架我觉得，在我们寻找新的、更好的方法构建技术时，我们不应该把我们的思维局限在从库和框架中寻找答案。
但是，除此之外还有什么呢？
在开始回答这个问题之前，我想指出我在网络上偶然发现的一些有趣的暗流。首先，Adrian Holovaty 有一个有趣的演讲，题目是“一个框架作者的反框架故事”。他认为，在没有框架的情况下也完成可以构建出功能丰富的 Web 应用。其次，当读到 Remix Run 框架的理念时，我感到万分惊喜：
我们的抽象足以保证你的应用程序的性能 [......]，而且不会隐藏底层技术。了解了如何在 Remix 中用 links 预取资产，就学会了如何在任何网站中预取资产。
这句话读起来就像是我上面提到的变更成本的解药。学习一些技术意味着学习可转移的知识，这是一个加分项。
第三，我了解了“Stackless Way”的概念，并阅读了 Elise Hein 写的一篇非常有趣的文章。她探讨了这种非正统的想法，即追求不设置构建步骤、不使用框架的“无栈（stackless ）”。
当我创立网络组件工作室时，我也选择探索一下自己可以在多大程度上采用无栈方法。我发现，现代浏览器功能非常强大，可以在不引入外部代码的情况下编写出丰富的功能。我感觉这相当令人振奋和自由。是的，这种方法仍有一些不完善的地方。不过，这里所缺少的可能不是成熟的框架或库，而是一本模式和原则手册。
想象一下，因为我们投入时间去发现和建立模式与原则，而使得一个行业不再那么依赖库和框架。我相信，这样的未来可以减少维护者的倦怠，减少破坏性的变化，为我们带来更优秀、更长久的程序。
今后，你仍然会发现我在使用框架和库，我甚至会编写一些新的框架和库。不过，这种无栈方法、有用的模式和原则、可转移的知识，是我要寻求和探索的。
作者 Nils Norman Haukås 是 Netlife Bergen 的首席技术官，他负责删除代码，打造技术卓越的安全空间，并研究减少会议的新方法。
查看英文原文：
https://nilsnh.no/2022/04/09/innovating-beyond-libraries-and-frameworks/
了解更多软件开发与相关领域知识，点击访问 InfoQ 官网：https://www.infoq.cn/，获取更多精彩内容！
,
