不会读代码的程序员，不是好厨师

时间：2021-07-05 21:52:46

关键字：代码程序员源码

手机看文章

扫描二维码
随时随地手机看文章

[导读]会读代码，和会写一样重要

[导读] 大家好，我是逸珺。
某日一好友，调侃我的笔名，说读起来好像“抑菌”！嗨，还真是，不管了，“抑菌”就“抑菌”吧。
写号以来，有小伙伴问：如何能快速提升编程能力？这感觉永远没有正确答案，每个人都有自己的套路，今天就来聊聊我对这个问题的看法：
学会高效读代码，就是一个不错的办法。阅读代码，可能和写代码一样重要！

为什么要会读代码？

考虑这样一些场景：

Case 1: 你还在读书，照着教程，照着例子，学习编程。刚开始，大概率是先读别人的代码，理解别人的代码，而非一上来，就开始写。

这是我YY的一个学写代码的学习模型，所以读了，理解了，在自己就可以发挥了，然后书本上、他人的知识，就流进了自己的脑瓜了。

Case 2: 一个职场新人，一进公司，就加入一个项目组，那项目代码真是海了去了！然后老大可能给你一个小小的活，在现有基础上，添加一个小功能。项目经验少的童鞋，一下就傻眼了，特么的，这代码这么多行，文件几百上千！该从何入手呢？别说改了，看都看不懂！完了，试用期是不是就要被干掉？！
Case 3: 你进了一个小公司，技术管理混乱，前任已闪人，你受命接任一个一坨翔一样的项目，那代码写的真是云里雾里，工期又紧，老板又逼着出货，怎么办？闪人？可是下家会更好么？跳槽往往是从一个坑里，跳到另一个坑里。所以读吧，总是要读的。。。
Case n: ......

学校往往教授的是如何写代码，可能从没有教如何读代码。
然而，理想很丰满，现实很骨感！工作中，你写代码的时间可能只占工作时间很少很少的一部分，大部分时间你可能都是在阅读已有的代码，当然除非这个项目从0到1都是你一个人干，可即便是自己写代码，也是渐进增长、不断迭代的，也需要不断反复阅读自己写的代码。
再者，编程与写文章，有异曲同工之处。编程与写作相似之处，都是用语言表达写作者的想法。
对于如何提升写作，古人曾讲：熟读唐诗三百首，不会作诗也会吟。回想学生时代，老师也常说：读书破万卷，下笔如有神！强调写作需要大量阅读，读的多了，写作能力也会相应提升。阅读之于写作，相辅相成，互为促进。
那么大量阅读别人的代码，也能提升自己的编程水平。阅读代码，个人觉得会有这样些好处：

博采众长

优秀的源码，就如传世佳作一样，值得反复揣摩，细细品味。其编写技巧、设计范式、架构思想，都具有极大的学习借鉴价值。比如一些优秀的开源项目：Linux内核、lwIP、u-boot等等。这些作品都汇集了全球优秀顶级程序员的思想智慧。都是非常优秀的作品，广为流传，广为应用。如果能花些时间去阅读理解一下其代码，一定是大有裨益的。
正如牛顿所说：如果我能比别人看的更远，只因为我站在巨人的肩上。

解决难题

编程生涯中，总会遇到一些感动束手无策的场景。github，搜索都已无能为力的时候。如果说还没遇到，那一定是机缘未到～

比如做Linux编程的时候，遇到某个API出错，或许在网上查找半天，都找不到答案。实在找不到答案了，尝试读一读内核底层相关代码，有时候就能发现问题的原因。

开阔视野

很多时候，日常工作内容或许只是很小的领域，修复一些小的bug，修改一些小的功能等。如果只专注这些小的点，个人成长一定会受到局限。
如果能善于发现一些新的感兴趣的领域，并去阅读相关的代码，则一定会提升自己的编程能力的。

所以为什么要读代码呢？

找bug

review别人的代码

学习

维护等

如何阅读代码呢？

这里聊聊我的一些体会，也未必都对，也未必适合其他的朋友。分享以作交流，如有其他想法，也欢迎大家留言交流。

先粗后细

我一般拿到一份别人的代码，会先去找这个项目的入口，先梳理个大概的脉络。如单片机程序，一般会从下面几个角度先扫一遍：

main在哪里？
开了几个任务？
哪些是关键任务，主要功能链是怎么样的？
任务间如何协作的？任务的执行周期是如何安排的？
使用哪些硬件外设？
使用了哪些中断？中断与哪些任务发生了交互？
从软件角度看，大致有哪些子系统？
是否有关键算法？
是否使用开源组件？
......

先不关心很细的函数具体怎么写，数据结构是如何设计的？这样，我大致能先有一个总体认识，然后在对自己感兴趣的进行细读。当然如果是review别人的代码则就另当别论了。
如果是Linux应用程序，或者C 应用程序，我也大致采用差不多的思路，先读个大概，然后再细读。比如对一个Linux应用程序，会先了解这些方面的概要信息：

入口在哪个文件？一般都是main函数。
是否支持命令行传启动参数？
是否是守护进程？
开了哪些线程？
大致有哪些子系统？
使用了哪些开源组件？
是否使用驱动，是否有通讯等？
......

如果项目采用cmake或者makefile进行组织的，那么先阅读下makefile也会是了解项目概要信息的一个比较好的切入点。

善做笔记

在阅读代码的概要信息的时候，我比较喜欢做做笔记，画画图。在阅读代码的时候，我比较喜欢先去研究代码中的数据结构。数据结构往往会体现作者抽象问题、对问题建模的一些思路，并使用UML图画出来，刚开始可能都不去看每个函数是怎么实现的，只关心与这些数据结构相关有哪些函数以及数据结构间关系。

“Bad programmers worry about the code. Good programmers worry about data structures and their relationships.”
— Linus Torvalds

或许，有的朋友会说，UML不会。不会没关系，用你习惯自己能看懂的方式都可以，而且即便是用UML也不必过分纠结绘制的图是否严谨。甚至拿支笔在笔记上手绘也可以。不过个人更建议，尽量写电子笔记，更容易保存和查阅。
阅读某一个具体函数时，如果函数内或者模块内具有状态机，如果这部分是需要仔细理解的时候，我就会将其状态机图，先绘制出来。比如，之前写的modbus协议中的状态图：

这样做有个好处，边绘图边去理解代码，就会加速对代码的理解，对我来说，我如果只用两只眼睛盯着看，和一边看一比画图效率会低很多。
这样做还有一个好处，可以将理解以图的形式记录下来，如果光用图还不能表达清楚的时候，我还会再加点文字描述。时间过了很久之后，再来看代码，可能之前的理解全忘了，可是如果有这样一份图文并茂的笔记，我就会很快找回记忆。

善用工具

比如source insght, vs code等工具，都是提高阅读代码效率的好工具。尽量熟悉如何使用键盘控制阅读跳转，用熟了，效率倍增。
另外，还有些工具，可以自动将代码转化成类图等，比如visual studio，可以自动绘制类图，Enterprise Architect也具有根据代码生成类图的功能。具有此类功能的软件还有很多。有兴趣可以搜索一下。

多多调试

如果遇到有的代码，怎么看也理解不了。这时候可以试着加些打印日志，运行调试一下，也可以使用调试工具进行断点、单步调试，观察程序运行的轨迹，数据的变化情况，可能就找到了突破口。
或者尝试对原有的代码，做些小的修改，来印证理解，也是不错的方法。
一个经常调试的程序猿，键盘上F10,F11这些键大都坏的比较快。