本系列文中会有大量书中内容摘抄，都是个人认为很值得分享的内容。当然，也会有个人感悟，作为学习记录及简单分享。
Code Monkey
文中提到，本书的作者 Robert C. Martin（鲍勃大叔）曾在一场演讲中以歌曲 《Code Monkey》 开场，暗讽低水平编码者。
是的，我们就是一群代码猴子，上蹿下跳，自以为领略了编程的真谛。可惜，当我们抓着几个酸桃子，得意扬扬地坐在树枝上，却对自己造成的混乱熟视无睹。那堆“可以运行”的乱麻程序，就在我们的眼皮底下慢慢腐坏。 -- 译者序
第一次读到时，我觉得这个比喻很好笑，又很真实。
再次读到，更多的是引发我的思考。因为曾经我也认识不到自己代码的问题，或者意识到了问题却没有立即付诸实际行动去解决，诚然有诸多外在因素和客观原因，但是自己的编码水平和对待这类问题的态度也是一个不可忽视的问题。
为什么会有糟糕的代码
我们过早的放弃了在代码上的工作，并不是因为它业已完成，而是因为我们的价值体系关注外在表现甚于关注要交付之物的本质。输出最终结出了恶果：坏东西一再出现。 -- 序
不知道小伙伴们有没有遇到过项目给到你的时候就已经做好了排期的情况，我最近频频遇到需求给到我的同时，告诉我 5 天后要上线，一周后要上线，往往这个时候，UI 设计图还没有出完。
这里我想说的是有时候有一些客观因素导致我们没有时间精雕细琢编写的代码，但是我相信每一个有追求的编码者都希望自己能写出好的代码。
上面这段话还有一个含义就是有一部分没有追求的编码者（或者 code monkey 更准确一点 😏），因为自己的技术水平或者态度问题不去关注代码质量，更不愿花费更多的时间和精力让自己的代码变得更好，如果遇到这种人，离他远点吧 💨。
如果不是工作后就加入了一个非常优秀的团队，工作过一段时间的小伙伴可能都被糟糕的代码所困扰过，那么，为什么要写糟糕的代码呢？
是想快点完成吗？是要赶时间吗？有可能。或许你觉得自己要干好而所需的时间不够；假使花时间清理代码老板就会大发雷霆。或许你只是不耐烦再搞这套程序，期望早点儿结束。或许你看了看自己承诺要做的其他事，意识到得赶紧弄完手上的东西，好接着做下一件工作。这种事我们都干过。
我们都曾经瞟一眼，自己亲手造成的混乱，决定气质而不顾走向新一天.我们都曾经看到自己的烂程序居然能运行，然后断言能运行的烂程序总比什么都没有强。我们都曾经说过有朝一日，再回头清理。当然在那些日子里，我们都没有听过勒布朗（LeBlanc）法则:稍后等于永不（Later equals never.）。
有些团队在项目初期进展迅速，但有那么一两年的时却慢如蜗行。对代码的每次修改都影响到其他两三处代码，修改无小事。每次添加或修改代码都得对那堆扭纹柴了然于心，这样才能往上扔更多的扭纹柴。这团乱麻越来越大，再也无法清理，最后束手无策。
随着混乱的增加，团队生产力也持续下降，以致趋向于零。当生产力下降时，管理层就只有一件事可做了：增加更多的人手到项目中，期望提升生产力，可是新人并不熟悉系统的设计，他们搞不清楚什么样的修改符合设计意图，什么样的修改违背了设计意图。而且他们以及团队中的其他人都背负着提升生产力的可怕压力。于是，他们只会制造更多的混乱，驱动生产力向零那端不断下降。
最后,开发团队造反了，他们告诉管理层，再也无法在这令人生厌的代码基础上做开发了.他们要求做全新的设计。管理层不愿意投入资源完全重起炉灶，但他们也不能否认生产力低得可怕。他们只好同意开发者的要求，授权去做一套看上去很美的华丽新设计。
于是就组建了一只新军。谁都想加入这个团队，因为它是张白纸。他们可以重新来过搞出点真正漂亮的东西来。但只有最优秀、最聪明的家伙被选中，其余人则继续维护现有系统。
现在有两支队伍在竞赛了。新团队必须搭建一套新系统新系统，新系统要实现旧系统的所有功能，另外，还得跟上对旧系统的持续改动。在新系统功能足以抗衡旧系统之前，管理层不会替换掉旧系统。
竞赛可能会持续极长时间。我就见过延续了十年之久的。到了完成的时候，新团队的老成员早已不知去向，而现有成员则要求重新设计一套新系统，因为这套系统太烂了。
假使你经历过哪怕是一小段我谈到的这种事，那么你一定知道，花时间保持代码整洁不但关乎效率，还关乎存亡。 -- 1.3 混乱的代码
读完上面这段话，我坦白，我有过其中多种情况。
至此，我们已经充分认识到了代码整洁的重要性，那么什么是整洁代码呢？让我们听听大佬们怎么说。
什么是整洁代码
Bjarne Stroustrup，C++语言发明者，《C++程序设计语言》（C++ Programming Language）一书作者
我喜欢优雅和高效的代码。代码逻辑应当直截了当，令缺陷难以隐藏；尽量减少依赖关系，使之便于维护；依据某种分层战略完善错误处理代码；性能调至最优，省得引诱别人做没规矩的优化，搞出一堆混乱来。整洁的代码只做好一件事。
Grady Booch，《面向对象分析与设计》（Object Oriented Analysis and Design with Applications）一书作者
整洁的代码简单直接。整洁的代码如同优美的散文。整洁的代码从不隐藏设计者的意图，充满了干净利落的抽象和直截了当的控制语句。
Michael Feathers，《修改代码的艺术》（Working Effectively with Legacy Code）一书作者
我可以列出我留意到的整洁代码的所有特点，但其中有一条是根本性的。整洁的代码总是看起来像是某位特别在意它的人写的。几乎没有改进的余地。代码的作者什么都想到了，如果你企图改进它，总会回到原点，赞叹某人留给你的代码——全心投入的某人留下的代码。
上面是我在书中摘抄的个人最有共鸣的三段话，每一段都值得反复阅读。
带来的好处
不知道小伙伴们有没有听过一句话，代码是写给人看的，这里的人，不只是当前团队中的其他小伙伴，后续接手这个项目的小伙伴，还有我们自己。
有人可能会想，代码真正 “读” 的成分有多少呢？不是应该把主要力量用在 “写” 上吗？
但是你有没有遇到这种情况，有一个项目，或者有一个模块，当我们需要添加新的功能的或者调整之前的某段逻辑，我们需要花费修改代码几倍甚至更多的时间去阅读周边代码，如果之前的代码编写的比较糟糕，这个时间甚至更久，所以我们在写新代码时，一直在读旧代码。
那么为了让读的过程更轻松些，我们应该编写整洁易读的代码，即使那会使编写过程更难，但是从整体来看，是会大大提升我们的工作效率的。
结尾
最后我想说，固然，编写整洁的代码是要比随意去写更耗费时间和精力的，另外很多公司和技术团队对这些也没有足够的重视或者没办法给到足够的时间。
但是作为一个合格的程序员，我认为我们有责任、有必要编写整洁、可维护的代码，至少让每次签入时，比签出时干净，也许只是改好一个变量命名，拆分一个非单一职责的函数，消除一点点重复代码，让这个项目，比我们来时更干净。
当然，空有想法和热情是不够的，编写整洁代码需要技巧、技术和工具，让我们一起学习吧！😁
