大体上分析源代码都要经历三遍过程:
第一遍是浏览,通过阅读源码的文档和注释,阅读接口,先弄清楚每个模块是干什么的而不关心它是怎么做的,画出架构草图;
第二遍是精读,根据架构草图把系统分为小部分,每个部分从源码实现自底向上阅读,更深入细致的理解每个模块的实现方式以及与模块外部的接口方式等,弄明白模块是怎么做的,为什么这样做,有没有更好的方式,自己会如何实现等等问题;借助断点调试深入理解
第三遍是总结回顾,完善架构图,把架构图中哪些模糊的或者空着的模块重新完善,把一些可复用的实现放入自己的代码库中。
我在漫长的读码生涯里积攒了一些的经验,算是碎碎念,供参考:
- 理清某一业务如何映射在代码执行流程上的,这点很关键。
- 理清不同模块间的业务关系,代码调用关系,很关键
- 调试是弄明白代码调用流程的最快方式,之一
- 找出关键代码(代表实际对象的类、衔接不同模块的类、代表业务关键节点的类)
- 分析日志可以帮助分析代码执行流程和业务流程
- 先用已有的可运行软件,体验业务,琢磨你点这里一下点那里一下代码可能是怎么做出反应的
- 阅读应该围绕目的,把实现目标放在第一位,比如修改Bug,如果有期限,在最后日期前搞定是第一要务,然后有时间就继续读源码或改进Bug修复方案,力求没有副作用和后遗症,再有时间就修修别人留下的破窗户(你也可以顺带鄙视下前任维护者)
- 千万次的问,还记得前面说要弄明白谁维护过你要读的代码吧,别不好意思,问吧,问吧,问吧
- 对着设计文档、接口文档或测试用例看代码
- 心理调试,勿畏难,别放弃。我有时看代码,看两天也不知道看了个甚,一头雾水两眼发花是常有的事儿,有时真是觉得搞不定了,然而,这要么是你基础知识没准备好,要么是你找错了入口,要知道,任何一份代码,都有一条隐形的线串着,耐心点,总会找到。这样不行就那样,多换换角度,多换换方法,读不行,就调试,调试不行,就运行,运行不行,就研究日志,都不行,我靠,while(!i.isDead())i.analyzeCode(),跟Y死磕!总之,你不放弃自己,就没人能放弃你!
- 给自己设置小奖励,弄明白某个逻辑或某个模块的代码后奖励自己休息一下,5~10分钟,走出办公室转转,或者干脆在网上瞎逛一下,浏览自己喜欢的网站
- 读不懂才要读,想不明白才要想,这是进步和成长的开始。那些阻挡你的蹂躏你的而杀又不死你的,终将帮助你成长让你变得更强大。
————————————————
版权声明:本文为CSDN博主「foruok」的原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接及本声明。
原文链接:https://blog.csdn.net/foruok/article/details/51235517