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

老话说的好，不以规矩，无以成方圆。在项目开发过程当中需要规范，在系统升级改造的过程中，规范的制定更加重要，因为他不仅仅关乎最终的代码质量，更事关项目的成败。在项目初期试验 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，关注前沿技术，分布式系统架构，组件化系统开发，机器学习和大数据，现在创业公司负责系统架构，乐于与大家一起聊聊架构。

本文是老系统升级改造的第三篇文章，点击链接，阅读前两篇文章：

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

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