在开发OA或其他企业软件时，很多基础的库、组件其实都是公用的，很大部分的概念、场景是具备高度认可以及公共认可度的，这也是一些toB的产品，可能从定位、功能甚至界面会累死的原因（比如钉钉和飞书，用友和金蝶，致远和泛微）。总体上是殊途同归，细节彼此差异，总体大同。

为什么要开发一个框架

我个人在OA这个领域深耕多年，对于系统的理解有了一定的积累，但是在开发的过程中仍会感觉不便、繁琐，这个原因是因为你再熟悉某种产品、熟悉这个产品能够达成的功能和业务场景，你仍无法快速的基于这些认知来完成开发的任务，原因很简单，这些领域基本没有开源产品（或者那些开源的根本算不上成熟的产品），于是但凡有公司或组织想要独立开发某个企业方向的软件或系统时就会遇到各种大坑，其中最大的坑可能就是基础的开发准备，这些基础往往并不是直接的业务需求，但却又耗费大量的人力物力财力。

并且开发建设这些基础的过程中，比如构建组织架构、构建考勤系统、构建表单系统，往往会有不同技术路线的选型，这些选型并没有万金油式的通用技术，稍不小心就会走向前期没问题，中后期问题严重的地步。这也是我想开发一套开源框架的原因，将所学所知落于实际的一套框架中。

这套我称为框架的东西，可能在一些人眼里并不能算是框架，因为实际上它是基于其他框架的，我目前选择是Symfony这套PHP语言的框架，所以它不能算是自己写框架了。这也是我想实现它的原因之一，当你拥有一套Symfony, Laravel, SpringBoot, Django, Rails, Koa等任何一个你认为的完备框架时，基于这些强大的框架开发一套公认的已经有成熟套路的企业产品时，你依然会面临巨大挑战，其中原因听我娓娓道来：

  • 以上框架虽然组件丰富、生态繁荣、开发者众多且拥有无限的第三方开源库和支持，但它们的核心仍然是围绕Http请求展开的MVC、Resutful API的为通用互联网产品打造的框架，它们有足够的请求、响应、模板、数据库模型、缓存、队列、多语言等等众多的支持，但与此同时没有任何一家会自带UI给你，不会有公司、部门、人员、权限系统、菜单、成熟表单系统等等。理由很简单，这些框架追求的是通用，像前边提到的这些需求都属于具体化的功能实现了，越具体就越不通用，这是很难协调的矛盾。
  • UI 是个很费神费力的工程，也许你会说我们有现成的前端组件库或者现成的开源admin用来修改和利用。但遗憾的是即便最完备的react, vue UI库恐怕也不能完全满足企业应用的需求，而且前后分离的项目自身也存在一些很难解决的弊端，如我前边所说世界上并没有银弹能够搞定所有场景。仅就原生库不可控一项，三方UI库就很容易让项目沉沦。
  • 你离项目需求越近就越省事，但同时你离它越近修改起来就越费事，所以找到一套折中距离的方案是最棒的，但我可能肯定你哪怕花钱也很难买到一套理想的开源方案（能买到的大部分是东拼西凑开源产品的东西），你很难基于你得到的这些代码省心省力的继续开发出你要的结果。
  • 熟悉业务的产品经理并不一定能将开发人员带入准确的实现思路上，熟悉开发甚至有高难度系统开发经验的研发人员并不一定足够熟悉企业的业务场景和具体的功能实现。当然从需求部门内收集需求，然后按照需求开发是肯定能够满足需求的，但是这并不是企业软件的设计之道，因为大量的企业需求是隐性的，并不会有人直接给你说组织架构调整会突然批量调整、审批流程的调整有多频繁、敏感的数据连开发人员都不希望能看到，真的等到一切都发生的突然，再使用敏捷迭代的思路显然就不能满足这种调整的节奏了。

在开发这套框架时，我考虑了很多可能的做法，以及结合我之前开发捷效办公这款产品的经验（值得借鉴和能够吸取教训），可能经历过捷效办公这个大项目之后我现在最想做的就是向以下几个方向改变：

  1. 以低代码形式代替0代码的做法。以生成代码的形式来构建功能，将代码暴露给用户的做法，是很值得尝试的方向，无论从致远A9(V8引擎)，还是泛微E-Cology10 无不在做着此类尝试，市面盛极一时的低代码风潮也是一个印证，我并不是一个在技术上追求时髦的人，但对于企业用户这个需求群体，其不确定性远远高于toC的产品，所以对于有实力且需求明确的企业客户，没有比把接力棒交给用户自己的研发团队更好的办法了。
  2. 前后分离未必是个好策略。仅就PC界面而言，在以Symfony这样一套拥有成熟模型、表单组件的框架支持下，显然基于它的套件是可以省很多事的。并且，在以往的项目中前后分离的做法存在着几乎很难逾越的困难，例如，权限控制、动态表单构建、调试困难等等不利因素，而且设想一下，一旦采用低代码的形式，对动态模型、动态界面的要求几乎都是要生成代码的，而一旦涉及代码的生成，就难免涉及重新打包、上线、重启等诸多问题。面对以上问题，我选择了传统的MVC的形式来实现PC的基础功能，其中包括代码的生成、数据库的Migrations、菜单的动态实现等等，目前都有了比较好的思路。
  3. 独立开发UI库和组件。在之前我从来没考虑过要自己开发基础UI组件和Admin，甚至我最常用和推荐的做法就是找一套Admin脚手架以及对应的UI开源库来实现自己想要的功能，美团的王兴曾经说过类似的观点，就是基于市面最接近需求的现成的方案来快速构建并进行市场尝试才是正确的选择，这在之前我觉着问题不大。但经历过几次UI库落伍、停更和基础jQuery, vue2, vue3更迭之后，我疲倦了，为了追求可控性和可持续性，自研UI应该是个好办法。
  4. 追求接口、测试的图形化、系统化，模型和界面构建的版本管理，即时通讯的基本库，这在一些成熟OA产品和我以外的开发中几乎都不曾涉及，我希望能借这个项目完成这些功能的开发。
  5. 追求新技术、扩展对已有框架的深入挖掘。作为一个开发者，对于新技术的尝试和老技术新应用的尝试都会让这个框架看上去有所不同，创新和改进会成为这个项目的特点。

综上所述，这个项目将会是立足于企业方向，在介于实际业务和底层技术框架之间构建一套易于搭建属于自己公司特点的脚手架工具。