最近读了一本书，名字大家都看到了：《代码整洁之道》，之前一直只是听说过这本书的大名，却一直没有进行拜读，最近想起来了就想着看一看，不看不要紧，看了之后就像吃了炫迈，根本停不下来。。。虽然这本书已经出版了十几年的时间，但里面的理论到现在为止也不过时。

有人也许会以为，关于代码的书有点儿落后于时代–代码不再是问题;我们应当关注模型和需求。确实，有人说过我们正在临近代码的终结点。很快，代码就会自动产生出来，不需要再人工编写。程序员完全没用了，因为商务人士可以从规约直接生成程序。扯淡!我们永远抛不掉代码，因为代码呈现了需求的细节。在某些层面上，这些细节无法被忽略或抽象，必须明确之。将需求明确到机器可以执行的细节程度，就是编程要做的事。而这种规约正是代码。

看这本书的那种感觉很奇妙，有时感觉作者说地真对！有时感觉作者骂地真对！有时感觉作者讽刺地真对！还有时看到作者列出的真实代码中的错误示例，再看到作者写出的优化后的代码，内心不禁在想：太妙了，代码本应这样啊！

没错，代码本应该是整洁的，也本应该是好理解、易扩展的！我们常说的设计模式也并不是一种炫技，而是几十年来的老前辈们总结出来的经验，是为了让你的代码更好维护的，是一种理所应当。

在工作中遇到烂代码的可能性是 100%，即使是很厉害的大佬写的代码，在不知情的情况下让你去看，看了一会后都会得出以下结论：“写的啥玩意啊，看都看不懂，乱七八糟的语法糖，考虑过后面工作的人么？什么设计模式，什么各种模块，直接写一块不好么？” 假设的可能有点夸张，但也都是人之常情。有时工作中遇到的烂代码是假的，可能是由于当前自己的技术水平不够，不理解；当然还有一部分可能真的是烂，但是这种情况下还是要做出一些改变！

现在让大家看几个月之前自己写的代码可能都会觉得写的一团糟，用当前的眼光来看可能会有更好的方式或方法来实现，如果你有这种想法的话，请付诸实践！不要等，哪怕是一个单词的拼写错误、一段本不应该写两遍的逻辑、一段没有进行格式化的代码。。。。亦或者是比较大规模的代码改动，改完之后可扩展性会更强，维护起来会更加容易。千万不要等，不要忍受当前的烂代码，代码本就是一直在重构的一个过程，没有哪段代码从出来就不改。下面这段话是书里的内容：

我们都曾经瞟一眼自己亲手造成的混乱，决定弃之而不顾，走向新一天。我们都曾经看到自己的烂程序居然能运行，然后断言能运行的烂程序总比什么都没有强。我们都曾经说过有朝一日再回头清理。当然，在那些日子里，我们都没听过勒布朗(LeBlanc)法则:稍后等于永不(Later equals never).

当然很多人会说：“项目中的屎山代码，我能在上面雕花已经很厉害了，还要干什么，即使我知道那块写的不好，但我也不会去动，因为现在它处于一个稳定的状态，如果我去修改了之后，出了问题全是自己背，吃力不讨好！”这也确实是很多人的现状，考虑的也不无道理，但在这里咱们单纯从代码的角度来看，从写代码的初心来看，早早的就背道而驰了。

代码格式不可忽略，必须严肃对待。代码格式关平沟通而沟通是专业开发者的头等大事。 或许你认为“让代码能工作”才是专业开发者的头等大事。然而，我希望本书能让你抛掉那种想法。你今天编写的功能，极有可能在下一版本中被修改，但代码的可读性却会对以后可能发生的修改行为产生深远影响。原始代码修改之后很久，其代码风格和可读性仍会影响到可维护性和扩展性。即便代码已不复存在，你的风格和律条仍存活下来。

我有代码洁癖，看不了没有格式的代码，看着有的项目中一个函数几百行甚至更多，里面各种重复逻辑，if/else不知道嵌套了多少层，表面看是逻辑复杂，再转念一想，为什么不用工厂、或者写一些别的类来简化下逻辑。这时肯定有人会站起来反对：“明明很简单的逻辑，非得使用什么设计模式，搞得一团乱还看不懂。。” 如果只是一个if/else，或者逻辑比较简单肯定没必要，但是逻辑复杂的情况下光if/else也足够将人搞晕，且当需求改变时代码变得难以维护。

我之前一直觉得写完代码格式化是正常的，是基本操作，但是工作中发现好像不是一个基本操作，格式化并不涉及到专业能力，而是态度，连格式化都懒得做，你说你写出的代码经过了严格的测试。。。。想起之前上学时老师经常说的一句话：作业会不会是能力问题，而做不做就是态度问题了。

说这些并没有什么恶意，仅是这本书的读后感，读完后就好像和作者已经是相识多年的老友，相视一笑。