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