（完全免责声明：我认为我的代码阅读不好。不过，我认为我的代码阅读比以前更好。）
在这一点上说，代码的读取次数比编写的次数多是不言而喻的。 当然，读取代码的时间要多于编写代码的时间（尽管我当然欢迎任何只写无错误代码库的示例）。 这就是为什么作为开发人员，我们一直被鼓励编写干净，文档齐全的代码，这些代码对于以后的其他人来说都是可读的（即使那是我们，一年以后，而我们却忘记了持有的一切）在我们写所说的代码时在脑海中）。
但是对于我自己和对学习编程的人来说，我注意到的一点是，对于新手和有经验的程序员而言，编写代码似乎比阅读代码容易。 这很奇怪。 与大多数其他工艺品不同，对于许多人来说，拼凑别人的作品实际上比仅仅自己重新写作更难。
我想不出很多其他的工艺品能做到这一点（尽管我真的很喜欢在海滩上成百上千的人写自己的政治惊悚片而不是带来一个政治惊悚片的想法）。
的确，我认为与读小说或故事的比较是一种启示。 世界上作家与读者之间的严重不平衡向我们表明，要阅读和消费书籍的人要比写书籍的人多得多，这是事实，即使绝大多数人完全有能力写作（也许写得不好，但让我们暂时搁置它）。
但是人们实际上在做什么阅读呢？ 在大多数情况下，阅读是轻松的：人们阅读小说，浏览小说或利用小说消磨时光。 人们很少真正真正接触到手头的文字。 这要困难得多：要真正输入文字，裸露文字并获得所有暗流，主题，主题和隐藏的潜台词是费力，缓慢，艰苦的工作，并且通常需要阅读，重新阅读和记录笔记-服用。
不仅如此，它还需要培训：立即进行这项工作并不容易。 很少有人能够立即进行深度阅读。 这需要有意识的努力，以免略过，在更广泛的叙事中考虑单词，识别主题等等。 它要求读者在其工具包中拥有完整的解释和分析工具库，然后才能真正说出自己已深入阅读一本书。
询问任何人是愿意阅读Moby Dick还是写关于鲸鱼的史诗，我想大多数人都会阅读。 但是，请他们进行深入，艰苦而详尽的阅读，使之真正地体现在解释的本质上吗？
我认为会有更多的人开始写自己的关于鲸鱼的故事。
实际上，这就是许多程序员阅读代码的方式：我们并没有真正解决正在阅读的内容。 当打开项目存储库时，我们面临着令人生畏的前景：成千上万个（也许甚至成千上万）的代码行散布在数十个源文件中。 通常，我们受到时间的限制：该项目中有一个错误需要修复，项目维护者不在工作中，或者我们已介入维护此全职，等等。
那么我们该怎么办？ 就像我们上面的鲸鱼阅读朋友一样，我们也浏览。 我们随意地看一下代码从哪里开始：我们轻拂过去的嵌套循环，信任注释和函数名（肯定是get_project_name获得了项目名，对吗？），并且给了看似正确的条件逻辑一团糟。 最终，我们对发生的问题有一个模糊的想法，我们编写了一个测试用例，并修补了一些代码，直到修复了错误并通过了测试为止。
这甚至适用于写得很好的代码：阅读写得不好的代码甚至会变得更糟，并且甚至会减慢整个过程。 当遇到真正深入的东西（例如重构），这需要我们真正阅读代码时，好吧……
写一个关于鲸鱼的新故事听起来要好得多。
我认为这是因为很多重点放在代码编写上，但不一定是代码读取。 在开始撰写本文之前，我对这个主题进行了一些粗略的搜索。 除了几篇文章（ 还有一本有趣的书，我想我可能不得不拿起书 ）之外，没有很多关于阅读代码的材料。 但是， 编写代码有很多内容：比阅读代码要多几个数量级，我认为这使我们拥有比编写代码更广泛的代码编写工具集。
因为，就像上面的深入阅读一样，阅读代码也需要一套自己的技能和工具。 学习编写代码使我们几乎不懂阅读代码，并且许多对编写代码有用的最佳实践和方法也以有限的方式对阅读代码有用。 我们从重复的实践中获得的好处不仅仅在于：作为开发人员，我们被迫通过反复，沮丧的阅读其他复杂代码的尝试来重新学习代码阅读实践。
我有幸与一些非常优秀的代码阅读器一起工作，并且我认为在过去几年中我已经变得更好。 但这是因为他们花了时间（并且有时间）教我，并向我展示了代码探索的方式：这就像被引入共济会秩序一样，其中知识的唯一传递是从大师到徒弟，并且内部Wiki指导您，这实际上限制了整个企业的可伸缩性。
那么，难怪给定了重点在于编写代码而不是阅读代码，开发人员经常选择重写现有代码而不是阅读代码吗？
对于代码阅读器，我们需要开始记录我们的操作方式：最佳实践，方法论，查看和图解程序流以及源代码结构的方法，这些方法可以使新老开发人员更轻松，更快速地闯入陌生的代码库。 我们不能依靠代码总是干净，编写良好和有文档记录：读取代码就是读取代码 ，而不是阅读围绕它的注释或针对该文档记录的API接口。
对于那些在代码读取方面挣扎的开发人员，请……振作起来。 保持练习。 这是详尽无遗的，令人沮丧的和痛苦的，但是每天您真的会花一些时间阅读一些代码，因为您每天都会对此有所改善。 与其撰写有关鲸鱼的新故事，不如熟悉一个已经存在的鲸鱼。
