接手别人的源码时

Question

工作上常常需要团队合作、也会接下不想接的源码，一个洞二个洞，补来补去，网上常说设计，程序员最怕改架构，一直改架构不如杀了它比较快，客户再催、老板再催、pm庄时间、sa改规格身为 豆芽程序员的我们，到底开怎办才可以，快速了解整个结构，了解这个领域…
没有文檔参考，就算有也是很旧了，没有人可以问，就算有他也忘了，我们只能慢慢的看，不然就是debug 一步一步跑，但是时间总是只有24小时，大家都是公平的，有没有前辈可以分享经验让菜鸟们学习，增加了解整个系统的速度及效率呢?目前还是菜鸟的我，我的经验是~ 先了解大概了解，业务流程，第二表的结构、最后看源码，找不到问题就是一步一步的看, 希望可以缩短时间，请大家给点高见~

Answer 1

没有文檔参考，就算有也是很旧了，没有人可以问，就算有他也忘了，我们只能慢慢的看，不然就是debug 一步一步跑很明显，公司的文化问题。文档可能因为以前不规范没有，但如果原开发人员在，想不起来就是借口。比较简单的方法，软件，每个菜单点一次，记住是做什么用途的，包括细节操作。用户总要看说明书的，看看说明书。了解软件是干什么的了。再来看实现。这个就看代码质量和你对开发工具的熟练程度了。

Answer 2

因为工作需要，这种看别人源码的事干过N次，最怕的是用全局变量，在哪里赋值的很难找。这种情况下，只好不断地全局搜索，一个个地找。
如果是win form，先从构建函数和form_load事件入手，搞清楚初始化的过程，然后看各个控件的事件处理代码，主要是要理清事件间的联系，另外比较重要的通常是“保存”按钮的事件，把这个事件的业务流程看懂了，整个业务流程差不多懂了一半。
边看边作笔记，尽量把流程理清楚，看不清楚的时候运行一下程序，设断点跟踪一下。如果是web form,也是先从Page_Load入手，再看控件的事件处理代码基本上也差不多。如果是命令行程序，相对简单些，从Main方法入手，一个方法一个方法地走一遍。感觉接收别人源码的时候，基本的原则是“能不改就不改”，因为一开始对流程不熟悉，很容易改错。有些代码，表面看上去很愚蠢，但也有可能有特殊的目的，如果不熟悉，贸然修改，很容易弄巧成拙。“优化”别人的程序需要非常非常小心，不是万不得已，决不可贸然为之。其实，接收别人的代码虽然痛苦，但也有乐趣。一是可以提高代码的阅读能力，二是一般来说，别人的思路和自己不一样，多多少少总有些可以学习的东西。

Answer 3

业务流程很重要，这样才有可能知道原来程序员的思路、编写习惯真的不小心遇到代码不清晰，转了几个弯才实现的功能，改了或干掉至于上头叫得紧，让他叫去，自己努力就好，最多搞个通宵，反正程序员通宵也不是新鲜事，再不行上头也会理解！程序员就要学会看别人的代码，了解了业务流程就分解功能，把一些明显不相关的代码 return 掉或者 给个什么固定值，定位一下方法有几个地方引用，如果少就容易改，如果引用多得小心点了

Answer 4

只看要改的部分,出毛病了就说原程序的bug

Answer 5

原来大家都差不多^^，我看高手都很利害~ 通常他们都会 把代码 重构一次，有人有弄过吗?
我有看了几页书，他也是 慢慢的跟踪，然后 一步一步的 改，很利害，再加上 ide的帮忙可以改很快，不知道有法有人有经验呢?  指点一下

Answer 6

对了，慢慢追踪是最终的办法没错，但是最近我感觉到错折了，因为最近跳去干as400的东西，写cobol，都是在终端上写，源码都很长，刚学不久 不熟真的很累，呵想想之前干 c# 时那时也是不熟，但是可以问问大家，真的好辛福，现在觉得真的是面对一部死机器哈，有没有人干cobol 的来交流一下呵

Answer 7

恭喜你!
人世间最痛苦的事情莫过于此.
代码量小还没什么.代码量大又什么都没有.加上windows自动生成的一些代码来干扰你的思路.
头都大了.
至少我这么认为的.