作者 | TRISHAGEE
译者 | 弯月
出品 | CSDN（ID：CSDNnews）
前几天，有人发推文说：“我们阅读的代码量远远超过了编写的代码量，所以我们应该提高阅读代码的水平。”我非常同意这个说法，于是转发了这条推文。
然而，许多人在回复中提出了不同的观点：“但更重要的是，我们应该学习编写方便阅读的代码。”
问题不在于，我们应不应该编写方便阅读的代码。当然每个人都应该编写方便阅读的代码，这一点毫无争议。问题在于，这两个目标并不是互相排斥的，我们无需在“编写方便阅读的代码”与“提高阅读代码的水平”之间进行选择，我们可以做到二者兼之。
然而，无论你多么努力地编写方便阅读的代码，也无论周围的人也同样付出巨大的努力，现实是某些时候你仍然会遇到难以理解的代码。
在本文中，我们就来讨论一下只注重如何编写方便阅读的代码究竟有什么问题。
我们不应该假设某人编写了不可读的代码
假设某人编写了不可读的代码，实际上是在假设某人在编写代码的时候根本不在乎其他程序员，这是完全错误的。难以理解的代码往往是日积月累的结果：
编写代码时的语言/框架与现在有很大的不同；
代码是在很早以前编写的，当时的流行做法和“最佳实践”与现在截然不同；
每一行代码的编写都考虑到了可读性，但随着时间的推移，随着代码行数越来越多，整体的可读性降低了；
程序员来来往往，你无法询问代码背后的业务或技术原因（当然，文档也过时了）。
等等，没有人会故意编写不可读的代码。如果有一个项目，只有你一个人，你就会亲身感受到这一点：编写完一段代码以后，隔几个月、几周甚至几天后，再翻开来看，你就会怀疑当时的自己究竟在想什么，因为现在你有更好的办法来编写这段代码，或者认为应该给这个方法起一个更好的名字。
一味指责别人并不能解决任何问题
“不可读的代码是代码作者的错，他们本该编写方便阅读的代码”，这种观点只是在指责别人，并不能解决任何问题。指责别人写的代码不好当然很容易，还能凸显自己编写的代码方便阅读。我们很难抛开自我，并思考：我需要掌握一些技能才能阅读这些代码，并搞清楚作者的意图。没错，抱怨我们拿到的代码质量不佳，可以让我们自我感觉良好，但不能帮助我们解决任何问题。
想象一下，如果巴兹·鲁尔曼只会抱怨：“莎士比亚这个家伙的文学功底也不怎么样，还采用了抑扬格五音步，让他的戏剧更加晦涩难懂。我才不会费尽心思去了解罗密欧与朱丽叶，莎士比亚本应写得更好一点。”，那么也就没有《罗密欧与茱丽叶：后现代激情篇》这部优秀的电影了。如果我们以当今的标准来品鉴《罗密欧与茱丽叶》，那么也许这个故事也不具备“可读性”。
没错，我们应该为阅读代码的人着想（很可能就是我们自己），编写方便阅读的代码。但同时，我们也应该对编写代码的人心怀善意和尊敬，我们应该学会接受代码本来的样子。真正的专业人士会学习代码库的特殊之处。真正的专业人士会尊敬代码的贡献者。这可以帮助他们更好地理解为什么这些代码会变成现在这样，只有这样他们才能找到前进的最佳方式。
代码的可读性是主观判断
我不能假设，我认为可读的代码你也可以轻松理解。我对可读性的理解，与代码库的不可读性一样，是我自己经验的积累。我曾在不同的工作场所使用过一堆框架和模式。如果某个陌生的（Java） 代码库使用了这些模式，我能立即理解这些代码。
但是，如果将我放在现代JavaScript 应用程序中，我可能会迷失方向，虽然我也可以逐行阅读和理解代码，但与经验丰富的开发人员相比，我掌握的常见模式以及对整体状况的把握要弱很多。
当然有意义的方法名和变量名、简短的方法、意图清晰的设计等等可以帮助我们理解代码。但我也没办法一下子克服不熟悉特定语言、框架、模式或业务领域的困难。
无论怎样，我们都会想办法让其他程序员轻松地阅读我们的代码，但不能因为你编写了自认为整洁易读的代码，就假设所有开发人员都能理解。
阅读代码是一种技能
这就是我最终的观点：阅读代码是一种技能。阅读代码是一种可以学习、可以提高的技能。能够提高阅读代码的能力的因素有很多，包括：时间、经验、实践，使用不同的语言、框架和库；接触不同的代码库、不同的编程风格、不同的模式。
只有通过反复的练习，才能提高阅读代码的能力。当然，我们一直在阅读代码，无论是阅读代码库、StackOverflow，还是博客、书籍或其他文章，这些都是一个良好的开端，只有多学多尝试，才能不断提高阅读代码的水平。但这还不够，我们还应该尝试更多刻意的练习。
阅读代码是一项可以通过实践提高的技能。下次当看到不理解的代码时，我们不应该责备作者编写了“不可读的代码”，也不应该因为读不懂代码而觉得自己很笨，因为每个人都有不同的经历。我们应该将其视为练习阅读特定代码以及提高自己的“阅读代码”能力的机会。
总结
阅读代码是一种技能。
鼓励开发人员“编写方便阅读的代码”并不能消灭开发人员提升“阅读代码”技能的需要。
当然每个人都应该编写方便阅读的代码。
