心路历程
先说说背景吧,项目的周期大概快8年了,看情况还有要继续的样子,本人从中期参与到目前大概有6年多时间，现在大概互联网场景下，大略我这个经历有点儿独特了; 先说说近一年来面临的情况
- 【不可控因素】部署环境的变动,当然有给到时间周期,同时包含有一些附属要求
-
windows iis-> linux -
.net ->netcore -
常规页（jq）+(.netMVC特性页)->单页应用（vue+el+webpack ） -
java->.net 的通信以及部署变更 -
代码->中间件（类生命周期、云部署）-部署
- 【可控因素】内部应用集成的改造工作超量
-
集成的块是以项目为依托,用户体系不一致 -
跨区域沟通，互相不熟悉对方业务 -
人员严重缺失、每个人方方面面都要处理 -
需求变更与新增内容同步进行 -
因为.net->netcore 硬性不兼容、前端改造部分、云组件部分、再加上集成部分的内部业务形成了多套代码管理 -
相关文档、需求以及管理性工作
基本是10死无生、删库跑路的必死之局，说说配置，长期配置为4人，会有临时协调人员大概3-4人不等,因为人员波动等问题面临这个情况时,我们的人员配置为2个人，而我几乎接下了全周期的所有工作； 之所以后续能够坚持的下来,一方面考虑到事情有始有终，本着负责的态度。另外一方面是觉得机会难得，很少有机会亲临这种从0到1复杂升级，于是乎我接下了这个挑战，分析了目前面临的情况以及主要矛盾后,将不可控因素与可控因素的变量做了合并；
如何度过的
首要矛盾
- 调研前端框架从易用性、兼容性、上手难易度考虑，常规vue-template-admin开局优先解决IE兼容性及常规如基础大文件上传、机构、用户等业务组件、增加标准的页面示例，尽快应用于新需求开发；时间托的越久后续的更新就没法终止，后期的工作量就会更大
- netcore升级，重新搭建core项目验证（生命周期/cli 编译发布机制以及要求），可行性验证完成后，对历史项目大面积移植，分析不兼容写法，增加兼容扩展包,尽快以能编译通过为目的调整；有内容交付、减少交付人为的客户方压力
- 本身有需要集成两个端,且项目体积都比较大，远程协调很多事情都是鸡同鸭讲,业务很难协调别人融入，推动缓慢，通过对其表以及页面功能与己方的调整方向融合，优先一端配合度较高的一方,重写另一方业务内容较少的部分减少人力沟通成本、和不可控因素、实在不行就只能想办法可控
- 沟通自身困境尽量压缩或延后变更及运维、优先Bug修复以及新功能的开发；保证项目现阶段工作内容的正常执行
- 复杂工作全力留给自己去做，留时间让成员熟悉新的技术及资料，正常推进工作，成员的离职在关键时候会导致崩溃和传染，减少内部成员压力，保证现阶段的稳定、尽量协调帮助,沟通很重要 延续处理
- 在完成 【新前端】 测试、正式相关验证后，要求新增功能都集中在【新前端】部分，后期新增的服务统一集中在原项目的一个地方，按照兼容包的写法规范之所以没有独立分离是因为没有时间保证之前公共的几大块内容的正确性，所以没法都集中在新的netcore上面，会影响目前环境运行 。所以考虑的是新增的接口后期的难易度为主、同时保证至少是服务层级不会有太大影响;
- 关键问题处理完成后,逐步按照用户最易看到的、重写难度、关联度低的功能进行迁移，同时接口部分，都采用新曾的方式，尽量不用原本的接口，大方向上逐步减少历史项目的比重
- 之后部署第三套环境，保证验收、同时逐步分离集中关键的服务,测试验证保证关键功能正常后,将新增的服务逐步替换此时按照服务域分步骤代理以达到linux iis环境的增量、减量平稳过渡,后续涉及到调整的服务逐步在netcore环境进行、此时能够基本做到后端服务不再新增调整内容，按照参考前端替换逻辑，同步进行后端服务操作
- 同样的之前集成通过兼容表等手段暂时搞定的java服务因为用了 [微服务] 从部署、冗余、维护支持力度来说同样需要进行调整、依次逐步解决
总结
- 多个事务集中在一起时,多想想那些是关键环节 控制好关键环节的节奏,很多事情的暂时穿插交互进行是为了减少多方阻碍,大家都放心，才能避免焦虑传染情绪失控
- 人就像一往无前的刀、破壁的时候很痛苦,挨过了、自成气魄
- 做程序的思维常常是一镜到底、寻找最短路径，但就事情的推动来说多变通才好,毕竟我们追求的是事情做好，而不是仅仅做好程序
- 反馈要有，但总是抱怨解决不了任何问题
- 艺多不压身，视野开阔才能脱离局限!
