概述

要想接手一个业务系统,前提是要读懂代码,而读懂代码的关键,是要熟悉业务。
只要业务搞清楚了,代码只不过是对业务的翻译,对照着业务看代码实现,看懂并不是件难事。
读代码的过程中,要重视知识的文档化,把读懂的每个业务、每个关键处理点,都写到文档中。当然,这其中也包括前面提到的各种坑。对于复杂的业务流程,画一些流程图。这样有助于帮助新接手的同学。

总结

实际上,业务系统的开发难度一般来自两个方面:高性能要求和业务复杂。解决性能问题,你需要具备一定的架构能力,有一定的技术广度,需要对各种基础架构、框架、中间件都有所了解。光了解还不够,还要有一定的技术深度,最好能对原理甚至是源码有所研究。除此之外,还要有一定的使用经验。广度、深度、经验三者配合,这样才能做到恰到好处组合这些技术搭建架构,解决性能问题,并且在出现问题之后才能快速地解决。应对大型项目的业务复杂性,要想让项目代码一直在你的掌控范围内,你需要有很强的业务建模能力、复杂逻辑的抽象能力、代码翻译能力等。对于一个人的基本素质、基础能力的要求要更高。实际上,对于复杂业务系统来说,对业务的熟悉也能成为你的竞争壁垒,成为升职加薪的砝码。我前面也讲到,低级别的晋升靠技术,比如升阿里的 P7,高级别的晋升靠业务,比如升阿里的 P8、P9,或者换个说法,高级别的晋升,靠业务比单纯靠技术,更容易一些。如果你参与的项目,性能要求高、业务也复杂,那恭喜你,好好干就成了。如果你参与的项目,在性能和复杂度上,只兼具其中一点,那也不错,值得一做。如果你参与的项目,既没有性能压力、业务也不复杂,那也别太着急,走着瞧,实在不行再跳槽。