本文主要是介绍企业服务架构演进-重复开发之殇，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
本篇是企业服务架构演进系列的第七篇，本篇将讨论一些令广大软件开发者深有感触的一些关于项目重构，项目重建等相关话题，并通过几个切身经历过和使用过的一些系统case来阐述一些更深刻的问题。这些话题引申出来其实是有些严肃的，这深刻的影响到了企业发展的效率，包括人力投入，时间投入，运维成本投入等。很多行业最忌讳的一个词就是返工，虽然很刺耳，但是在重构，重建的包装里面其本质上来说就是没有做好，低效。
- 企业服务架构演进-引言
- 企业服务架构演进-单体架构的变迁
- 企业服务架构演进-从jquery到vue的工程实践
- 企业服务架构演进-单库多服务的尴尬
- 企业服务架构演进-第三方系统与自研之道
- 企业服务架构演进-走上造轮子之路
7. 企业服务架构演进-重复开发之殇
四代权限系统的煎熬
1.第一代权限系统其实在16年做物料管理系统的的时候就在开发了，开发完成之后对接4+系统。在之后随着业务的发展，各个项目逐步上线，对于更高的权限管理场景则显得不太能支持。
2.第二代系统研发上线之后直接被弃用–>说实话这其实是在领导层撕逼的情况下导致项目没有推动起来，另一方面也是没有充分调研业务权限需求，数据模型不够合理导致的结果。
3.第三代系统研发的目的是为了解决大量项目上线之后广泛的权限对接场景，同时从根本上解决数据权限，操作权限等风险问题，第三代系统目前整体承接了第一代权限系统的权限管理需求，整个部门的多个业务系统则在这个系统上面进行权限管控，包括管理员权限，数据权限，按钮权限等。这个系统为了与后面新做的权限系统区分开来我们内部叫做统一权限2.0系统。
4.第四代系统通过德勤软件公司提供的权限管理设计方案进行开发，充分按照上市公司的管理标准设计，从不同方面和业务模型去整体输出对各个业务线不同系统的权限管理能力。整个项目周期持续了半年，以scrum的形式迭代开发，原先需求是专门为某一业务线去设计的，后来根据业务线需求，将整个服务拆分为4套，不同业务线自己按照包源码去部署，数据库隔离，代码共用。整体将核心代码打包，再在外面套一个壳标示不同业务线的权限管理系统。
这里比较煎熬的情况是一个部门要维护接近3套的权限系统还包括外部部门接入的，需要推动迁移，同时最老的一套系统当时存在一个滥用redis缓存导致的严重bug，在整个权限系统的设计开发过程中实际上付出的时间和人力成本是非常高的，但是从整体上看权限系统越来越符合业务线需要，数据量上也越来越多。
招聘数据报表难产的一个季度
背景：这其实是一个面向面向老板编程的需求，因为真的仅仅就1到2个老板去用，而且频率也不是特别高。
报表维度是按月维度统计的，基于不同指标去计算一些数据，同时也加上了按部门计算统计的需求，开发难度和成本也比较高。了解需求之后制定开发方案并进行评审，第一版搞完之后，由于数据维度的问题重新调整计算了一版。再之后由于统计维度的问题重新跟hr系统打通并重构了一版。在整个过程中我是唯一一个全程负责这个功能的人，每一版本几乎都相当于重做了一次，比较庆幸的是我当初的设计方案和表结构设计经得起这么折腾，改动点也不是特别多，但是最后一版对于hr系统的数据要求则显得复杂的多。报表数据源一开始只有招聘系统本身的，我分为三类处理的，后续根据需求变更的内容有些数据需要从hr系统中取，但是取之前也需要按照报表维度的要求计算，否则无法实现统计功能。
工程效能研发系统的系统迭代演进
第一版工程效能系统由兄弟公司引进，后由于整体功能复杂，部分模块存在耦合，导致代码可维护性和稳定性存在问题。第二版由企业信息系统专门负责建设工程效能研发，与资深PMO大佬合力研发，实现了代码发布，需求管理，bug管理，集群管理等，需求看板等特色功能。
第三版根据业务线推广的工程效能系统在第二版的基础上根据自己的需求场景抽象了通用的解决能力，并尝试推广到其他业务线。看似有这么多版，实际上不同的公司在工程部署，打包，项目研发管理方面的成熟度都不同，随着容器化部署的流行，以及未来的运维管理趋势来看，整体的工程效能系统实际上也需要做一些针对性的升级。其本质就是为了应对大规模服务化提升研发效能和开发部署效率的。
OA系统的首页改版之争
OA系统的演进过程中，我在前一篇博文中有所涉及，这里的OA系统指的是公司内部改版了很多次的OA系统。整体界面风格，权限管理，业务系统集成都跟大多数OA系统类似。但是在架构方面实际上也走过不少弯路，尤其是OA系统与各个子系统之间的集成并没有特别的说明，另外一个OA本身也存在一些界面改版，整体过程中有三次大的改动。每次改动之后，OA系统的首页布局就更加清晰，各个子系统模块的划分也更合理。但是改动过程中领导层对于产品的设计方案并不认可，每次改动完之后总有新的变化，导致部门内的产品和开发非常难受，毕竟这么大的一个OA设计和交互，有自己的想法表露出来也没能被领导层认可。在这个过程中其实我没怎么参与，但是总体上看来就是折腾，折腾，然后慢慢看着像那么回事。其中，为了整体的OA界面和办公系统融合当时还到阿里公司去取经来着，后续的设计也跟阿里内部的OA系统有类似的风格，只是功能和交互设计简单了些。
本篇没有过多讲解其中的细节，但是重复开发和重复建设实际上对公司也好对程序员也好都不是一个好的事情。虽然有些客观因素存在，但是如果我们能找到一些方法论，做充分的准备和调研，尽量减少重复建设或者返工的成本的话，那么我们将有更多的资源做更有意义的事情。
整体的企业服务架构演进系列已经完结，如果你全看完了的话，希望有些内容能有共鸣，笔者最近的面试中跟一位资深大佬聊了一些，说我最近几年的工作经历中有没有对企业内部服务相关的领域行业做总结，比如领域模型，业务模型去沉淀一些。说实话我并没有，我这两年更倾向于偏技术点的业务系统开发，但是我也在不间断的思考企业内部服务的一些业务模式，在业务开发过程中比较重要的应该就是业务模型了，但是更深入的去理解业务的话对于自己的工作经历和成长也很有帮助。后续笔者会再增加1-2篇文章讲述企业内部系统相关的业务模型，领域模型等。以博客笔记的形式去综合性的展示一些企业级系统的相关业务模型和业务流程。
我最近整了一个公众号，持续输出原创内容，敬请关注：
这篇关于企业服务架构演进-重复开发之殇的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
