今天刷到一个视频号报道，说一位女军官打印源码研究，借此提高代码水平，提升我军核心能力。

视频里，厚厚一摞打印纸堆在桌上，密密麻麻的代码从纸边溢出来。女军官伏案研读，神情专注，旁边的解说词铿锵有力——"钻研核心代码""提升战斗力""科技强军"。

评论区画风挺统一的，外行看热闹：太刻苦了，致敬。程序员看门道：等等，打印源码？这靠谱吗？

作为一个写了快二十多年代码的人，我看到这个视频的第一反应是：这份精神值得敬佩，但这个方法，值得商榷。

❶说起来，打印代码这事还真有传统

先别急着否定。

上世纪七八十年代，打印源码是程序员的常规操作。那时候显示器小、分辨率低，一行放不下几个字符，想要通读一段逻辑，打印出来铺在桌上看，反而更清楚。

Linux之父Linus Torvalds早年也说过，他习惯把内核代码打印出来读。比尔·盖茨当年亲自审阅Windows NT的关键代码，据说也是打印出来用红笔批注。甚至有一张老照片——Ken Thompson和Dennis Ritchie在贝尔实验室，面前就摊着一堆打印出来的Unix源码。

那个年代，打印代码不是因为酷，是因为没有更好的办法。那时候没有4K显示器，没有语法高亮，没有代码折叠，没有IDE自动跳转。你想看一个函数调用了哪些其他函数，只能翻页或者翻纸。

所以"打印源码研究"这件事，在历史上是真实存在过的，而且确实有它的价值。

但请注意，那是三四十年前的事了。

❷问题一：现代代码的规模，打印根本扛不住

1980年代，一个Unix内核的源码大概几万行，打印出来几百页，铺一桌子还放得下。

今天呢？

Linux内核超过3000万行代码。一个Android系统的源码，全部下载下来要占100多个G。一个普通的电商系统，后端代码动辄几十万行。

你打印3000万行代码试试？按每页50行算，60万页纸。一本《辞海》大约8000页，这相当于75本《辞海》摞在一起。

就算你不是看整个系统，只看一个模块——一个中等规模的模块，十几万行，打印出来3000页。你翻开第1页看到的一个函数，调用了第1500页的另一个函数，那个函数又引用了第2800页的一个类。你怎么翻？

这不是"刻苦"能解决的问题，是方法本身和时代脱节了。

❸问题二：读代码和读文章是两码事

不少人以为，读代码就像读文章，从头到尾顺着看就行。写过代码的人都知道，根本不是那回事。

代码不是线性的。

一个函数A调用了函数B，B里面又调用了C，C里面有个回调指向D，D的某个分支条件又依赖A传入的参数。你在屏幕上，按住Ctrl点一下函数名，一秒跳到定义；按一下返回键，一秒跳回来。来回切换，一秒钟的事。

换成纸呢？你看到函数A调用了函数B，翻到第47页找到B；B调用了C，再翻到第132页找C；C里有个回调指向D，再翻到第289页。等你搞清楚D的逻辑，想回到A继续往下看——A在第几页来着？

这就是代码和文章最大的区别：文章是线性的，代码是网状的。读代码需要的是"跳来跳去"，不是"从头到尾"。

纸质打印最擅长的恰恰是线性阅读，最不擅长的恰恰是网状导航。用最不擅长的方式去对付最需要跳转的东西，事倍功半。

❹问题三：代码是活的，纸是死的

真正理解一段代码，光"读"是不够的。你得"跑"。

在IDE里，你可以设断点，一步步执行，看每个变量的值怎么变化。你可以改一行代码，重新运行，看看输出有什么不同。你可以在函数入口打一个log，看它在什么条件下被调用，调用了几次。你甚至可以故意把某个参数改成异常值，看错误处理逻辑是否按预期工作。

这些在纸上都做不了。

