如何优雅的接收正在运行古董代码？

古董代码，意味着有较长的运行时间，系统初始设计需要支持的业务与现在的业务可能已经大不一样，加上需要快速支持业务发展，导致设计将就、数据结构混乱、代码混乱，还可能无文档、无流程图。如何才能优雅的接收？

思考的方向

1. 如何保证项目的正常运行？

2. 团队成员如何快速上手？

3. 如何接手后不会更乱？

4. 如何从老项目中吸取养分？



如何保证项目的正常运行？

1. 接管生成环境。保证在生产环境不变的情况下，能稳定运行。

2. 摸透发布流程。每个老系统都可能有一些特殊的生成发布流程，只有快速掌握了，才能在意外发生时，重新部署，并支持业务运转。

3. 接管进行中需求。进行中需求是必然造成生成环境变化的，需要评估需求对项目的冲击，尽量减少大范围改造。同时与需求方沟通，打好预防，这波需求有可能无法上线。毕竟第一波需求上线后有问题，可能无法快速解决，需要直接回滚。

4. 接管git、测试环境。在本地和测试环境反复验证突发情况的处理方案。

团队如何快速上手？

1. 抓住业务主线。无论系统迭代了多久、分支流程有多少、无效代码有多少，一个系统必然是来支持一个或者几个业务的开展。业务的主线往往是程序的主线。与产品、业务沟通，快速理解业务知识，忽略业务细节，直取主线。细节太多，会让人迷失，并产生不可全部掌握的感觉，团队信心会收到打击。

2. 掌握主节点入口。在主线的指引下，到测试环境反复模拟业务场景，抓到每个节点输出的日志、记录程序的入口。有了日志的记录与程序的入口，生产环境一旦出现异常情况，可以快速定位问题所在节点，并有针对性的阅读代码，分析问题具体原因。

3. 掌握主要数据结构。主线抓住后，就是主要数据了。再复杂的系统，再多的表，实际利用率也会符合“二八原则”。根据主线的理解，分析并掌握主要的数据结构，以保证后续的需求迭代、问题定位更加高效。

如何接手后不会更乱？

1. 分析系统初始设计思路。能负责一个系统的初版设计的，大多是有一定技术能力的，能掌握其初始设计思路，能对系统有更深刻的认识。不要认为系统技术过时、程序混乱、数据结构混乱就认为这个系统就是一个垃圾堆。技术过时，不可避免会遇到，初始设计可能是当时的最好技术方案了，只是随着技术发展，它落后了，但是不能做技术的迁移；各种混乱，初始设计时可能业务还不成熟，考虑的方向和适应性有限，特别遇到业务大量变革时，很多老系统不可避免会出现混乱的情况，加上资源紧迫无法及时调整，导致了各种混乱现象。理解其初始设计思路，尝试理解各种变化对系统的冲击，可以更高效的掌握系统的整体情况。

2. 资源不足时，不要大范围重构。重构也许是好心，如果只做一半，会成为下一个接手同事的噩梦。如果系统只有一套思维、一套技术方案，或许陈旧，也还好理解，也还好找到路径去分析项目。一但重构又只做一部分，会导致一个系统有多套思路、多套技术方案，会加大程序的混乱程度。也许重构中的人相信自己在让系统变清晰，但是未完成前它就是混乱的，要么不要开始，要么一路到底。不要看到一个坑，然后使劲踩上两脚，让坑更深了。

3. 数据结构、代码分析未掌握80%时，不接改造面太大的需求。数据结构不清晰时，做大需求有要程序稳定，很多东西就会新写一套，以免和以前的产生冲突，但毫无疑问，这回让程序再出现分支、重复数据结构等。

如何从老项目中吸取养分？

1. 业务知识学习。先说做技术为什么要学业务，做一个项目的架构，业务和技术都要了解，你对业务理解越透彻，你就看的越远，你设计的系统就越能适应，因为很多的变化其实在你这里不是变化，只是早已知的一个分支，所以不要忽略业务知识的学习。而老项目往往承载了整个公司各种业务变革，其中充满了各种业务知识，不少也许产品、业务都已经完全遗忘了。掌握了业务知识，了解了业务的发展，后续系统的重构也必然成竹在胸。

2. 项目管理与技术管理的反思。它怎么乱的？怎么才能不乱？怎么才能让大家感觉不是站在垃圾堆里造垃圾？这也是我们技术人员可以去分析并借鉴的方向。这是必然是一个非常好的反面教材。正反都学，才能知道什么要坚持，什么可放手，才能不偏不倚做好长期的管理工作。

总结

要用发展和辩证的眼光去看待这类系统。