近日，外媒上的一篇文章震惊了我，它赤裸裸地写道：你们这些程序员们，真得每天都在读代码吗？多数人阅读代码的数量远远不够。

文中提到，在Peter Seibel撰写的“Coders at Work”一书中描述了这样一个矛盾的现象：“几乎所有的程序员都建议他人通过多读代码获得乐趣，但自己却往往做不到。”甚至他还直接向麻省理工学院计算机科学系教授 Hal Abelson寻求答案：

“我想更深入了解一下。像很多人一样，您也常常建议程序员应该多读代码。然而，当我问到您是因为读了哪部分代码而受到启发或感到娱乐时，您同其他人一样，回答说‘是因为您阅读了学生的代码’，而这是您的工作，‘在谷歌review代码’，而这同样是您的工作。从头到尾，这都听起来不像是您在某个夜晚心情愉悦地读一段代码的样子。”

为了搞清楚这种现象产生的原因，Seibel几人展开一番讨论，并给出了精彩见解，不过，或是由于过于聚焦“读”这个词，使得他们的思考局限于某一个框架，考虑的问题跟着带跑偏了。

实际上，我们都读过代码，但基本是需要编辑的时候才会选择读代码，而只有当遇到复杂问题时，读代码这件事才变得异常重要。毕竟，有程序员就曾抱怨：“一坨几千行的代码，整个业务逻辑都放在里面，注释也不写全，谁能看懂？”

而为了养成这种读代码的好习惯，作者Kartik Agaram从另外一个角度给出了自己的见解——破解程序法读代码。

这种破解程序法比“被动地”、“线性”阅读能产生更好的理解，且基本满足以下三个特点：

1. 主动探索：当你想要破解一款程序时，你最终希望要对代码库进行修改，恰恰是这个欲望引导着你一步一步读着代码；

2. 大幅修改：同样，此时你会根据想要进行的修改对现有代码进行评估。决定用什么和删除什么迫使你对现有系统保持一副排斥的态度。而如果你以线性的思维读代码，你会发现：你基本无法批判性地检查代码；

3. 组合：为了改变你想要的程序，你可以将新代码与现有代码进行组合。

通过破解程序的方式学习代码，还可以调用某一个代码库的自然结构。一本好书就是通过一系列问题和答案来引导读者的，而代码库本质上是非线性的，像地图一样，你可以不停地向地图寻找答案，但你不能指望地图告诉你要问什么问题，因为从左到右、从上到下地线性读取地图是没有意义的。

此外，过度沉迷于干净代码和整洁界面的讨论，使得我们忽略了一件事：对不熟悉的代码愈加避而远之。对于程序员而言，整洁，意味着有据可循，但如果我们想要另辟蹊径时，反倒是累赘。

所以，或许只有当你再也听不到老大review代码的声声抱怨时，就说明已经你已经进步了~

文章转载自：CSDN