现在的系统都很庞大、修改一处代码总要瞻前顾后的考虑一下对整个系统的影响
而对于庞大的系统而言，自己修改过、完全理解的部分如沧海一粟
大家在工作中如何快速的理解别人做的代码、修改代码时如何考虑对整个系统的影响
一起交流一下吧
先抛砖引玉一下：
最原始的方法莫过于grep，但grep也有很多弊端，比如检索用的关键字得凭借经验来决定，有时不够客观；工作量非常大，一层一层网上找，有时根本没个头儿；找呀找呀又找回来了，像在迷宫中散步似的
比较简洁的办法是在现有的系统中进行一下测试，如果有比较完善的log的话，通过一些工具（有可能得自制），生成出sequence图，可以比较直观的看到系统之间各个模块的调用关系；通过对比正常情况下和特殊情况下的log还能迅速找到产生差别的分歧点；这种方法的困难点在于：事前需要项目组统一好log的输出方式，否则铺天盖地的log也让人无从下手
还有一个问题就是：毕竟测试仅能部分展现代码的运行过程，具体的逻辑还得仔细研究代码才行
当某天，领导给你一份几十万行甚至上百万行的代码时，如何厘清这里面的脉络，是一个程序员必须面对的问题
除了灌水的，尽可能给每位发言的人都分配一些回帖奖励分数
大约在这个月底左右结贴，希望大家踊跃发言，不吝赐教
------解决方案--------------------
可以考虑先只针对一个功能看，并且用笔和纸，将这个功能自己总结着写下来。
一个功能点能解决了，再看其它功能点就容易些了。
思路是 由点及面，方法是书面总结。个人觉得笔头写下来的过程中，会注意力更加集中。
------解决方案--------------------
赞同，我也是用这种方法来让自己集中注意力思考的，反正对于我来很管用~
------解决方案--------------------
1、分析包以及包含哪些类，对整个项目有个概况了解，分析项目采用的框架结构；
2、看具体类以及类的公开接口（共有方法签名、属性），再看类之间的关系，从面向对象角度分析设计思路；
3、再看类的内部实现，这部分通常根据需要，需要看什么地方就看什么地方。
------解决方案--------------------
找个功能，跟着走下去，看看处理流程，所涉及的代码！这样就好理解了！
------解决方案--------------------
这和代码质量太大关系了。。如果那份代码有详细文档，清楚地说明了使用的框架结构，以及遵守了哪些设计模式，遵循了哪些接口约定，那你一个模块一个模块的去看很快就能搞清了。
怕就怕那些杂乱无章毫无章法的印象派代码风格，跟踪调试一个模块，这里一个调用，那里一个调用的，跟踪三四层绝对晕了。。
------解决方案--------------------
根据文档和注释，写个大知道的模块调用流程
------解决方案--------------------
首先对整个项目要有初步了解，弄清楚整体框架结构，功能块的组织，然后以功能区为单位，找到问题点，由点及面这样抽丝剥茧。大体上应该是由全局到局部，再由局部到全局。
六楼说的很有道理，原始代码的质量的质量太重要了，如果给你的是一份改了很多次，经了很多手的代码，如果在没有文档注释，那可真是头疼。
------解决方案--------------------
从主页开始看，一点一点就能懂
------解决方案--------------------
感觉要先看文档 大致了解整个软件的功能有哪些 针对这些个功能点找到对应的代码 然后各个击破
------解决方案--------------------
都成推荐了。。再补充一句，其实丰富自己的经验，充实自己的知识库也是很重要的
比如要你研究Linux内核源码，不说最新内核版本，就说各种分析各种深入浅出烂大街的2.6版本，代码应该说相当规范了，文档也几乎不能再详细了，但要你研究出个什么结果还是不太可能的，能看得懂结构逻辑与算法就已经算牛逼的了，更多的人可能没几个模块看得懂的，因为这涉及到很多操作系统的知识，没看过理论分析的几乎是不可能直接看得懂代码的(当然天才级大师除外)，同时就算你懂一些操作系统理论，不了解很多著名算法还是看不懂，线程调度文件系统安全加密等都涉及到大量基础算法，以及他们的衍生“杂交”品种，没得功底修炼不了传世之作，不然只会走火入魔。
------解决方案--------------------
1.业务知识
2.指导文档
3.ER图
4.略懂一些该语言的代码。
------解决方案--------------------
先看业务框架,再看技术框架,最后再看源代码.
------解决方案--------------------
先理解业务，业务最重要。再根据业务去熟悉代码
------解决方案--------------------
其实我觉得如果有同事最好就最好和同事先交流一下， 然后把我一下整体， 再从自己那部分梳理
------解决方案--------------------
一个系统项目再大， 框架是死的，所以我一般先了解这个项目用的框架，之后通过一个功能的代码来熟悉这个框架的使用方法，基本上其他的功能都是一样的了。。
------解决方案--------------------
1. 先了解你要读的代码是用来做什么的，这样就会对代码产生一个比较直观的认识。比如，快速的做一遍功能测试，如果有功能测试文档，那就按照文档走一遍。
2. 比较大的工程，代码的风格，和各个功能的实现都是十分类似的，如果不是这样，也就预示者这个项目的架构设计比较失败，难于维护。带着问题去阅读代码中的某个模块。比如，解决某个bug，通过解决这个bug，并对bug所在的这个模块深入理解。这样，结合1，你就能猜到整个系统的实现大概是个什么样子。
------解决方案--------------------
光看代码太累了
所以这时候才体现了文档的价值
快速理解现有代码
我建议是先弄清楚这上百万行代码构成了一个什么系统
然后根据功能模块去细看代码
这样理解起来会更快
因为你知道这部分代码是干什么的
后面只需要关注是怎么实现
------解决方案--------------------
这话说的在理！
------解决方案--------------------
如果有需求文档就最好了，毕竟所有的代码都是为了实现需求的……通过需求文档和项目文档找到对应的文件包、程序集，模块的位置就自然浮现了吧，其实我是菜鸟
------解决方案--------------------
这个问题的确头疼，因为接触新系统，完全不了解流程，一般的做法是先看两三天代码（老板应该不至于让你当天就开始改），注重某一项业务慢慢去改，边改边测试当前模块。
不知道说的对不对。。。
之前看过一个文章说的就是僵尸代码，大系统遗留的代码，不敢删除，也不敢修改，等更多好的建议
------解决方案--------------------
进去跟一下代码就明白了
------解决方案--------------------
先搞懂框架怎么用的 根据界面 一点点的跟代码吧
------解决方案--------------------
一个良好的程序员，耦合性是很低的。从单独的模块入口看起，一般都是能理清楚的，主要这都是业务逻辑比较simple，看框架可能就要结合这接口的声明来看了
------解决方案--------------------
从头开始看，一步步来最快了~~~
------解决方案--------------------
这个我赞同， 其实我觉得都没必要看代码，因为代码肯定看的懂，但业务确非如此。
对于“修改一处代码总要瞻前顾后的考虑一下对整个系统的影响”，我的理解是，还有比这更烂的系统么！
------解决方案--------------------
好的文档加注释会有很大的帮助
------解决方案--------------------
一路看下来，个人觉得系统的结构更为重要，一个那么多代码的系统很难全部理解，也不是每个模块都能看懂的，根据需要，去处理需要部分的代码，这是比较理想的
------解决方案--------------------
有文档没，代码注释多不。有的会容易很多。大的还是先看一个小模块把。
------解决方案--------------------
按功能来划分代码成模块，这是快速，大致上理解代码。
然后逐步分解....
当然，分解到何时何处是最基本，这要看系统的复杂程序和你的“循环层”and你想要的结果决定的
------解决方案--------------------
有Demo最好，优先走一遍Demo
大牛们给出的意见普遍是，任何源码都从文档和框架走起。
Debug是一种手段，善用Debug，例如把项目的日志输出开到最大，安装虚机进行调试等等。
随时调，随时做笔记！自己理框架，有了轮廓其他的都轻车熟路了。
------解决方案--------------------