怎么会发生这种事?为什么好代码会这么快就变质成糟糕的代码?理由多得很。我们抱怨需求变化背离了初期设计。我们哀叹进度太紧张，没法干好活。我们把问题归咎于那些愚蠢的经理、苛求的用户、没用的营销方式和那些电话消毒剂。不过，亲爱的呆伯特(Dilbert) ，我们是自作自受 。我们太不专业了。

　　这话可不太中听。怎么会是自作自受呢?难道不关需求的事?难道不关进度的事?难道不关那些蠢经理和没用的营销手段的事?难道他们就不该负点责吗?

　　不。经理和营销人员指望从我们这里得到必须的信息，然后才能做出承诺和保证;即便他们没开口问，我们也不该羞于告知自己的想法。用户指望我们验证需求是否都在系统中实现了。项目经理指望我们遵守进度。我们与项目的规划脱不了干系，对失败负有极大的责任;特别是当失败与糟糕的代码有关时尤为如此!

　　"且慢!"你说。"不听经理的，我就会被炒鱿鱼。"多半不会。多数经理想要知道实情，即便他们看起来不喜欢实情。多数经理想要好代码，即便他们总是痴缠于进度。他们会奋力卫护进度和需求;那是他们该干的。你则当以同等的热情卫护代码。

　　再说明白些，假使你是位医生，病人请求你在给他做手术前别洗手，因为那会花太多时间，你会照办吗 ?本该是病人说了算;但医生却绝对应该拒绝遵从。为什么?因为医生比病人更了解疾病和感染的风险。医生如果按病人说的办，就是一种不专业的态度(更别说是犯罪了)。

　　同理，程序员遵从不了解混乱风险的经理的意愿，也是不专业的做法。

　　1.3.3 迷题

　　程序员面临着一种基础价值谜题。有那么几年经验的开发者都知道，之前的混乱拖了自己的后腿。但开发者们背负期限的压力，只好制造混乱。简言之，他们没花时间让自己做得更快!

　　真正的专业人士明白，这道谜题的第二部分说错了。制造混乱无助于赶上期限。混乱只会立刻拖慢你，叫你错过期限。赶上期限的唯一方法-做得快的唯一方法 -就是始终尽可能保持代码整洁。

　　1.3.4 整洁代码的艺术

　　假设你相信混乱的代码是祸首，假设你接受做得快的唯一方法是保持代码整洁的说法，你一定会自问："我怎么才能写出整洁的代码?"不过，如果你不明白整洁对代码有何意义，尝试去写整洁代码就毫无所益!

　　坏消息是写整洁代码很像是绘画。多数人都知道一幅画是好还是坏。但能分辨优劣并不表示懂得绘画。能分辨整洁代码和肮脏代码，也不意味着会写整洁代码!

　　写整洁代码，需要遵循大量的小技巧，贯彻刻苦习得的"整洁感"。这种"代码感"就是关键所在。有些人生而有之。有些人费点劲才能得到。它不仅让我们看到代码的优劣，还予我们以借戒规之力化劣为优的攻略。

　　缺乏"代码感"的程序员，看混乱是混乱，无处着手。有"代码感"的程序员能从混乱中看出其他的可能与变化。"代码感"帮助程序员选出最好的方案，并指导程序员制订修改行动计划，按图索骥。

　　简言之，编写整洁代码的程序员就像是艺术家，他能用一系列变换把一块白板变作由优雅代码构成的系统。

　　1.3.5 什么是整洁代码

　　有多少程序员，就有多少定义。所以我只询问了一些非常知名且经验丰富的程序员。

　　Bjarne Stroustrup，C++语言发明者，C++ Programming Language(中译版《C++程序设计语言》)一书作者。

　　我喜欢优雅和高效的代码。代码逻辑应当直截了当，叫缺陷难以隐藏;尽量减少依赖关系，使之便于维护;依据某种分层战略完善错误处理代码;性能调至最优，省得引诱别人做没规矩的优化，搞出一堆混乱来。整洁的代码只做好一件事。

　　Bjarne用了"优雅"一词。说得好!我MacBook上的词典提供了如下定义：外表或举止上令人愉悦的优美和雅观;令人愉悦的精致和简单。注意对"愉悦"一词的强调。Bjarne显然认为整洁的代码读起来令人愉悦。读这种代码，就像见到手工精美的音乐盒或者设计精良的汽车一般，让你会心一笑。

　　Bjarne也提到效率-而且两次提及。这话出自C++发明者之口，或许并不出奇;不过我认为并非是在单纯追求速度。被浪费掉的运算周期并不雅观，并不令人愉悦。留意Bjarne怎么描述那种不雅观的结果。他用了"引诱"这个词。诚哉斯言。糟糕的代码引发混乱!别人修改糟糕的代码时，往往会越改越烂。

　　务实的Dave Thomas和Andy Hunt从另一角度阐述了这种情况。他们提到破窗理论 。窗户破损了的建筑让人觉得似乎无人照管。于是别人也再不关心。他们放任窗户继续破损。最终自己也参加破坏活动，在外墙上涂鸦，任垃圾堆积。一扇破损的窗户开辟了大厦走向倾颓的道路。

　　Bjarne也提到完善错误处理代码。往深处说就是在细节上花心思。敷衍了事的错误处理代码只是程序员忽视细节的一种表现。此外还有内存泄漏，还有竞态条件代码。还有前后不一致的命名方式。结果就是凸现出整洁代码对细节的重视。

　　Bjarne以"整洁的代码只做好一件事"结束论断。毋庸置疑，软件设计的许多原则最终都会归结为这句警语。有那么多人发表过类似的言论。糟糕的代码想做太多事，它意图混乱、目的含混。整洁的代码力求集中。每个函数、每个类和每个模块都全神贯注于一事，完全不受四周细节的干扰和污染。

　　Grady Booch，Object Oriented Analysis and Design with Applications(中译版《面向对象分析与设计》)一书作者。

　　整洁的代码简单直接。整洁的代码如同优美的散文。整洁的代码从不隐藏设计者的意图，充满了干净利落的抽象和直截了当的控制语句。