纸上的代码是"死"的。你只能看到它"写了什么"，看不到它"运行时发生了什么"。而理解代码的关键，恰恰在于理解它在运行时的行为——数据怎么流转，状态怎么变化，异常怎么处理。

Linus Torvalds后来也改口了，他说现在更推荐在电脑上读代码，因为可以搜索、可以跳转、可以追踪调用链。打印代码这件事，他自己早就不干了。

❺问题四：搜索是第一生产力

程序员日常最高频的操作不是写代码，是搜索。

搜一个函数名，搜一个报错信息，搜一个变量的所有引用。在IDE里，Ctrl+Shift+F全局搜索，0.1秒出结果。找谁调用了这个函数？右键→查找用法。这个字符串在哪些文件里出现过？一搜全出来了。

打印出来的代码你怎么搜？用眼睛一行一行扫？3000页纸你扫一遍试试？

我见过一个真实案例：一个团队的老大坚持让新人打印代码来读，说是"培养基本功"。结果新人花了一周时间"读"完了，问他某个功能在哪个模块实现的，他翻了半天纸也找不到。

不是他不努力，是工具不对。

❻那什么方法才靠谱？

如果目标是"提高代码水平"，真正有效的方法是什么？结合我自己的经验和大厂通行的做法：

第一，带着问题读代码。不要漫无目的地"通读"，而是带着具体问题：这个功能是怎么实现的？这个bug的根因在哪？这个接口的调用链是什么？有问题驱动，你的注意力才有锚点，不会读完就忘。

第二，用工具读，不要用纸。IDE的代码导航、调用链分析、全局搜索，是为读代码而生的。Source Insight、Understand、JetBrains系列，甚至VS Code配合插件，都比纸强一万倍。

第三，边读边动手。读完一个模块，自己画一张架构图。看完一个函数，自己写注释总结。看完一个设计模式，自己在本地写个demo跑一下。动手才是最好的理解方式。

第四，读优秀开源项目的源码。Linux内核、Redis、Nginx、Spring——这些项目的代码是经过千锤百炼的，读它们能学到真正的工程经验。但同样，在GitHub上读，用IDE打开，别打印。

❼方向比努力更重要，但这事也不是全无价值

公平地说，打印源码也不是完全没有可取之处。如果你研究的是一小段核心算法——比如加密算法、排序算法、压缩算法——代码量不大，逻辑密集，打印出来反复推敲，确实有帮助。这种场景下，纸上阅读的"慢"反而成了优点，逼你一个字一个字地看，不放过任何细节。另外，军事场景有特殊性。涉密系统不能随便联网，不能随意用个人电脑打开，打印出来在保密环境中研读，可能是安全合规下的无奈之举。从这个角度理解，打印代码不是为了"更高效"，而是为了"更安全"。但报道把这描述成一种提升代码水平的"先进方法"，就有点误导公众了。

话说回来，一个程序员水平的高低，不取决于他读了多少行别人的代码——不管是在屏幕上读还是纸上读。代码水平的提升，靠的是"写"，不是"读"。你读了一万行Linus的代码，不等于你能写出Linus水平的代码。就像你读了一千篇莫言的小说，不等于你能写出《红高粱》。

读代码是辅助，写代码才是主业。在真实项目中踩坑、调试、重构、优化，在每一次"为什么这段代码跑不通"的痛苦中成长——这才是程序员提升水平的正道。打印源码研究，精神可嘉，方向跑偏。就像一个人为了锻炼身体，每天扛着石头上山。精神可嘉，但你为什么不去健身房呢？有更好的工具和条件不用，非要用最笨的方式感动自己，这叫"用战术上的勤奋掩盖战略上的懒惰"。

致敬每一位刻苦钻研的人。但如果方向不对，越刻苦，离目标越远。代码在屏幕上是活的。把它打印到纸上，就只剩一具尸体了。

龙门小站

📖 往期推荐

📝是不是真的？传言詹姆斯准备每天花上万美金坐直升机上班
📝信托到底是什么？800年前一个骑士的死局，逼出了人类最硬核的金融制度