1.整洁代码
阅读本书有两个原因，第一，你是个程序员，第二，你想成为更好的程序员
1.1 要有代码
有人认为随着时代的发展，写代码不再是问题，我们更应该关注建模和需求
这句话后半句没有问题，因为语言在发展、在进步，但是无论语言发展的如何强大，最终的精确性都需要代码来实现，所以代码是不可被丢弃的
1.2 糟糕的代码
问：为什么会有糟糕的代码？
答：想着快点完成；赶时间；老板给的时间不足以写出好的代码；先完成需求，之后在对代码进行优化；能运行的代码总比没有强
其实当你有了之后回头优化的想法，大概率你也不会优化了
勒布朗说过：稍后等于永不
1.3 混乱的代价
在这里插入图片描述相信很多有工作经验的人，都经历过前人的代码，被这种代码拖累，导致整个团队生产力下降，这时候技术leader就会投入更多的人，然后新人并不了解代码，也不知道如何修改代码，导致就按照自己的想法写代码，最终导致代码越来越混乱，直到生产力降到0
1.3.1 华丽新设计
出现了上面的问题，人们的第一想法就是：摒弃老的代码，做一个全新的设计，这是一个好的思路，也是一个正确的思路，但是从老迁移到新的时间成本很高，在没有完全迁移完成，老的系统也没法下掉，就这样我们进行新老系统的维护，一旦设计新系统的人离职了，可能新来的成员又要进行设计新系统了，因此我需要花时间去保持代码的整洁
1.3.2 态度
写代码的态度也决定你写的代码好坏，不知道你是否经历过要花费几个星期来完成本应该几个小时的工作，是否经历过只需要做一行改动，却设计上百个模块的情况？
为什么会发生这样的事，为什么好的代码会很快变成糟糕的代码？
我们抱怨需求变化背离了初期设计。我们哀叹进度太紧张，没法干好活。我们把问题归咎于那些愚蠢的经理、苛求的用户、没用的营销方式等，代码自然就写不好了
程序员遵从不了解混乱风险的经理的意愿，也是不专业的做法。
1.3.3 谜题
程序员面临着一种基础价值谜题。有那么几年经验的开发者都知道，之前的混乱拖了自己的后腿。但开发者们背负期限的压力，只好制造混乱。简言之，他们没花时间让自己做得更快！真正的专业人士明白，这道谜题的第二部分说错了。制造混乱无助于赶上期限。混乱只会立刻拖慢你，叫你错过期限。赶上期限的唯一方法—做得快的唯一方法—就是始终尽可能保持代码整洁。
1.3.4 整洁代码的艺术
写整洁代码，需要遵循大量的小技巧，贯彻刻苦习得的“整洁感”。这种“代码感”就是关键所在。有些人生而有之。有些人费点劲才能得到。它不仅让我们看到代码的优劣，还予我们以借戒规之力化劣为优的攻略。
缺乏“代码感”的程序员，看混乱是混乱，无处着手。有“代码感”的程序员能从混乱中看出其他的可能与变化。“代码感”帮助程序员选出最好的方案，并指导程序员制订修改行动计划，按图索骥。
简言之，编写整洁代码的程序员就像是艺术家，他能用一系列变换把一块白板变作由优雅代码构成的系统。
1.3.5 什么是整洁代码
大家对整洁代码，都有着自己的理解，今天我就说一下大家公认的整洁代码的规范
1.只做好一件事（每个函数、每个类、每个模块都全神贯注于一事，不受四周细节的干扰和污染）
2.可读性强
3.有单元测试
4.易于作者之外的人修改
5.代码尽量简单、少
6.没有重复代码
7.有意义的命名
1.6 童子军军规
代码必须时时保持整洁
1.7 前传与原则
在本书中，你会发现对不同设计原则的引用，包括单一权责原则（Single ResponsibilityPrinciple, SRP)、开放闭合原则(Open Closed Principle, OCP)和依赖倒置原则(Dependency Inversion Principle， DIP）等。
1.8 小结
本书会看到好的代码，也会有糟糕的代码，会学习到如何从糟糕的代码转换为好代码，要时刻保持、提醒自己，保持代码的整洁
