未雨绸缪，聊聊旧系统升级改造那些事儿

本文是老系统升级改造的第三篇文章，主要谈老系统改造过程当中如何制定规范以及防范技术风险。点击连接，阅读前两篇文章：

洞若观火，聊聊旧系统升级改造那些事儿

量力而行，聊聊旧系统升级改造那些事儿

老话说的好，不以规矩，无以成方圆。在项目开发过程中须要规范，在系统升级改造的过程当中，规范的制定更加剧要，由于他不只仅关乎最终的代码质量，更事关项目的成败。在项目初期试验pilot阶段，就须要制定好代码改造的相关规范，在w项目当中咱们从如下几步完成项目关键规范的制定与完善。

首先，详细记录操做步骤，作好详细的按步骤操做的文档，利于后续全面铺开的状况下高效的培训新加入团队的人员。在此期间，收集代码修改的规范，详细指明每一类文件，每一种代码其对应的改动点，其依据是什么，应该如何修改，注释应该怎样添加，如何命名，统一使用怎样的代码格式。

这一步若是作得好，能够为开发代码转换工具提供转换模板，使得代码修改能部分自动化，下降手动修改的过程当中的错误率，提升项目开发效率，不过此类工具化转换是须要原有代码具有足够多标准可识别固定模式的源代码，好比COBOL，RPG等有着严格格式的代码，比较适用于工具快速处理。

固然，旧系统代码有着足够多的可识别关键字也是能够作到工具化处理的，这就须要工具开发工程师找到足够多的能够识别的模式，经过模板去转换，若是是工具不能修改的代码，须要手动修改的，必定要使用工具添加相关注释注明此处须要手动修改，以便于后续检查遗漏和修改的结果，并且须要给出详细的手工修改指导手册，明确各类不一样状况须要如何修改，严格执行规范化操做。并随着项目的进展状况及时对新发现的改修点作出及时更新，维护好最新的修改手册，确保没有遗漏。

其后，测试的数据规范化。采集原始数据，了解原有业务逻辑，并记录下原有系统的输入输出数据，甚至进行详细的截屏，以记录每一步操做对应的页面及数据变化，以便后续验证改造后系统在数据上是否与原有系统一致。

在测试标准化数据准备好后，就能够充分利用自动化测试工具来检查辅助程序验证改修的正确性，减小手工测试的漫长周期。尤为是在程序年代久远，文档缺失，根据程序代码分析数据处理逻辑又费时且容易出错的时候，经过对程序执行先后数据变化的记录，从而开发自动化测试脚本是保证改造先后数据正确性的有效手段，进而保证代码移植升级过程当中及时发现程序修改的漏洞。

最后，严格执行指定的规范，不容许一丝一毫的例外。在W项目里面，日方规范要求极为苛刻，文档格式，代码注释这些都巨细无遗，更为甚者，连Excel文档关闭前光标都必须第一sheet页的第一格，更不要说页面字符的位置都必需要与设计规范要求一致，不能偏离一个像素，他们都能拿尺子在屏幕上量。对方在检查此类规范时更是严格，有丝绝不同都予以指出，并要求及时改正。虽然咱们没必要要求细致到如此程度，但对于完美的追求且不可放弃。

经过以上规范的制定和严格的执行，力求将改动点标记好后，通过全部人手动修改后的代码达到与目标平台要求一致，同时保留完善的转换文档可供后续维护的员工使用。对于旧系统的改造而言，规范比新系统构建的时候更加剧要，由于没人知道你没有根据标准修改的代码会带来怎样的bug，尤为是在测试的时候，debug尤为不易，会花费数倍的时间去调查。好比在w项目里面，由于他的IDE当时debug很是不便，出了问题只能靠输出日志来查看，因为程序分支太多，为了调查一个字段的数据出错，还得写一个小工具来给代码添加几十上百条log输出，来找哪一行代码出错。如能精心维护好代码规范，确保每一个改动都能遵循，必将为项目的顺利完成打下坚实的基础。

未雨绸缪—尽早攻克技术难点，作好技术储备，防范技术风险

不管是从头构建项目仍是项目升级改造，咱们首先面临的问题就是技术选型。通往北京的路千条万条，那一种交通工具最方便，又是那一条路最适合你呢？

