嗨，我是鲍勃大叔，这里是整洁代码之道课程。
现在该上天文课了。
整洁代码重要吗？
整洁代码，这重要吗？
《实现模式》是Kent Beck写的一本书。如果你想养成好的编码习惯，这是一本非常好的书。
但是在这本书里，Kent说它是基于一个脆弱的承诺，好的代码很重要。
（这个承诺）脆弱吗？ 我可不这么想，
让我给你讲一个故事，这个故事是关于“一个被代码干掉的公司”。
从前，我在一个公司上班，我用一个工具来调试C源代码。这是一家叫“soyed ink”的公司的产品。
这是一个强大的工具，它节省了我们很多精力。
但是，在上世纪90年代，我们正从c转到C++.
Soyed公司指天发誓，发布c++版本的debug的日子很快就要到了。
但是，时光如飞，6个月以后，他们交付了c++版本的debug，并且花了45分钟加载。然后就宕掉了。
我们严正的警告他们。
他们承诺会很快提供一个好的版本。
我们将信将疑，但是我们决定等等。
6个月后，他们发给我们一个新的版本。你猜怎么样？
他们花了45分钟加载，然后又宕了。
从此，我们不再指望他们，在我们看来，这个产品完了。
果不其然，6个月后，这个公司完蛋了。
十年后，我遇到了一个在那家公司亲历了这个产品的员工，他给我讲了背后的故事。
他说，我们飞快的进入Cdebug市场，我们写了太多的垃圾代码。
当我们要写C++版本的时候，根本没法动这些垃圾代码。
所以，整洁代码，对他们当然很重要。
最后，就是这些垃圾代码，干掉了这家公司。
但是，问题在哪里？垃圾代码是怎么干掉这家公司的？
生产率陷阱
你做过全新的项目吗？你还记得当时的生产率是怎样的吗？
那时候，随着键盘在你的指尖噼啪作响，你交付了一个又一个功能特性。你的速度如飞。
你不停的申请新的任务，你只需几天甚至几小时就能搞定它们。
但是，这个速度是不能持久的。过了一年半载，开发速度慢了下来。
你的工作难度越来越大，开发速度越来越慢。
这是为什么？这是因为你的代码越来越乱。
而且研究烂代码真的很花时间，
真的太花时间了。
一开始让你巨爽无比的高速度急剧下降。以前只要几小时的工作，现在要好几天。
以前只要几天的工作，现在要好几周，好几个月，甚至不可能完成。
老板们开始担忧了，
毕竟，他们是根据你一开始的高生产率来做的计划。
现在，他们要面对现实和商业计划之间的可怕的差距。
老板们消除差距的第一招就是给软件开发人员更大的压力。
这个方法带来的后果就是开发人员会制造越来越多的垃圾代码。
And dispy his role and efforts
开发速度下降更多。
第二招，老板试图给现在的团队增加更多的人手。
这当然导致生产率下降。
因为新成员没有想老成员那样吃过烂代码的苦头，
所以他们飞快的工作，写了一大堆烂代码。
这使得生产率下降的更厉害。
增加人手可不便宜，这样，老板现在面临的囧境是，即增加了人手，又降低了生产率。
走投无路的老板只好问计于程序员，问他们觉得该怎么办？
程序员当然会建议他们认为最优的办法
他们盼着重新设计系统好几个月了。
他们中的一个说
对系统来说，最佳方案是
is working the machine to remove the great big magan.
系统需要重新设计了
老板们被这个方案吓坏了。
他们知道这得花多少钱。
并且他们对新方案也没有多少信心。
但他们还有别的选择吗？
他们识时务的取消了一切其他的计划。
并且，他们批准了重新设计整个系统。
对开发人员来说，这是一个阳光明媚的日子。
我们要重新做一个全新的项目，我们将远离那些烂代码，我们又会取得高生产率。啊，这是多么美好的一天啊！
这样，我们挑出了最好的精英，他们是推动者，他们是行家里手。
他们会通过重新设计系统，带领我们从泥沼中走向光明。
留下的人痛恨这些精英。
因为客户现在要的不是精英们将要做的东西。
客户要的是缺陷修复安定新增特性。这样，我们被迫留下来维护烂代码。而那些精英们则可以去做全新的项目。
与此同时，精英团队得有需求啊。
你猜，从哪里可以弄到需求？
你觉得会有需求文档吗？就算有，你觉得它们靠谱吗？
不，不，不，以前有过这么多的最后时刻的缺陷修复和午夜验证，这使得需求文档完全不靠谱。
真正的需求在老系统中，在老系统的代码中。
现在，精英团队被迫研究老系统，试图弄清楚新系统的需求是怎么样的。
就这样，比赛开始了，就像希腊神话中的阿基里斯和乌龟赛跑一样。
每次，当精英团队弄清楚了老的系统是什么样的，缺陷修复和验证就已经使得老系统面目全非了。
这事儿我见了10多年了。
这些年来，老员工一个个被新员工取代。
系统越来越乱，仍然不能上线工作。
最后，就算它从来没有被部署过，开发人员仍然要开发和重新设计它。
这就是烂代码阻碍项目，部门，大区，甚至整个公司的故事。
但是，烂代码是怎样极大的拖低了生产率？背后的机制是什么？
代码腐烂
他们对这些代码做了什么？为什么这些代码变坏了？代码在开始的时候即整洁又漂亮。
但是，随着时间的推移，代码变得腐败，发臭，就像一块烂肉。
通过观察软件开发人员看代码时的表情，你可以知道这些代码有多老。
在我们探寻原因之前，让我们先看看这些现象。
降低我们开发速度的腐烂代码是什么？它是怎样影响我们的生产率的？它是怎么影响我们的评估的？
僵化
一个僵化的系统是这样的一个系统，当我们需要修改或者提高系统中的一个功能点，它会迫使你修改许多系统中的别的点。
这是因为代码是如此的？？
在任何时候，当你修改某一点时，你被迫去检查，判断许多其他点。
然后，你不得不对更多点做检查和判断（雪崩效应）。
程序员就像小狗追逐它的尾巴一样，不停的检查代码（无限接近，但是永远不能到达）。
在这里，那里，那里，那里不停的修改，仅仅是为了让系统运行起来，就可能要检查，改动好几百个模块。
僵化的系统无法预测，非常难以评估，因为你不知道有多少模块需要修改。
脆弱的
脆弱的系统是这样的系统，当你修改一个点时，许多点都不能正常工作。
对这样的系统，一个简单的修改可以导致整个系统充斥着不稳定的功能。
对于这样的系统，非常难以评估。因为它是如此的不可捉摸。
当一个系统是脆弱的，用户和老板对此非常头痛。
他们看见奇怪的，杂乱的函数曾经可以工作。
这些杂乱的功能使得他们很紧张。
当开发人员在这里做一个改动，其他另一个地方被破坏了。没有什么是靠得住的，开发人员显得技能不足，系统显得很不可靠。
不可分割的
一个不可分割的系统是这样的系统，它是由不可分割，且不能重用于其他目的的模块构成的系统。
我们试图使得这些构成系统的模块能够重用
不幸的是，这些努力通常失败了。
系统设计师没能让模块有很好的边界。
软件开发人员急于找一些捷径，这些捷径通常跨越好几个模块，
这导致模块不可分割且不可重用。
不可分割的系统难以捉摸，你永远不知道你是否能重用系统中的任何组合模块。所以，你没法做可靠地评估。
不透明的
在这两扇门背后，是在进行代码评审。花点时间研究一下这幅图。一副好的图胜过一千句。
不透明的代码是这样的代码，它不能交流作者的意图，它很难阅读，很难理解而且很难修改。
快速开发
你有没有被烂代码弄晕过？当然有！我们都是码工啊，当会有过。
问题是你为啥要写烂代码？因为愚蠢的老板？因为不耐烦的客户？或者因为不可能完工的进度计划？或者是需求老是变化？
事实上，原因是以上因素的组合，它们都是让代码变烂的间接因素。
然而，让代码变坏的直接推手是码工，对，码工，我们，我们是让代码变烂的直接推手，这是我们的错。我们不能责备别人。是我们写的烂代码。
写出烂代码的第一个原因是我们感受到产品交付日期的压力。
所以，我们就匆忙的编码，我们安慰自己我们可以以后来修复这些烂代码，但是，我们知道我们不会回来的。
就是这些想法使得烂代码降低我们的开发速度，我们不能通过写烂代码来加快开发速度。
而且，你已经知道这一点了，你知道你会被烂代码弄晕。
如果你想要高速开发，你必须保持代码整洁。保持高速开发的唯一之道就是保持做好每一步。
这很难接受，每个人都认为他能够通过匆忙编码来得到高速开发，但是这不可能，你不可能通过匆忙编码来获得高速度。
某些人认为，在短期内这很快，但是这回带来长期成本的增加。
但是，就算这个观点成立，如果你匆忙编码，这即伤害短期目标，又伤害长期目标。整洁代码没有短期成本，并且你不可能通过匆忙编码来获得高速开发。
寿司
你看寿司大厨怎么做寿司吗？这是一个你能直接观察到的奇迹
下次你去的时候，多注意一下，你会发现厨师做的非常快。
厨房里有这么多东西，他知道器具在哪里，他知道食材在哪里，每一个动作都是如此到位，他动作如飞。
这是一个奇迹。然后，在这一刻，当他把精心准备的食物放到你的面前时，如果你看一下他的工作区，你注意到这里井井有条。
他在工作的时候就在随时清理工作区，因为这是他可以保持高速的唯一之道。
好的，我们现在知道了，烂代码是怎样搞晕我们的，而且我们知道了走的快的唯一之道就是走的好。
那么，什么是整洁代码?
什么是整洁代码？
什么是整洁代码？我问过几个大牛。这样，让我们听听他们怎么说。
Bjarne Stroustgrup, C++的发明人说。
我喜欢我的代码优雅且高效。整洁代码只做一件事，优雅的代码只需要几句话就能做很多事。高效的代码非常好读，不会浪费读者的时间。
‘代码只做一件事’是什么意思？我们将在后续章节中花很多篇幅来讲述的它。
Grady Booch， 上世纪90年代经典作品《面向对像分析与设计》一书的作者，说
整洁代码应该简单且直接。整洁代码应该读起来像一首优美的诗歌。
我们都会同意‘简单且直接’这一部分，但是，代码真的能读起来像优美的诗歌吗？
短一点的回答是‘是的’。长一点的回答是‘好吧，几乎全都可以’。
我们很快会在其他章节中谈到这一点。
Michael Feathre, 《修改代码的艺术》一书的作者，说
整洁代码总是看上去像是特别在意它的人写的。
这真是一个很可爱的想法啊，我们看过了这么代码，看上去没有人在意它们。本课程就是教授“如何在意代码”。
Ward Cunningham, 是wiki的发明人，让我们继续
他说，你知道你是在读整洁代码，当你发现你读到的每一句代码都深合你意的时候。
这正是Ward的风格，用简单明了的话来表达高深的含义。
你上一次读到像你期望的代码是什么时候？并且我们怎么才能写出读者期望的代码呢？
这就是本课程要讲述的。我们要学习注意细节，仔细，简单且直接。这就是整洁代码之道。
童子军军规
Robert Stephenson Powell是童子军之父，当他死去的时候，他说，让世界比你发现它的时候更美好。
如果，我们这样对待我们的代码会有什么（后果）？如果我们把这条规则用在(代码)，说，让你的代码模块签入时比你签出它们的时候更干净。
在签入代码之前，总是做一些力所能及的事使得你的代码更干净。
如果每个人都这么做，代码会变得越来越好，越来越好。。。
这两点，就是本课程的核心思想。
好的，足够多的关于整洁代码的好内容，让我们进入代码吧。
让我们进入第二章。
谢谢大家！