当我构建应用程序时，我会在此过程中构建框架。我最近意识到，并不是每个人都认为这是正常的，所以我想我应该说明一下我所做的事情，以及为什么我认为这是一个好主意。
但是，让我们暂时停下来，简要讨论一下我所理解的软件开发框架。框架的例子有像React这样的前端web框架，像Django这样的后端web框架，像Ant Design这样的UI组件框架，像SQLAlChemy这样的ORM，或者像mstform(我帮助创建的)这样的表单库，等等。
框架可以很大也可以很小，但最终它是满足某些任务的代码，您可以通过插入自己的代码和声明来控制这些任务。框架本质上是声明性的，声明往往比包含大量移动命令性部分的代码更容易理解和维护。这样，框架还可以帮助您构建应用程序。我的文章“框架模式”讨论了框架让您做到这一点的许多方法。
我首先要完全承认我的偏见：我喜欢创建框架。但是，除了享受它之外，我还认为当您构建大型的、长期的、成功的应用程序时，这项活动会带来巨大的好处。
例子很好！在过去的二十年里，在构建应用程序时，我编写或帮助编写了以下您自己的框架：
框架是开销。你需要学习它们。他们可能会挡道。它们可能会对性能产生影响。
为什么不干脆完全避开它们呢？使用平台，无论是Web浏览器、操作系统还是其他任何东西。
我认为这是一种错觉。平台已经是一个框架了。如果它适合你想做的事，那太好了。但对于您的特定目的而言，它可能不是一个很好的框架。
更微妙的效果是，框架还有助于维护--它们为应用程序代码提供了一种结构，使您可以更容易地决定如何向其添加新功能，并使您的代码库更容易导航。
成功的应用程序往往会随着时间的推移而增加复杂性。框架可以帮助您防止应用程序变成一大团泥巴。
为什么要推出您自己的框架，而不是仅仅构建在现有框架之上呢？毕竟，现有的流行框架有很多好处：它有文档记录，你可以雇佣已经知道它的人，也许最重要的是，你不必自己构建和维护它。即使你选择了一个不太受欢迎的框架，这仍然意味着你不需要构建和维护它，而且那里有太多的东西。
所有这些都是真的，我鼓励人们在可能的情况下使用现有的框架。但是，每个使用过框架的人都知道，您往往会达到这样的境地：让框架做您想做的事情的唯一方式就是丑陋的方式。这并不奇怪--所有的应用程序和所有的开发人员都是独一无二的，而框架试图泛化关注点，所以它很可能并不总是完美地适合您。
这通常是可以接受的--您通常很乐意为框架提供的特性付出更多工作的代价。但有时这并不好；有时编写好的代码所需的代价太高--它很难编写，很难测试，或者维护负担很大。
无论您选择使用哪种框架，都会有差距。如果您现有的框架没有意见，并且您找不到更小的框架来以令人满意的方式帮助您，那么您的应用程序将会有一些重要的功能。仅仅通过做一件重复的丑陋的事情来通过它，你必须付出的代价太高了--代码变得无法维护，甚至不可能正确编写。对于次要功能来说，这可能是可以容忍的，但不幸的是，它最有可能发生在您的应用程序的核心功能中，在那里您花费的精力最多。那该怎么办呢？
这就是我开始考虑推出自己的框架的时候。我将自己的框架集中在应用程序最需要帮助的问题上。好处是我可以降低应用程序代码的维护成本，完成困难的目标。代价是我需要编写和维护框架。
我认为人们经常低估了这样做的好处，高估了成本，所以我将两者都讨论。
您从任何框架中获得的好处都是一样的。您的自定义框架有助于将您的代码组织到有助于维护的结构中，并使困难的事情变得更容易。您自己的框架很可能非常适合您的应用程序。另一个很大的好处是，如果框架需要新功能，你不需要等待任何人，只需添加它们即可。
应用程序代码往往很难自动测试。这是因为应用程序本质上倾向于集成各种东西--服务器、文件系统、数据库等等。它是一个整体。这意味着应用程序测试倾向于集成测试，并且集成测试比子系统测试更难编写、运行更慢、更难维护。
但是您的框架的代码不是应用程序代码，不会受到这些问题的影响。它是一个子系统。测试往往更容易编写和维护，并且可以快速运行。因此，通过创建应用程序功能的框架，您已经将该功能从困难和令人沮丧的测试领域中剔除出来，并将其投入到有趣和更容易测试的领域中。
因为您已经将框架与其余功能分离，所以更容易确保框架和应用程序之间的松散耦合。松散耦合和测试允许您在框架代码库中非常快速地移动，并做出可以立即对整个应用程序产生重大影响的更改。
记录框架也更容易。这是因为你有一些单独的东西，你可以指出它不是很大，因此不是压倒性的要记录的。
顺便说一句，如果您将框架分离到自己的软件包中，并将其与应用程序分开维护，那么所有这些事情都会变得更容易，尽管这也有缺点--您需要管理这些包--所以请根据具体情况来决定是否应该这样做。
所有这些都意味着框架的维护负担比您预期的要少--如果您从应用程序中提取一个框架，您可以有效地将应用程序中较大的维护负担转换为框架中较小的维护负担。
但是您仍然需要创建框架。这是不是只有精英天才程序员才能做到的超级困难呢？这样想很酷，因为这意味着我是一名优秀的天才程序员，但我实际上认为框架创建应该而且可以成为任何开发人员工具箱的一部分。这是你可以学到的东西。
创建框架的行为可能看起来令人望而生畏，但框架可能微不足道，但仍然是值得的。许多框架可以放在单个代码屏幕中。
下面的一些内容可能非常适合一个代码屏幕和区域框架：
一种定义如何在Excel中导出和导入特定数据模型的字段的方法。
一种使用此包装器使为SOAP端点编写测试模拟变得更容易的方法。
您会注意到，我很难将这些小框架描述为我可以，而不是简单地说后端Web框架或形式库，它们会立即为许多人唤起一大堆关联。(后端Web框架是后端Web框架，后端Web框架是后端Web框架)。这是因为这些框架是为非常具体的目标而设计的。
将现有的Reaction Table组件与后端REST服务集成的前端存储。它负责同步分页、可搜索性、可排序性，并管理前端URL参数。
一种可定制的方式来标准化前端JSON有效负载和后端数据，其中出于安全目的，字段是只读的。
再说一次，你会注意到要表达我的意思要困难得多。只要你能定义它们对你自己和使用它们的人有什么好处，那实际上可能是一件好事。这意味着您正在为特定的应用程序解决实际问题。
顺便说一句，一开始我不能很好地描述我的前端Web框架Obviel，因为人们当时还不太熟悉这些想法--在Backbone、Ember、Angular、Reaction和Vue出现之前。现在很容易了。
我不会在这里深入讨论如何创建框架的技术细节。查看现有框架以获得指导，并阅读我的框架模式文章，而不是我想讨论在构建应用程序时增量创建框架的方法。
当您开始构建应用程序时，您不会知道需要构建的所有框架。只需迭代构建应用程序功能即可。但是要注意框架的机会：那些重复且令人讨厌的代码。一般规则：重复的(主要是)声明性代码是可以的，但是重复的命令性代码是有风险的，因此是框架的机会，可以帮助它更具声明性。
当您将框架集成到应用程序中时，首先处理单个案例，然后将其扩展到您可以使用的所有其他地方。因此，首先使用单个表单尝试您的验证系统，在需要的地方进行调整，然后将其扩展到所有其他表单，并在执行过程中对其进行调整。
确保花时间转换现有代码以使用您创建的框架。这可以让您深入了解您可能想要修复的框架中的差距。一致性很重要。程序员首先在应用程序中查找示例代码。确保所有现有代码都使用新模式，这样不使用框架的旧方法就不会在不经意间传播开来。
寻找发展现有框架的机会。您的表单验证库可能会在相同的验证阶段自动清除无效字段或设置默认值。由于您已经将其扩展到所有表单，现在很容易在您的应用程序中的任何地方一次性添加此新功能。
不要过于担心你的框架在另一个上下文中是否有用，如果它在单个应用程序中对你有帮助，那么它已经很有用了。但是一定要对自己假装你会把它开源。有很好的测试和写作记录和变更日志。未来会感恩的。
而是因为您没有将其开源，或者因为您的开源项目有1.5个用户(就像我的大多数用户一样！)。如果你需要的话，不要太害怕在清晨破坏API。把它们塑造成湿润的黏土。
在你能使用的地方使用现有的框架，但是当你能做到的时候不要害怕使用你自己的框架。这看起来可能令人畏惧，但它是可以学习的。通过提取框架，您的应用程序和框架都可以变得更易于管理。
因此，下次处理应用程序时，要寻找框架机会。不要过于雄心勃勃，要从小处做起，然后慢慢发展你的框架。这是伟大的，给它的开放源码的待遇，测试，文档和变更日志，但它并不一定必须是石块的权利，因为这一点。它是你自己的框架，你可以让它做你需要的事情，即使你在这个过程中改变了主意。
因此，在您的应用程序花园中播种一些框架种子，并从中获得乐趣！