分析代码中的业务逻辑是程序员的必经之路

“分析代码中的业务逻辑”，是逆向工程的一个子集，在大型系统开发/维护过程中，已经成为一个程序员的必经之路。

在软件开发领域，所谓的“逆向工程”是指从可运行的程序系统出发，运用解密、反汇编、系统分析、程序理解等多种计算机技
术，对软件的结构、流程、算法、代码等进行逆向拆解和分析，推导出软件产品的源代码、设计原理、结构、算法、处理过程、运行方法及相关文档等。 

众所周知，我们使用了几十年的软件系统的开发方法，都是在围绕：可行性研究与计划，需求分析，概要设计，详细设计，实现，集成测试，确认测试，使用和维护这几个阶段在进行，这其中就包含了“需求分析”和“该要设计”。对于程序员来说，“需求分析”和“概要设计”是指导后面的“详细设计”，“实现”的依据。它们虽然作为软件系统商业机密的组成部分，不允许被外传，但是在公司团队内部，它们对相关项目的程序员来说是开放的。既然，程序员是“实现”阶段的执行者，手里有源代码，又能够看到“需求分析”和“概要设计”，那何来逆向工程呢？

实际的情况是，开发中的好多阶段，例如：可行性研究与计划，需求分析，概要设计，详细设计都被弱化了，特别是对于那种已经完成了首个版本开发且已经上线的系统，通过迭代来引入新功能时，开发几乎就直接进入“实现”阶段了。

加之开发和维护过程中的人员流动因素，可想而知，经过多个这样的迭代，就会出现“需求分析”和“概要设计”的真空，开发人员要弄清楚前几个迭代的业务逻辑，就只能从分析代码入手，从分析整个系统的运行行为入手，来还原之前的“需求分析”和“概要设计”，进而确保新功能的实现能够很好的衔接现有功能。

因此，作为一个程序员，直接分析原有代码，导出其中的业务逻辑，是工作中一条绕不开的路。既然绕不开，就直视它，根据项目特点，找到分析代码，导出业务逻辑的特定方法。作为一个程序员，会成长成什么样子，由很多因素决定。但对于我来说，我希望能够在程序员的这条路上走得再远一些。

参考：

软件逆向工程