前情提要
上一篇文章中，讲到了我在阅读这本书时的感悟，及我对身边同伴于这本书阅读观感的观察、疑惑和思考。在今天的文章中，我将说明疑惑是如何被解决的。
如果你看不懂它的话，那么你就看不懂它
前面我们说到，老人们认为，缺乏足够经验的新手无法领悟 Clean Code。这难道不是一个很讽刺的回答吗？一本书写出来是为了给人指导的，如果说，只有已经具备很足够经验的人才能看懂它，而无法对缺乏经验的人一点帮助，那么，这本书其实是无用的。打个比方的话，就等于幼儿园的小朋友看线性代数……
反过来想
到这个地步，基本上这个问题是无解的了。于是我想到《如何解题》中的建议——
反过来思考。
我一直在想 Clean Code 这本书该怎么看，怎样才能从中得到收获？可是我从来
没有问过，为什么我要读这本书！
是呀，为什么我需要读这本书呢？老人们为什么想让我读这本书呢？他们认为读了这本书可以习得一些编写整洁代码的要点，会提高代码的质量。
为什么要读这本书 -> 老人的建议 -> 提高代码质量
也就是说，其实他们的 目的是让我提高代码质量，而不是读这本书本身 。于是，我们成功地可以把问题从 如何阅读 Clean Code 规约为 如何提高代码质量。
感觉好像问题变得更加明了了，但是如果我们再深入一步呢——为什么要提高代码
质量？
高质量代码 -> 可读性高
可读性高 -> 别人能看得懂
为什么要让别人读得懂 -> 减少沟通成本
为什么要减少沟通成本 -> 团队开发
这才是真正的问题，整洁代码的目的在于减少团队成员的沟通成本，而不在于写出让自己满意的代码。
什么是 Clean Code
深合己意？
如何每个例程都让你感到深合己意，那就是整洁代码 - 沃德原则
咋看之下，这说的是对的。仔细想想，会发现这句话是经不起推敲的。我写了一
段自己满意的代码，那么它就是整洁代码了。如果正如这个 沃德原则 所言的话，
那么整洁的垃圾代码真的不少。自己满意，但是别人看不懂的代码多了去了，这
句话纯粹是废话，完全经不起推敲。
那么到底怎样才算是整洁代码？
大家好才是真的好？
如果每段代码都让团队里的人一看就知道是什么意思，那就是整洁代码。
代码的质量不是作者自己能评定的，要由团队来决定。能让团队成员一下子看懂
的，符合团队开发风格的，才是质量高的代码。程序员的工作，很少单独有一个人完成的。正是因为团队开发的原因，整洁代码才是有必要的。
真正的问题
只有在团队开发的情况下，别人才需要不得不大量阅读你编写的代码。这个时候，
如果你写的代码可读性特别差，就会大大提高成员之间的沟通成本，降低工作效
率。
两个人的团队中，A 和 B 每天开始工作时都得问对方写的代码是什么意思
三个人的团队中，A, B 和 C 一共需要沟通 6 次
四个人的团队中，A，B，C 和 D 需要 24 次
五个人的团队中，A，B，C，D 和 E 需要 120 次
这个计算当然是夸张了，但是，它说明了可读性的代码对于团队生产力的巨大破
坏作用，从反面来说，也就证实了可读性对于团队开发的重要性。
就是在团队开发的情况下，别人才需要阅读你的代码以进行增量开发和功能拓展，
也就只有在这种情况下，可读性才显得如此重要。
自己写完就扔的代码，不需要可读性，就算写完了只有上帝知道它做了什么，有
什么关系？大括号该放哪儿？蛇底式还是驼峰式？函数命名要用动词？类名应该
是名词，不能用复数？自己怎么开心怎么来好吧，管它呢~~~
网友评论