整洁代码之道 1 整洁代码

你是一个程序员，同时你想成为一个好的程序员

1.1 要有代码

1. 将需求明确到机器可以执行的细节程度，就是编程要做的事。而最终落实到机器上的东西，就是代码
2. 没有明确的需求，就没有精细的程序。你认为你要的那种 “五彩斑斓的黑” 是真是存在的？还是自相矛盾的？

1.2 糟糕的代码

1. 糟糕的代码会毁掉一个产品，甚至一个公司
2. 如果你告诉自己 “这个以后再来优化” ，那么这就是 “技术债务”，你大概率不会再有机会去优化它
   1. 勒布朗法则（ LeBalance ）：稍后等于永不（ Later equals never ）

1.3 混乱的代价

1. 随着混乱的增加，团队生产力也持续下降，趋向于零
2. 为了解决持续下降的生产力，领导会选择增加更多人手，或增加工作时间
   • 不论是两种方案的哪一种，都会导致生产力无限趋向于零

1.3.1 华丽新设计

1. 花时间保持代码整洁，不但有关效率，还有关生存

1.3.2 态度

1. 程序代码的最终崩塌，大部分责任还是应该归咎于程序员，是自作自受（ But the fault , is not in out stars , but in ourselves ）
2. 程序员遵从不了解混乱风险的经理的意愿，是不专业的做法

1.3.3 谜题

1. 你认为项目工期很紧张，所以没有那么多时间保持代码整洁，但制造混乱无助于赶上期限
2. 混乱只会立刻拖慢你，叫你错过期限
3. 做得快的唯一方法，是始终尽可能保持代码整洁

1.3.4 整洁代码的艺术

1. 能分辨整洁代码和肮脏代码，也不意味着会写整洁代码
2. 代码感 需要花大量时间不断培养，缺乏代码感的程序员，看混乱是混乱，无从着手
3. 编写整洁代码的程序员就像是艺术家，能用一系列变换把一块白板变作由优雅代码构成的系统

1.3.5 什么是整洁代码

1. 令人读起来愉悦的代码
2. 完善错误处理代码，在各种细节上花心思，防止 破窗理论
   • 窗户破损了的建筑让人觉得似乎无人照管，于是别人也再不关心
   • 他们放任窗户继续破损，最终自己也参加破坏活动，在外墙上涂鸦，任垃圾堆积
   • 一扇破损的窗户开辟了大楼走向倾颓的道路
3. 整洁的代码只做好一件事，让代码像是专为解决那个问题而存在
4. 代码应当讲述事实，不引人猜测
5. 测试驱动开发，没有测试的代码就不干净
6. 用人类可读的方式写代码
7. 整洁的代码看起来像是某位特别在意它的人写的
8. 减少重复代码，提高表达力，提早构建简单抽象

1.4 思想流派

1. 整洁代码之道的代码风格就像是武术流派多种多样
2. 本书中描述的风格是作者认为正确的，如果读者也觉得有益，则可以遵循其中教诲，练就如何编写整洁而专业的代码
3. 但绝不是说书中的风格就是完全正确的，洽洽相反的是，书中的很多风格存在争议，这些规范其实并没有一个最终权威

1.5 我们是作者

1. 每个代码中我们的角色，既是作者，亦是读者。作者有责任与读者做良好的沟通，所以我们需要对自己的代码负责
2. 你以为写代码的过程大于读代码的时间，所以把代码写的通俗易懂其实没必要
3. 但是你错了，其实在代码中，读与写的比例通常是 10:1
4. 写新代码时，我们一直在读旧代码，参考旧代码，所以为了写的快，就应该让代码更易读
5. 代码的读和写，是一个相辅相成的过程

1.6 童子军军规

1. 让代码比你来时更干净

1.7 前传与原则

1. 是 Software Development: Principles, Patterns, and Practices 的前传
   • 敏捷软件开发：原则、模式与实践
2. 读这本书的时候，这本敏捷软件开发在我的书单中，所以说来很凑巧的，我正确的选择了先读 “前传”

1.8 小结

1. 读艺术书并不能保证读过之后就能成为艺术家，但是会让你知道成为艺术家需要的工具、技术和思维过程
2. 在读本书的过程中，努力锻炼自己的 代码感 ，才是正确的学习方式