企业整体技术架构思考维度（推动公司技术变革实践总结第一步）

企业整体技术架构思考维度（推动公司技术变革实践总结第一步）我们公司在2016年的时候，有N个产品线，几乎每个产品线都在使用不同的技术选型。背景介绍反对的一方认为，统一的技术选型会限定项目中研发人员的能力成长，造成研发人员会局限在某一个技术领域内，不利于人员的长期成长。一般来说，小团队肯定要实现技术架构的统一。规模以上的企业，可能在不同的业务线内部实现技术架构的统一，不同的业务线可能存在差异。我们公司人员不是很多，业务线虽然很多，但是研发人员的资源非常紧张，因为为了解决人员复用的问题，整个公司期望进行技术架构的统一。

标题

概述

一个公司，研发体系的技术架构体系是否统一，这个不同公司的要求不一样。

同意的一方认为，统一的技术架构体系可以保证公司内部人员实现研发能力的复用，保证研发人员可以在不同项目之间进行切换。

反对的一方认为，统一的技术选型会限定项目中研发人员的能力成长，造成研发人员会局限在某一个技术领域内，不利于人员的长期成长。

一般来说，小团队肯定要实现技术架构的统一。规模以上的企业，可能在不同的业务线内部实现技术架构的统一，不同的业务线可能存在差异。

我们公司人员不是很多，业务线虽然很多，但是研发人员的资源非常紧张，因为为了解决人员复用的问题，整个公司期望进行技术架构的统一。

背景介绍

我们公司在2016年的时候，有N个产品线，几乎每个产品线都在使用不同的技术选型。

1. 项目组A用.net架构。
2. 项目组Ｂ前端用flex，后端用struts。
3. 项目组Ｃ前端用EasyUI 后端用自定义MVC架构。
4. 项目组Ｄ前端用ExtJS，后端用springMVC。
5. 项目组E前端用ExtJS，后端用SpringMVC，跟项目组D两个框架。

项目组之间几乎没有交流，相关的技术问题，解决起来更多依赖项目组成员内部来进行技术实现。

时间来到2017年以后，当时后端主要是SpringMVC Mybaits（针对ORM框架，当时也经过了一番比较激烈的争吵，但是相对还好 没有走过多的弯路)。前端技术相对比较难以选择，当时有两种思路：

1. 采用EasyUI和ExtJS等相对比较成熟的前端框架。
2. 采用MVVM架构的Vue，RectJS、AngularJS三种新一代的前端技术框架。

其实对公司的业务来讲，相对来说，界面需求相对比较简单。每个技术都能实现基本的诉求。

技术选型过程

1. 选型范围

基于当时的项目实际应用，和市面上比较成熟稳定的前端框架，基本确定在以下四个前端框架中进行选择。

选型比较

关于版本选取的说明：

1. ExtJS：对于PC端来说，ExtJS 4到6基本变动不大，ExtJS6中集成了支持手机端开发的modern(也就是原来的Touch)部分，当前公司PC端的Web开发主要以ExtJS4.2版本为主；

2. Angular: 其1版本和2版本差距很大，进行了大量的优化，并增加一些标准化技术的支持，从2014年到如今也逐渐成熟，所以这里直接选用2版本；

3. React：选取了官网的最新版本15；

4. Vue：1和2版本使用差距不大，故选取2版本，性能更优。

2. 选型模型

当前选择的前端框架，除ExtJS外都是开源免费的产品。

这些框架的生命力都是非常好的，社区活跃度都很高，我们这里主要是结合公司的实际情况，分析并决策出一个更加适合公司产品需求现状的前端框架，来支撑公司业务系统的视图层的技术实现。

下面针对评估模型中的各关键特性进行具体说明：

选型比对

3. 选型过程

具体的选型对比，在此不再做详细阐述。

4. 选型结果

针对以上分项比较，对整体的情况进行如下评星：

选型结果评分

走过的弯路

虽然最终选定了AngularJS框架，但是当时公司有个技术总监，建议使用Ionic，理由如下：

1. 公司其他人对AngularJS框架，但是当时他研究过，未来他可以在这个方面基于支持。
2. Ionic虽然是手机端的开发框架，但是可以通过适配做到PC端界面展示。他预测未来移动端的应用适配将是主流。

虽然当时架构组对此表示质疑，但是最终受限于各种原因，最终通过ionic作为前端框架选型。

但是实际过程中发现：

1. ionic本身是移动端为主的技术框架，组件库本身不够丰富，许多PC端传统应用常用的组件如：树，表格，侧边栏菜单，模态框等都不具备；因此需要引入其他的库。
2. ionic自身以国外的网站资料为主，缺少中文资料库
3. 因为引入了其他的库，引入任何第三方组件，都要考虑 –prod 的兼容性，有的根本不支持这个选项
   3.前台改一点代码，编译需要等非常久的时间，严重影响效率；
4. Prod打包耗时非常严重，此为ionic框架本身的问题，官方并未给出任何关于此问题的解决方案。短则十几二十分钟，长则达到数小时
5. ionic本身的发展规划（1-2 2-3 3-4.0beta）变化都非常大，基本不具备平滑升级的可能性。这样一个“灵活多变”的还处于上升期的框架不适合作为公司的框架。
6. 使用ionic进行组件封装，目前团队资源，不具备可实时性，组件的易用性，稳定性，扩展性需要很强的前端架构能力和语言功底
7. 限于对ionic编译和运行机制了解太少（深入了解和学习的话，会花费相当的时间成本和精力），很容易触到解决问题的天花板

落地实践

在2018年10月，公司架构组总结了ionic技术选型的问题，并判断重构的可行性。

经过架构组的最终选择，最终在ng-zorro和PrimeNG之间进行了选择，最终选择了ng-zorro。

原因如下：

1. ng-zorro符合阿里Ant-design规范，在后期也是阿里团队承认的技术框架。
2. 界面风格更加现代。
3. 符合原生的NG语法，使用起来相比Ionic更加简单。
4. 为PC端设计为主，组件库使用起来障碍相对更小。
5. ng-zorro开源，PrimeNG为收费版本，对后期的扩展影响较大。

到目前为止，已经完成框架的稳定版本持续升级，目前使用起来问题不大，比较顺畅。

总结

技术的选型是一个很难判断的事情，除了前端框架在选择的时候遇到过障碍以外，在后台ORM框架中也在Mybatis和JPA之间纠结了很长时间。最终确定使用Mybaits，这一点不再做更多的说明。

归根结底，技术选型这个事情本身没有对错，只有适合。

1. 适合团队目前的技术水平，不能让做传统应用的人去选择一些互联网企业中的技术栈
2. 适合PC端应用，不要拿移动端的组件库去做PC端的应用。
3. 选择成熟期的技术框架，不要选择已经落后的技术架构，也不要选择太过超前的技术架构。最理想的情况是选择一个相对超前，但是未来前景比较好的技术框架。