本篇是企业服务架构演进系列的第三篇，随着前后端分离的工程设计思想逐渐形成潮流之后，各个互联网公司都在随前端开发潮流走。从此web软件应用开发变得更加专业，全栈越来越成为一个奢侈品，而另外一方面从企业服务系统中对于前端框架组件的应用选型也能看到一些端倪。
本系列主要讲解我在之前公司的一些工程设计见闻和思考，整个系列大概有7篇文章。
- 企业服务架构演进-引言
2.企业服务架构演进-单体架构的变迁
3. 企业服务架构演进-从jquery到vue的工程实践
- 企业服务架构演进-单库多服务的尴尬
- 企业服务架构演进-第三方系统与自研之道
- 企业服务架构演进-走上造轮子之路
- 企业服务架构演进-重复开发之殇
一、jquery最后的辉煌
我在上大学的时候，通过培训机构学过一些js，尤其是jquery.js。这个组件尤其精良，打开了从前端到后端的道路，想想，如果用原生js写ajax请求是不是很啰嗦。jquery.js封装了很多api，对于当时还在学jsp的我要上手一个前后端都需要开发的项目，那么jsp里要引入跟jquery.js有关的很多js资源。毕业之后到公司要真正去用jquery.js写项目的时候发现是多么的眼熟，公司的web框架其实比较简单的针对veloctiy+HTML渲染做了封装。在之前说过的物料管理系统中，假如我要实现一个动态表格的功能，我需要手动通过jquery.js去操作页面元素，封装一个函数，然后写成一个js文件，最后引入到html页面中。这个系统的前端代码看上去有点凌乱，我的意思是它一开始是由几个刚毕业的实习生搞起来的。并没有什么规范可循，至于css样式和UI则是大概还能看的水平。由于我和其他同事的开发水平都不是很高，js函数，css样式怎么写的都有。客观上来说我们需要把大量精力放到后端的业务代码上，毕竟如果真把前端CRUD系统的界面搞得特别美观在当时也不太现实。对我来说比较痛苦的事情是用jquery.js做一些数据表格的计算，由于精度问题导致经常出现线上bug，而本地和测试环境却不复现，这个问题在线上也不是必现的，每个月会出现1-2例数据计算错误的case。当这个系统下线的时候，我心里唏嘘了几次，五味杂陈。再之后便离前端越来越远了。
二、angularjs的落地实践
在进行物料管理系统的多轮迭代之后，部门团队的人数也逐渐增多了，新启动的项目也多了起来。对我印象比较深刻的就是财务系统，虽然我没怎么开发过财务系统，但是在进行前端项目选型的时候大家也跟项目组长，部门老大一起沟通了，决定尝试用当时比较火的angularjs。大概是2017年，vue也还没听说过。另外一方面会议室系统也很快上线了，用的就是angularjs.我们当时的一位主力开发还买了angularjs实战方面的书籍。于是我们大概5-6个开发人员就踏入了
前端angularjs开发的泥潭中。经过大概1个星期的时间我们了解并掌握了angularjs中的一些技术概念和部分实战能力，比如angularjs中的指令，事件，表单，路由等实用功能。但是这些仅仅能应付相对简单的系统。对于后期财务系统来说，可能就是一个噩梦。因为财务系统有很多表单，主力开发团队对angularjs的掌握并不是那么深，对于功能模块设计，架构设计等没有做好前期规划。很多表单之间的业务逻辑都耦合在了一起，对于前端angularjs写的js文件来说，由于业务上的复杂度导致呈现在代码上特别复杂，比如一个表单js就好几千行，而十几个表单就不少了。另外一方面angularjs并不太支持热刷新，比如我改了一个js,但是需要重启项目，这个就有点蛋疼了。开发维护财务系统的第一批人员很早就走了，于是这么多表单的开发和迭代就变成了一个泥潭。比较好的一方面就是我们有几个技术比较好的大佬，在进行项目开发的时候遇到问题可以很快找到解决方案，即使我们没有太多angularjs的开发经验，但是我们在项目推进和线上验收使用方面还是得到了领导层的认可。
由于项目开发的深入，我们对angularjs的了解也越来越多，同时也开始关注angularjs的一些社区发展，关注升级版本来解决一些复杂度问题，我们当时的主流版本是1.4,15,1.7这几个，但是同时也在观望未来是否还会继续使用angularjs。
angularjs火了大概1年多，企业系统中也有几个是用它做前端主力开发的，我们也沉淀了一些公共组件。但是这段经历给我的感觉就是如果做不到前后端全能的话或者没有想法走全栈路线其实最好的方式就是专注于业务和自己熟悉的开发范围。
三、vue在新系统中的实践
时间来到2018年，我们的团队中有了产品，后端开发，测试，前端开发，UI这些角色，团队人员配比比较全面，我们也开了很多其他项目，比如权限，hr系统，招聘系统，这几个哪一个拎出来都是一个企业级的项目。一方面是业务的场景比较复杂，另一方面迭代的次数比较多，在各自的业务范围内几乎实现了较全的功能，也支持了很多业务线，整体提高了公司的办公效率。团队小范围调整之后我们开了权限系统的项目，这个项目主力三个后端开发，两个前端开发，1个测试，1个产品，1个pm.经过1个多季度的时间基本完成了3个大版本的迭代。我们改变了原有的开发模式，后端专注于功能接口和业务逻辑实现，前端负责数据渲染，UI样式等。同时，在组长的带领下我们开始尝试写后端api然后跟前端同学对焦，并制定一些接口交互规范，比如code,msg,data这种的封装，对通用的工具组件下沉到部门公共组件jar包中，并引入。每个负责自己模块的同学拿到需求之后先看需求，开需求评审会议，然后梳理业务逻辑，梳理需要开发哪些接口，需要依赖哪些接口等等，之后后端同学设计表结构，整理后端接口文档，并开方案设计评审会议。经过两个会议之后，正式写代码实现业务逻辑就开始了。再之后，就是各自按接口模块进行自测联调，随时沟通并调整接口内容，不断对焦业务需求。这几个项目前端采用的是VUE，前端同学负责自己项目开发的环境，并实现一些基础组件，有些项目也是使用了基于VUE的封装框架比如vue-element来提高开发效率。
在这些项目的开发过程中，我们可以看到前后端分离确实可以解决一些复杂度比较高的企业级项目，但是也看到了这种模式的缺点，就是联调，维护，人力等成本都比之前的高一些。比如新来的前端同事不会VUE怎么办，联调迭代新功能如何定制接口规范等问题。
实际上，在进行落地实践中我们也遇到了一些问题：
1.开启新项目之后前端也需要申请一个域名，增加了一些运维困难
2.后端需要开发适配单点登录的相关逻辑，升级sso-client包
3.前端后端联调的环境问题。
其中我对第三个问题尤为印象深刻，一方面前端也要申请域名，测试，沙箱，线上都要申请，如果是开发环境那么就要绑定hosts这个对前后端开发来说都不太友好。另一方面，由于单点登录实现机制的限制导致我们经常遇到跨域的问题，出现这个问题几乎都需要前后端一起看，而且需要相对较长的时间解决。
最后总结一下，本文其实没有多少技术含量，总体就是描述一下我这几年来从开始写前端代码到最后专注于后端的一些见闻和体验，技术发展一直都很快。有时候全能并不一定是好事，在一定的阶段里在垂直领域做到优秀其实已经很不错了。