程序员书库（ID：OpenSourceTop） 编译 编译自：https://statsthinking21./statsthinking21-core-site/
我们的目标是编写可读的代码，但是，无论你和周围的人多么努力的编写可读的代码，还是难以避免阅读到一些难以理解的代码。今天，我们就来讨论一下只注重如何编写方便阅读的代码究竟有什么问题。
假设“不可读的代码”是指某人只管自己敲代码，而不去关心使用代码的人，这是完全错误的，难以理解的代码往往是长期累积的结果：代码是在语言/框架没有做成的时候写的 代码是前一段时间写的，当时的“最佳实践”和现在可能是不一样的 每一行代码的编写都考虑到了可读性，但随着时间的推移，随着代码行的增加，整体信息都丢失了 写这行代码的人已经走了，你找不到人询问代码背后的业务或技术原因（当然，文档也过时了）
诸如此类的情况还有很多，没有人故意编写不可读的代码，如果你有一个只有你贡献代码的项目，你应该就会有所体会，当你创建了一个项目，几周之后会看这个项目时，你都想不起来自己当时写下这段代码时到底在想什么，因为你现在觉得有更好的想法可以取代它。“不可读的代码是代码作者的错，你应该编写可读的代码”的叙述侧重于指责而不是侧重于如何处理问题。我们很容易责备写代码的人写了一些不好的东西，并暗自告诉自己只编写可读的代码，我们很难抛开自我，并思考：我需要掌握一些技能才能阅读这些代码，并搞清楚作者的意图。这样做的主要原因是，抱怨别人可以让我们自我感觉良好，但是这样做并无济于事。想象一下，如果巴兹·鲁尔曼认为“莎士比亚这个家伙的文学功底也不怎么样，还采用了抑扬格五音步，让他的戏剧更加晦涩难懂。我才不会费尽心思去了解罗密欧与朱丽叶，莎士比亚本应写得更好一点。”那我们可能会错过一部独特的电影，因为以今天的标准来看，原作的故事并不“可读”。你在编写可读代码的时候应该考虑读者，反过来，我们也应该对代码的作者抱有善意，学会接受代码的本来面目，真正的专业人士会学习他们代码库的方言，这将更好地帮助他们更好地理解为什么事情会变成现在，只有这样他们才能找到更好的前进方式。我不能假设我认为可读的代码就是你一看就能理解的，我对可读性的看法，就像代码库的不可读性一样，是我经验的积累。我使用过一堆框架和模式在一堆不同的地方工作过。如果某个陌生的（Java） 代码库使用了这些模式，我能立即理解这些代码。但是，如果将我放在现代 JavaScript 应用程序中，我可能会迷失方向——我可以逐行阅读和理解代码，但与经验丰富的开发人员相比，我掌握常见模式或大局的能力要有限得多。当然有用的方法和变量名、简短的方法、有意的设计等等也会让它变得更容易理解，但是它并不能改变我对特定语言、框架、模式或业务领域的不熟悉。无论如何，让读你代码的人尽可能理解你的代码，但你不能仅仅因为你编写了你认为的干净易读的代码就假设所有开发人员都能理解它。阅读代码是一种技能。阅读代码是一种可以学习、可以提高的技能。时间、经验、实践，使用不同的语言、框架和库；不同的代码库；不同的编程风格；不同的模式，将提高你阅读代码的能力。八年前我看不懂英语，现在我可以理解大多数书面内容。事实证明，通过练习，英语并不难。代码也一样，当然，我们一直在阅读代码，无论是在我们的代码库或 StackOverflow，还是博客或书籍或其他任何东西中，我们可以通过我们的工作更好的阅读代码，但这还不够，我们还需要更多的刻意练习。阅读代码是一项可以通过实践提高的技能。下次我们看到我们不理解的代码时，我们不应该因为“不会编写可读代码”而职责作者，我们也不应该因为自己理解不了别人编写的代码而自责，因为我们都有自己独特的经历。相反，我们可以将其视为练习阅读此特定代码并提升我们的“阅读代码”技能的机会。--- EOF ---
|
