有人也许会以为，关于代码的书有点儿落后于年代–代码不再是问题;我们应当重视模型和需求。确实，有人说过我们正在接近代码的终结点。很快，代码就会自动发生出来，不需要再人工编写。程序员完全没用了，由于商务人士能够从规约直接生成程序。扯淡!我们永久抛不掉代码，由于代码出现了需求的细节。在某些层面上，这些细节无法被疏忽或抽象，有必要清晰之。将需求清晰到机器能够履行的细节程度，便是编程要做的事。而这种规约正是代码。
看这本书的那种感觉很奇妙，有时感觉作者说地真对！有时感觉作者骂地真对！有时感觉作者挖苦地真对！还有时看到作者列出的实在代码中的错误示例，再看到作者写出的优化后的代码，内心不禁在想：太妙了，代码本应这样啊！
没错，代码本应该是整齐的，也本应该是好了解、易扩展的！我们常说的规划形式也并不是一种炫技，而是几十年来的老前辈们总结出来的经验，是为了让你的代码更好保护的，是一种理所应当。
在作业中遇到烂代码的或许性是 100%，即使是很厉害的大佬写的代码，在不知情的情况下让你去看，看了一会后都会得出以下定论：“写的啥玩意啊，看都看不懂，杂乱无章的语法糖，考虑过后面作业的人么？什么规划形式，什么各种模块，直接写一块不好么？” 假定的或许有点夸张，但也都是人之常情。有时作业中遇到的烂代码是假的，或许是由于当时自己的技术水平不够，不了解；当然还有一部分或许真的是烂，可是这种情况下仍是要做出一些改变！
现在让大家看几个月之前自己写的代码或许都会觉得写的一团糟，用当时的眼光来看或许会有更好的方式或方法来实现，假如你有这种主意的话，请付诸实践！不要等，哪怕是一个单词的拼写错误、一段本不应该写两遍的逻辑、一段没有进行格式化的代码。。。。亦或许是比较大规模的代码改动，改完之后可扩展性会更强，保护起来会更加容易。千万不要等，不要忍受当时的烂代码，代码本便是一向在重构的一个过程，没有哪段代码从出来就不改。下面这段话是书里的内容：
我们都从前瞟一眼自己亲手造成的混乱，决定弃之而不顾，走向新一天。我们都从前看到自己的烂程序居然能运转，然后断言能运转的烂程序总比什么都没有强。我们都从前说过有朝一日再回头整理。当然，在那些日子里，我们都没听过勒布朗(LeBlanc)规律:稍后等于永不(Later equals never).
当然很多人会说：“项目中的屎山代码，我能在上面雕花现已很厉害了，还要干什么，即使我知道那块写的不好，但我也不会去动，由于现在它处于一个安稳的状态，假如我去修正了之后，出了问题全是自己背，吃力不讨好！”这也确实是很多人的现状，考虑的也不无道理，但在这儿我们单纯从代码的角度来看，从写代码的初心来看，早早的就各走各路了。
代码格式不可疏忽，有必要严肃对待。代码格式关平交流而交流是专业开发者的头等大事。 或许你以为“让代码能作业”才是专业开发者的头等大事。可是，我希望本书能让你抛掉那种主意。你今日编写的功能，极有或许在下一版别中被修正，但代码的可读性却会对以后或许发生的修正行为发生深远影响。原始代码修正之后好久，其代码风格和可读性仍会影响到可保护性和扩展性。即使代码已不复存在，你的风格和律条仍存活下来。
我有代码洁癖，看不了没有格式的代码，看着有的项目中一个函数几百行乃至更多，里边各种重复逻辑，if/else不知道嵌套了多少层，外表看是逻辑杂乱，再转念一想，为什么不用工厂、或许写一些其他类来简化下逻辑。这时肯定有人会站起来反对：“明明很简单的逻辑，非得运用什么规划形式，搞得一团乱还看不懂。。” 假如只是一个if/else，或许逻辑比较简单肯定没必要，可是逻辑杂乱的情况下光if/else也满足将人搞晕，且当需求改变年代码变得难以保护。
我之前一向觉得写完代码格式化是正常的，是根本操作，可是作业中发现好像不是一个根本操作，格式化并不涉及到专业才能，而是情绪，连格式化都懒得做，你说你写出的代码经过了严厉的测试。。。。想起之前上学时老师常常说的一句话：作业会不会是才能问题，而做不做便是情绪问题了。
说这些并没有什么恶意，仅是这本书的读后感，读完后就好像和作者现已是相识多年的老友，相视一笑。