这样的状况下，技术选型和预研就很重要，可是每每不是在项目筹备阶段才开始作技术调研。而是在架构师平常的生活中就不断的阅读，了解不一样新技术发展方向，了解各类各样工具，各类各样的技术解决方案，不一样方案，技术间的差别，各自的优缺点；人的精力是有限的，虽不求将全部的技术都详尽掌握，但大量的阅读能够开阔眼界，当你碰到问题的时候就能够有足够多的选择，就有方向，有的放矢，而不是无头苍蝇。

因此咱们讲未雨绸缪，就是把工做作到前面，尽早解决技术难点，就能快一步推动方案验证。这须要架构师在对整个系统所创建的运行环境，有着清晰的认识，对于使用到的架构理念有着深入理解。所谓一千我的心中有一千个哈姆雷特，好比前几年流行SOA，若是对其没有足够的认识，仅仅是作了几个web service就号称本身是SOA架构就未免有些名存实亡，由于SOA是一套体系，从服务粒度的划分，到服务部署，注册，管理，部署运维都须要一系列的相关技术去支撑，并非开发了几个web service就是SOA了，所以在对概念不清晰的时候，只知其一;不知其二就急吼吼的采用，每每最后结果是画虎不成反类犬。

也正如，如今流行的微服务架构，不少人还说微服务就是API接口嘛。其实这里存在一个误区，微服务的理念在于，将一体化系统进行细粒度划分，各自完成独立的功能，自成体系，各自根据自身的业务发展自行演进，从开发，测试，部署和运维也自行负责，将本来紧耦合的变成松耦合，它的从而组成一个完整的生态系统来完成整个应用服务。而不是说个人应用全是restful 接口就是微服务了。

在行动以前理解好概念，分析清楚业务，理清业务将来发展与现状直接的差别，从而选择合适的架构，框架以及相应的技术去作pilot，技术方案在获得验证事后再从边缘功能开始作起，积累经验，攻克技术难点，而后再推而广之。任何工做不可能一蹴而就，所以系统升级改造过程当中更须要遵循这样的一个按部就班的过程，经过这个过程去排除各类技术风险，防范在这个过程当中由于技术风险带来的数据丢失等问题，对于数据一致性要求更高的系统，还要作两手准备，新老系统有时候还须要并行运做一段时间，一旦新系统有问题能很快切换到老系统上完成业务处理，以保证整个业务运行的可靠性。

在技术选型当中，忌讳的就是盲目使用未经市场普遍检验的开源软件，一味求新求快，必须结合自身实际状况，业务需求来采用相关软件，尽量采用成熟稳定，且有足够技术支持的组件来构建自身的系统。以文件存储系统为例，我关注了某分布式开源文件系统，持续跟踪和测试了进一年时间才将其集成到系统当中，做为图片的存储，并搭配Thumbor成为一个小小的图片文件存储处理系统，一年以来也一直运行良好，但后面断断续续出现丢失文件的问题，查下来大都是文件莫名丢失，因为数量不多，就让业务人员补上了，并未有足够的警戒。

后面居然出现了大规模的图片丢失问题，一查文件状态显示已删除，咱们紧急联系做者，跟他一块儿用了一周尝试解决问题，最终也未能恢复数据，最后只能将备份图片所有迁移至阿里云OSS上。这个事情就是告诫了咱们在选择相关软件系统的时候，必定要注意其成熟度，应用的广度，是否是通过了市场的检验，再根据业务的实际状况来使用。

如今云服务愈来愈多，日益丰富了架构师们的选择，在选择云服务的时候，虽然给咱们带来了各类各样的好处，但任然须要有足够的风险意识，仔细考量其成本，可靠性，以及目前自身的业务需求，是否是与当前的须要所匹配，再行决定。在自建系统与云服务之间有个成本平衡点，若是采用云服务这个成本越过了自身运行此类系统的运维成本，那么咱们选择云服务就较为理想，反之不是那么迫切，且自身资源足够的时候，有足够的能力去维护的话仍是建议谨慎使用云。仍是那句话，架构中的技术选择都是因时而动，量力而为，越早扫清方案当中的障碍，那么在下一步的过程当中就少一分风险。

做者介绍

王巍，涟拓网络架构师，先后就任于Achievo、IBM、HP，关注前沿技术，分布式系统架构，组件化系统开发，机器学习和大数据，如今创业公司负责系统架构，乐于与你们一块儿聊聊架构。