《代码整洁之道》
第一章 专业主义
1.1清楚你要什么
清楚自己负责的是什么，并为自己收拾残局
1.2 担当责任
自己写的代码要对它负责，如果有bug需要自己去负责，不要推卸责任。并且需要想清楚为什么会有这个bug，现在如何更好的解决这个bug，以及以后如何防止相同的事情发生
1.3 职业道德
- 需要了解自己的领域：必须精通设计模式、设计原则、方法（结构化分析、瀑布模型等）、实践（测试驱动开发、面向对象设计、持续集成）、工件（UML图、结构图）。
- 坚持学习：与时俱进，学习不同的语言
- 练习：歌手练习声音、医生联系手术缝合、音乐家练习音阶
- 合作：一起编程、一起计划、一起练习、一起设计、一起合作。也需要学会独处
- 辅导：辅导新人的同时自己也会受益
- 了解业务领域：如果不了解业务是写不出好的程序的，需要花时间去了解业务
- 与顾客保持一致：雇主的问题就是你的问题。必须弄清楚问题，并找到最佳解决方案。
- 谦虚：专业人士都知道自己也会摔跟头，不要因别人犯错了就对之横加贬损，因为自己很可能就是下一个犯错的人。如果遇到挫折最好的办法就是一笑而过，并在上面长个心眼
第二章 说“不”
能就是能，不能就是不能。不要说“试试看”。-- 尤达
2.1 对抗角色
竭尽所能的捍卫自身的目标，如果无法完成任务就要勇于说“不”，也要勇于对抗，不能为达目的不择手段。“为什么”远不如“事实”重要。为什么是一个细节问题。不能因为各种原因而去省略重要的步骤
2.2 高风险时刻
最要说“不”的时候就是那些高风险的时刻。越是关键时刻，“不”字就越具有价值
2.3 要有团队精神
有团队精神的人，不会永远说是。那些事情做得到，那些事情做不到一定要分清楚，做不到的事情一定要讲出来，不能自信过头。
- 试试看： 没有“试试看”这回事，尝试的意思就是“付出额外的精力”
- 消极对抗：一辆火车冲向大家，只有你一个人有所察觉，你可以选择自己轻轻抽身到马路边，眼睁睁看着其他人被车碾过，也可以选择大喊：“车来了，快离开”
2.4 说“是”的成本
大多数情况下，我们都希望说是。一个故事：部门招标1个月时间做一个系统，然后a公司中标了。b成员负责项目的开发，时间特别赶b成员同意做此项目。他没日没夜的加班，全部用硬编码方式完成了这个项目，自己还沾沾自喜的认为干了一件特别了不起的事情（项目开发期间还加了一些其他的功能）。结果之后部门来了个新领导砍掉了这个项目。
2.5 如何写出好代码
有可能写出好的代码吗？有可能坚守专业主义的精神吗？在项目特别赶的情况下就可以硬编码，不管设计原则吗？其实想要写出好的代码就需要学会如何说“不”。
第三章 说“是”
3.1 承诺用语
做出承诺的步骤
- 口头上说
- 心里认真对待做出的承诺
- 真正付诸行动
3.1.1 识别“缺乏承诺”的征兆
- 需要/应当：我需要减肥、有人应当负责某某事情
- 希望/但愿：希望明天能完成任务、但愿明天有时间
- 让我们：让我们把事情做完
3.1.2 真正的承诺是怎样的
我将在...之前...完成任务。
- 之所以没有成功，是因为我寄需求于某某去做这件事：比如这件事依赖于其他团队，这种情况应该提前就采取行动，提前预估风险
- 之所以没有成功，是因为我不太确信是否真正的能够完成：即使目标无法完成，你任然要不留余力的前进，离目标要更近一些
- 之所以没有成功，是因为有些时候我真的无能为力：遇到这种情况的时候要及时向承诺对象发出预警越快越好！
3.2 学习如何说“是”
- “试试”的另一面：试试意味着“仍然有余力可施”
- 坚守原则：彻底不要出现“如果...或许...”，也不要冒险放弃原则，比如不写测试用例等。专业人士对自己的能力极限了如指掌，清楚的知道如果保持效率的加班能持续多久，也明白要付出的代价
专人人士不需要对所有请求都回答“是”。不过，他们应该努力寻找创新的方法，尽可能做到有求必应。如果给出了肯定的回答，就要使用正式的承诺。
第四章 编码
4.1 做好准备
- 代码必须能够正常工作
- 代码必须能够帮助你解决客户提出的问题
- 代码必须和现有的系统结合的天衣无缝
- 其他程序员必须能看懂你写的代码
- 凌晨3点写出的代码：疲劳的时候千万不要写代码，要确保自己已经将睡眠、健康和生活方式调整到最好的状况
- 焦虑时写下的代码：焦虑的时候建议可以花点时间让自己安静下来，不要硬逼自己写代码，不然很容易写出以后不得不抛弃的代码
4.2 流态区
高效率状态会出现“绝无错误”的误区，这种状态会为了追求所谓速度，理性思考的能力会下降。建议可以结对编程
- 音乐：听音乐并没有帮助“我”专注编码，反而会消耗一部分脑力资源
- 中断：中断无法避免，发生这种情况的时候要想一下，自己也可能会去打扰别人，乐于助人的态度就是专注的态度。
4.3 阻塞
无法写出代码的时候建议结对编程会有意想不到的收获
- 创造性输入：广泛阅读各种资料来激励自己去创造
4.4 调试
真正调试的时候往往是大于编码的时间的，建议使用“测试驱动开发”可以有效的减少调试时间。医生不喜欢重新打开病人的胸腔去修复此前犯下的错误、律师不喜欢之前搞砸过的案子、写代码如果写的更多的是bug也是不专业的
4.5 保持节奏
知道何时应该离开一会： 当遇到问题感到疲倦的时候可以离开一会，调整一下精力后才会更好。
4.6 进度延迟
管理延迟的诀窍： 早期检测和保持透明
- 期望：如果计划的是12天开发周期，那么不要期望自己能10天完成，否则期望会导致大麻烦。不要让其他任何人对此抱有期望
- 盲目冲刺：快速冲刺是做不到的，要明确的告诉老板，让他们不要有这种期望
- 加班加点：如果没有加班失败的后备方案，建议不要同意接受加班方案
- 交付失误：明知道没有完成任务却说完成了任务
- 定义完成：要说清楚完成的情况，是代码编写完成了还是自测完成，还是对接完成了
4.7 帮助
- 帮助他人： 互相帮助是每个程序员的职责所在，要以能帮助他人为荣
- 接受别人的帮助：如果有人向你伸出援手，要诚挚接受，心怀感激的接受帮助并诚意合作。不要因为自己压力大而推开伸来的援手。
- 辅导：向深资导师寻求辅导也是程序员的专业职责
第五章 测试驱动开发
5.1 此事已有定论
TDD不仅仅是一种用于缩短编码周期的简单技巧。结论很清楚，每个开发人员都需要掌握TDD
5.2 TDD的三项法则
- 在写好失败的单元测试之前，不要写任何产品代码
- 只要有一个单元测试失败了就不要写测试代码了，无法通过编译的也是失败的情况
- 产品代码恰好能够让当前失败的单元测试代码通过即可，无需多写
5.3 TDD的优势
- 确定性： 代码有任何修改，都需要运行全部测试
- 缺陷注入率：有不少研究称TDD能显著降低缺陷
- 勇气：看到有坏味道的代码就可以马上修改，是TDD给你的勇气
- 文档：单元测试就是文档，每个单元测试都是一个调用示例
- 设计：遵循三项法则能够产生一种驱动力，促使你做出松耦合的设计
5.4 局限
在某些情况下的三项法则是不切实际的，这种情况很少，如果弊大于利就不要使用它
第六章 练习
6.1 引子
没门编程语言都它的hello world。这也是第一个练习，练习能够带来协调的开发节奏。无论是搏斗还是编程，速度都来源于练习
6.2 编程柔道场
- 卡塔：类似于编程小游戏，训练自己
- 自由练习：不限制形式的搏击
6.3 自身经验拓展
- 开源：可以在开源网址上去贡献代码
- 练习的职业道德：不要在上班的时候进行练习，老板的职责不包括避免你的技术落伍
无论何时，专业人士都需要练习。
第七章 验收测试
7.1 需求的沟通
- 过早精细化：经常愿意花大代价追求这种不现实的精确性
- 不确定原则：需求完成的越精细，就越容易被忽视。业务想看到和开发看到的不一致
- 预估焦虑：需求是一定会变化的，追求精确性是徒劳的
- 迟来的模糊性：需求的不确定性会让开发和测试都搞错需求
7.2 验收测试
- 完成的定义：不同的团队的完成的定义是不相同的
- 沟通：验收测试的目的是沟通、澄清、精确化。开发方、业务方、测试方都要达成共识
- 自动化：验收测试都应该自动进行，手动执行的都要考虑成本
- 额外工作：大量的测试用例不是额外的工作，只有确定了细节指标才可以避免开发误入岐途
- 验收测试什么时候写，由谁写：通常会交给业务分析人员、QA或者开发人员。如果是开发人员尽量不让写代码的人和开发的人是同一个人
- 开发人员的角色：开发人员有责任把验收测试与系统联系起来，让测试通过
- 测试的协商与被动推进：测试也是普通人，也会犯错误。如果发现测试用例有问题要及时沟通改进
- 验收测试和单元测试：验收测试是业务方写给业务方的。单元测试是程序员写给程序员的。
- 图形界面及其他复杂因素：尽可能减少GUI测试，GUI测试越多后期维护的难度就越大
- 持续集成：持续集成不应该失败，如果失败了团队所有人应该都要停止干活，先让测试先通过
第八章 测试策略
8.1 QA应该找不到任何错误
开发小组应该把【QA找不到任何错误】当成努力的目标
- QA也是团队的一部分：他是团队中需求定义者和特性描述者
- 需求规约定义者：编写针对极端情况、边界状态、异常路径的测试
8.2 自动化测试金字塔
人工探索式测试 > 系统测试 > 集成测试 > 组件测试 > 单元测试
- 单元测试：程序员自己编写的测试，应该要接近100%的覆盖率，通常要达到90%以上
- 组件测试： 针对系统的各个组件编写的，封装了业务规则（QA 和业务人员编写）
- 集成测试：对组件很多的大型系统才有意义
- 系统测试： 对整个集成完毕的系统进行的自动化测试包含吞吐率和性能测试等
- 人工探索式测试： 确保在人工操作下表现良好，同时有创造性的尽可能多的找到“古怪之处”
第九章 时间管理
9.1 会议
公认：会议是必须的、会议浪费了大量的时间
- 拒绝： 理智的使用时间，谨慎的选择需要参加的会议，礼貌的拒绝一些不必要的会议
- 离席：如果你明白继续待在会议室会浪费时间可以找合适的机会商量如何离席
- 确认议程与目标：务必弄清楚议题是什么，花多长时间，取得什么成果
- 立会：每个人回答不超过1分钟（昨天干了什么，今天打算干什么，遇到了什么问题）
- 迭代计划会议：会议的节奏要快，每个任务应该限制在5-10分钟之内，如果不够应该另选时间专人专门讨论
- 迭代回顾和demo展示： 看最新的工作成果的demo可以在最后一周的最后一天下班前45分钟召开，前20分钟回顾，后25分钟展示
- 争论/反对：如果观点无法在5-30分钟之内达成一致，就永远无法达成一致，出路是用数据说话
9.2 注意力点数
注意力是稀缺的资源如果注意力用光了需要1个小时或更多的时间去补充，可以在注意力不够的时候做其他事情。
- 睡眠：充足的睡眠可以保证好的注意力
- 咖啡因：适当的咖啡可以保持注意力
- 恢复： 注意力耗尽可以自己沉思一会，或者小睡一会
- 肌肉注意力：转移注意力到肌肉注意力上面可以提升心智注意力
9.3 时间拆分和番茄工作法
给自己设定25分钟，25分钟之内无论什么干扰都需要在25分钟之后在处理，没4个番茄时间段之后休息30分钟
9.4 要避免的行为
专业开发人员会评估每个任务的优先级，排除个人的喜好和需要，按照正式的紧急程度来执行任务
9.5 死胡同
比如选择了走不通的技术道路越是坚持浪费的时间就越多，专业的开发人员会保持开放的头脑来听取其他意见 ，即使走到尽头，他们仍然有其他选择
9.6 泥潭
专业人员时刻留意显露出来的泥潭，然后各种努力，尽快脱身。在泥潭中继续前进时不易察觉的，要及时修正设计。
第十章 预估
10.1 什么是预估
开发认为预估是猜测，业务认为预估是承诺
- 承诺：如果你承诺某事，就必须按时完成，不兑现承诺就是一种欺骗
- 预估：它不包含任何承诺
- 暗示性承诺：试试看就是暗示性承诺，尽量不要使用
10.2 PERT
一种避免乐观的项目估计的合理方法
10.3 预估任务
一组人集合起来重复进行讨论-预估的过程，直到意见统一
- 亮手指： 统计大家树起的手指进行精细预估
- 规划扑克：用成员的扑克点数进行预估
- 关联预估：任务写在卡片上按照规则进行预估
- 三元预估： 用三种预估得出概率分布的一种方法
10.4 大数定律
把大任务分成多个小任务，分开预估在加总，结果会比单独评估大任务要准确很多
第十一章 压力
11.1 避免压力
- 承诺：如果没有兑现承诺导致业务失败的压力
- 保持整洁：代码设计的整洁可以避免压力，混乱会降低速度，导致工期延误、承诺失信
- 危机中的纪律：当困境降临时，不要改好的行为。如：赶工期的时候要保证代码质量
11.2 应对压力
- 不要惊慌失措：放松下来，多想一下问题，努力寻找就会带来好的结果
- 沟通：请求团队其他成员或者主管，避免产生惊恐
- 依靠你的纪律原则：战胜压力的方式就是依靠你已经知道的切实有效的东西-纪律
- 需求帮助：结对编程可以制止你的精神错乱
第十二章 协作
12.1 程序员与人
- 程序员与雇主：要端正态度，准守规章制度
- 程序员与程序员
- 代码个体所有：自己的代码自己维护和其他同事不沟通，拥有大量重复的代码
- 协作性的代码共有权：打破隔断，相互合作
- 结对：结对编程是复查代码最好的方式
一定要学会交流--和大家交流
第十三章 团队与项目
13.1 只是简单混合吗
- 有凝聚力的团队
- 发酵期：一起计划、一起解决问题、一起面对问题、一起搞定一切
- 团队和项目，何者为先：专业的开发组织把项目分配给有凝聚力的团队
- 如何管理有凝聚力的团队：可以给团队设置目标值
第十四章 辅导、学徒期与技艺
软件学徒期
- 大师：一般拥有10年以上的从业经验，他们懂得如何领导和协调多个团队，他们是熟练的设计师和架构师
- 熟练工：能胜任工作，并且精力充沛，他们会学习如何在团队中卓越的工作和成为团队的领导者
- 学徒/实习生：刚开始进入自己的职业生涯，他们需要熟练工的督导。他们应该至少持续一年的实习期
技艺中包含着价值观、原则、技术、态度、正见。工匠知道何时该说不，他们懂得如何做出承诺，成熟的工匠才能算是专业人士。