Clean Code第一章：整洁代码 －－阅读与讨论
由 尼克徐 发布于 2015年10月10日 ｜ 更新于 2015年10月13日tinyfool xieweizhi007 cleanclear 等3人欣赏。
这一章，我觉得主要写的是四个方面：
1， 整洁代码（Clean Code）的动机
2， 整洁代码也是态度问题
3， 整洁代码的标准
4， 简略介绍了怎样才能写出整洁的代码。
一， 整洁代码(Clean Code)的动机
咱么大都是男同志，不爱收拾屋子可以，但代码一定要整洁！原因是：
1， 乱七八糟的代码使得代码维护成本升高，最后到难以承受的程度。
做工作久了，见到各种乱七八糟的代码，有时读一遍就后悔接这个活儿，然后我们就强烈要求重做一遍。
模糊不清的函数名变量名，除了本人就看不懂的算法（黑话一样），不注意模块藕合度导致的动一处整个应用崩溃，胡乱定义全局变量，面条汤一样的，上千行的if else......都够够的了。
2, 糟糕的代码“引诱”开发者加入更多的糟糕代码
破窗理论说的就是这个，越是糟糕的无人照管的代码，开发者上手做时，也可能就更不关心代码的整洁度，从而加入更多的糟糕代码，使得情况更糟。
3，糟糕代码的恶性循环
已存在的糟糕代码->拖后继开发者后腿->期限压力下，制造更多的糟糕代码->已存在的糟糕代码更糟糕了->...
打破此恶性循环的关键在于，制造新的糟糕代码，无助于赶上期限，做的快的唯一办法，是始终保持代码整洁。
二，糟糕代码，也是你我的责任
代码整洁不整洁，也是态度问题。
长期以来，包括我在内的开发者，经常会以项目时间紧张，或者是项目经理不关心为由，不去写整洁代码。
Clean Code此书的作者告诫，代码糟糕不要总是怪罪外界，需要从自身找原因。
书中举了个例子，如果是医生，能不洗手就上手术台，然后这是说为了赶进度吗？
所以，代码糟糕，不能只埋怨其他的人，其实更是我们的责任。
我们需要参与进项目的规划过程，需要坚持自己的整洁代码的观点，与项目经理多沟通，象医生坚持自己的卫生标准一样。
读书读到这里，我觉得自己有必要写个关于整洁代码的ppt, email给我们团队全体成员。
当然，此书读完后写这个ppt时，内容更会充实些。
当然态度嘛也要谦虚谨慎啦。
三，整洁代码（Clean Code）的标准
综合各家之言，Clean Code有以下特征
好的代码，其代码逻辑直接了当
减少依赖关系，便于维护
分层维护错误处理
如同优美的散文（！！！惭愧的我无力面对）
代码块越小越好（小就是美）
性能上已经优化到一定程度，不需要再优化了。
人类可读，容易理解。
减少重复，尽量抽象相似逻辑中的共同的元素和方法，封装起来被调用。
童子军军规：“让营地比你来时更干净”(Leave the campground cleaner than you found it.)，让项目随着时间的流逝，越变越好吧！
总体而言，整洁的代码，那各处完美的细节和精心的设计，读时能感觉到作者的精心呵护和着力的照料。他们在意这些代码（走心的代码...)
四，怎样才能学会写整洁代码
1， 能分辨整洁代码和肮脏代码。
2， 遵循大量的技巧，贯彻刻苦习得的“整洁感”（代码感）
有”代码感“的程序员，能从混乱中看出可能与变化，帮助程序员选出最优方案，制定重构计划。
这一章有几个问题可以探讨一下：
1， 大家写整洁代码的动机强吗？进度很紧张时，是否能坚持？
2， 怎样说服项目经理支持整洁代码？
3， 整洁代码的标准和规范上，各位所在的公司有什么样的规定？如何执行？
如何加入Root Cause读书会：请加我的微信brainstudio,我建立了一个群，方便通知各位写读后感及讨论。
最近在做一个C++项目的重构，发现有下列几个问题让我很难受：
- 有的一个文件18000行（Xen的核心代码也就18000左右）
- 一个函数1153行，期间充斥了大量废弃的接口和大量的if...else语句
- 接口升级的时候就是在原名称后面加个New
- 接口的返回值处理，有的是放在当前函数中，有的是另起一个函数，风格不一致。
总得感觉是，这东西居然能用，也是很不容易。
上述是吐槽脏的代码，针对楼主提出的问题分享下我的观点：
- 我刚工作不久，团队里对代码整洁度要求应该是中等：有code review，有风格规定。我自己也有很强的代码洁癖，举个例子来说，昨天review自己的代码的时候我主要改三个点：变量命名、字符串自动换行（Java版：Google Java风格指南）；进度紧张的时候，只能是尽量坚持，类似于本书提到的“童子军军规”：保证每次commit的质量。
- 怎么说呢，这种说服肯定不是在项目开发很紧张的时候说两句就起作用的，在日常的每次开发和讨论中就应该挂在嘴边……重要的事情要一直说（我们自己要散发出“代码洁癖”的气味，也许能影响到其他队友吧）。话说我昨天转正谈话的时候还提到我们团队应该在项目开始之前先规定基于本项目的变量命名规则、字符串处理规则（toString的形式）、类注释的问题……能转正不容易。
- 我们团队的代码规范是跟着Google Java规范走；以我目前看到的，执行方法有下面三种：（1）入职的时候师傅会给一份团队的代码规范来学习；（2）平时普通的代码，commit之后会有导师review；（3）一些关键模块的代码，会在周会上大家一起review。
今天对自己的一部分代码做了重构，发现做的最多的是下面几个操作： （1）减少重复代码——继承、函数抽取； （2）公用的代码在继承体系中上移； （3）公用的步骤在继承体系中上移——模板模式； 至于重构的时机，这个看个人的时间安排和项目进度，尽早重构是最好的，没有一次就写好的代码，慢慢来，用心嘛
“整洁的代码” 这件事，其实跟编程语言选择关系很大，虽然什么语言都可以写出整洁的代码，但是难度和可以达到的程度是不同的。
比如说ios， swift 比起objective－c来说，写整洁的代码要容易得多。 同样的F#比C# ， Clojure比Java更容易写出整洁的代码。
代码的各种规范只是个及格线，还远远不够。