通常，当我在这里写东西时，我会花时间充分思考一个观点，提出一个理由，解决我能想到的问题的所有主要方面，等等。
但是这周我已经因为使用代码库而筋疲力尽了，所以这篇文章不会出现在那些帖子中。我打算尝试一下意识流博客。
当程序员对自己说，我这里有一些代码或想法，我认为这些代码会让其他人的生活变得更轻松时，代码通常有两种大致的形式：库或框架。
库是一组构建块，它们可以共享一个共同的主题或很好地协同工作，但在很大程度上是独立的。
框架是一个上下文，用户可以在其中编写自己的代码。这可以采取控制反转、特定于领域的语言，或者仅仅是一个非常固执己见的内部耦合库的形式。这是一种谱系；两者之间没有硬性界限。判断某物是否为框架的一种方法是问问自己，我可以将其与其他类似的东西结合使用吗？或者它已经建立了与其他可能做这些事情的方式相互排斥的做事方式？"；
框架的主要特点是它们对程序员施加了限制。它们没有提供一组程序员可以做的新事情，而是对程序员可以做的事情建立了一个边界。作为灵活性的交换，它们通常消除样板，为在其上构建新的库建立试金石，并允许程序员的技能在项目之间变得更具可移植性。事实上，有时限制本身是可取的！毕竟，类型系统只不过是对代码施加限制的一种方式。限制本身并不是坏事。
但是。当你编写一个框架，希望别人用它来构建真正的项目时(也就是说，它不只是一个玩具)，你承担的责任比你使用库要大得多。
通常，框架必须提前预测其用户在其围墙内可能需要做的每一种事情。对于它吸收到自己的词汇表中的每一块拼图，它必须承担起这组任务的责任。它不仅必须注意需要在其中完成的每项任务都能完成，而且理想情况下，它还需要提供一种比正常方式更好的方式来完成这些任务。否则，为什么要用它呢？
这也转化为开发人员的体验。您的框架是否引入了超越基本语言的基于约定的行为？您最好彻底记录这些内容，否则用户将无可救药地迷失方向。您是否引入了一种特定于领域的语言？您现在负责构建链的一部分，并负责编辑器集成。
现在，如果有一个主要的组织支持这个框架，也许这个演算就会奏效。谷歌可以背角度，枢轴可以背弹簧，史诗可以背虚幻引擎。在这些情况下，框架方法是可行的，因为存在真正涵盖所有需要覆盖的基础的资源和意愿。
但是，如果没有大的组织；如果项目是由个人、初创公司或不是公司核心的小团队编写和维护的，那么它几乎肯定会在库中出错。有了库，核心概念的编辑器集成和文档更有可能掌握在语言初学者自己手中。对于库，任何缺陷--如错误、文档缺失、功能缺失、缺乏持续维护、与其他库的争议性等--都更有可能被自定义代码或其他库中的片段所掩盖。有了库，好的部分可以零碎地使用，而不必因为一个没有人会在后备箱里解决的问题而扔掉整个东西。
所以我的观点是：框架并不总是糟糕的，但它们比库更大的风险--无论是对创建者还是用户。如果您的框架能够在不损失太多的情况下成为一个库，那么它很可能就应该是一个库。如果你没有在一家大型科技公司工作，你可能没有时间或精力去给予一个框架它所需要的所有关注。图书馆不是万能的，但它们应该是首选。