大概是在15年7月份开始做一个后台管理系统，用的是老一套php+jquery，前端也没有工程化的东西。慢慢的在我们开发的过程中遇到了问题，前后端太耦合。一个html模板，前端用到他，后端php渲染也会用到，很容易导致出现各种意外。对开发效率有很严重的影响，所以我们决定前后端分离。前后端分离意味着之前php渲染的东西由前端去渲染，这就要求不能再去用之前的这种形式，我们决定放弃jquery，去选择一个mv模式的框架。
15年底时vue、react刚开始流行起来，当然收首屈一指的要数angular了，无论在影响力还是各种资源的丰富上来说，都表现尤为突出。我们意识到我们的问题，也顺应趋势(确实有这方面的考虑)，决定开始一次重构。选择angular作为主要框架，配合semantic作为ui框架，构建上选用了gulp，撸起袖子就开干了。当时没多少页面，一个月多的时间基本完成。相比较jquery，angular是直接由数据去驱动页面，而不是直接去操作dom，这样前端的重心会放在数据的处理上。这种改变相比以前的方式简直是里程碑式的转变，是一种开发思想的转变。
第二次重构是在17年4月份。这个时候我们业务开始慢慢扩张，复杂度也随着增加，对开发效率上有很大的要求。并且angular脏值检查比较耗性能，组件上不够灵活。另外我们也需要一个包管理工具，而不是require js。于是在内部开始讨论起来，用vue还是react。虽然多数选vue，不过最终还是选择了react。这时业务比较多，不可能是全部重构，而是对于新的业务采用新的框架，老的业务还是在老项目去维护。我们用新框架首先做了我们的邮件编辑器，拖动各个素材模块编辑，用起来很棒。基本用了半年的时间里我们将以前的全部业务逐步迁移过来，并且在此项目上做了相册、视频、论坛、基金会、商城等一些列的功能。最后还是觉得当初选择是对的，相比vue，react在组件化上更灵活。这主要得益于react的组件就是单纯的类或者函数，这样代码的复用性也高，其次jsx在控制流程上真的很棒。
我们也在react状态管理器上做了很多探索。开始是一把梭的东西，所有的状态都由redux去写，很快就暴露出了问题。 1.过于繁琐，需要定义action type，还要dispatch一个action。2.单一状态树导致很难对数据做模型设计。比如我们要将列表单独抽出一个列表数据模型，用redux实现起来还是比较费劲。redux比较适合做一些全局状态的管理，对于后台这种数据量多，数据结构稳定多样并不适合。于是我们小范围的尝试了mobx。mobx有4和5两个版本，由于我们对于ie9这样的浏览器还是需要兼容的，所以去选择了mobx4。尝试了一段时间后，还是觉得有些不足。1.不是纯的数据，因为mobx4对数组监视是基于类数组，而不是真正的数组，这样会在有些地方埋坑。2.副作用大。修改一个属性，就会不知觉的触发一些组件的更新渲染，这种隐形的渲染触发方式难以接受。3.库有点大，不是小而轻。基于以上原因，我们开始思考。对于复杂业务，面向对象任然是比较好的解决方案。我们也不理解为什么很多状态库要搞得这么绕呢，比如vuex，如果谈状态的严格性，react中state也属于宽松状态。我们觉得约定大于配置，不要过于追求过于严格而去牺牲开发上的一些东西。所以我开发了mdel库，虽然他不是特别好，但是在我们的项目中用起来特别爽。我们将所有的状态进行归类，用模型去组织状态，比如列表模型、表单模型、弹窗模型等。那儿用只要new一个，他就是一个全新的状态，他也没有和其他库一样很繁琐的去定义action。另外一个优点就是配合typescript，对于数据和方法，编辑器都有很明确全面的的提示，开发起来蛮爽。并且他也是一个小而精的库，一个库只做他应该做的功能就行了。
不止在状态管理器上，随着业务量的提升(130个不同的页面)，我们也在各个方面去探索。1.文件结构上，由于最开始没有将src目录设置别名，导致修改文件目录需要改很多东西，牵一发而动全身。2.将api单独抽出一层，这样结构更清晰，不过我们开始做的不对。一个接口，我们将请求的参数也固定进去，这样在扩展这个接口的时候前端只能去新开一个接口，可扩展性差。后期我们将请求的参数改成动态的，只固化请求url和请求类型。3.我们选的ui框架是antd这样的重型库，但是我们在界面上想有自己的一些特色，不至是单单改个主题。我们也觉得有些组件对于我们来说不合理，比如Select组件，如果他的值不在选项列表中，则会展示这个值。如果能重新选择，可能会考虑element ui这样轻量级的库，不过现在去换已经没可能了，所以我们对实际用的antd库做了目录映射。4.webpack打包上编译时达到4个G内存，直接导致把其他的服务挤崩调。我们google了很多内容，没有明确的解决方案，就翻webpack文档，终于在分割代码中找到突破口。4.为了更好的提升代码效率，我们用typescript重写了一些单元库，这样代码质量提升不少。一个好的架构，一定是在质量和开发效率有很大的优势，也会越来越工程化，需求上不可能什么都会做，开发上也不是随心所欲。
不过有点遗憾的是还是离开的这家公司，在新的一家公司也是做后台管理。感谢以前踩过的这些坑，迎接我的将是新的坑和新的希望。前进的道路上会有各种各样想象不到的事情发生，但前行的决心不会改变。