这部书老早的都该翻完了，结果因为各种的使其overdue。另外，关于这本书，实际上并不是《代码整洁之道》，二更是偏向于后面的程序员职业修养的部分。其中的内容呢，更多的是作为工作中的“指南手册”。让我想到前面的一本书《时间管理–写给系统管理员》，里面写的是在工作时候的事情处理，以及一些情况的应对。
所以，这篇文章给这本书收个尾。
书的前言
书的前言，使用“挑战者”号的失事事件为引子。陈述了在一个巨大体系中的管理的问题。由于管理人员自已以为自己是专业人士，忽略工程师一次又一次的警告和建议。这些问题的一点又一点的积累最终导致了这灾难的发生。
即使工程师们早就知道这种问题的存在，最后还是没有改变结果。管理人员心存侥幸，希望一切相安无事，认为自己才是专家，他们的恐慌，希望，直觉才是准的。刚刚好遇上现在的《Chernobyl》，一个个的错误，导致了灾难。
遇到不合理的事情，需要及时的质疑，不能因为自己心中所想的“他是专业人士”来默默的吞掉疑问，无条件信任。一个专业人士的态度不应该是：“我们尽力而为吧”。而会以“这是我们的承诺，如果你想调整，请随时联系我们”。
如何变得专业
去承担责任，不要破坏代码的结结构，代码本身的结构要；可能的灵活，避免代码结构的僵化。
不能铭记过去的人，注定要重蹈覆辙。
坚持学习，不断涉猎新的技术。另外，没事的时候可以做做Kata来练练脑子。
同意或拒绝
这个在前面那本时间管理的书里面又提到过的。
能就是能，不能就是不能。不要说‘试试看’。
奴隶没有权利说不。但是专业人士应该懂得说不。事实上优秀的经历总是对敢于说不的人求贤若渴。敢于说不，才能真正做成一些事情。因为试试看是一句模糊的话，一方有着百分之八十的期待，一方只有百分之二十的把握，这样往往会导致，“还没完成？”，“还需要些时间”这种灾难性结果。
当无法明确完成的时候，和经理确定最低的可能的期望功能。所以，敢于说不。
作出承诺包含三个步骤：口头上说自己将会去做，心里认真对待作出的承诺，真正的付诸行动。书里面写了很多的有趣的场景：
- 问“为什么网络这么慢”，回答“我们是得再弄点路由器了”
- 老板说：“我们进度需要快点”，“好”我们总会有器官的感觉，觉得大多数的时候他们并没有全力去兑现呢？在这些承诺里面都有给自己开脱的词汇：“需要/应当”，“希望/但愿”，“让我们”。
尽可能地使用正式承诺，确保各方能无误地理解承诺地内容。
编码的技巧
关键在于具备信心，和出错感知能力。
代码需要：
- 能工作
- 解决客户问题
- 和系统结合
- 代码易读
在心烦意乱的时候，千万不要敲代码！。
中断的恢复，结对工作，或者是使用TDD，来进行开发驱动。
不要对十天之内全部完成特性开发抱有任何期望，这种期望有可能杀死整个项目。
测试驱动开发
使用TDD，Java有了30秒一次的运行周期。使用测试样例来控制正确需求。TDD的确可行，此时已有定论，争论已经结束。
TDD的三个原则
- 编好失败单元测试之前，不写产品代码。
- 一个单元测试失败了，就不要写测试了。来解决它先
- 产品代码恰好让当前的失败通过即可。
需求沟通
很多时候，出现了过早的精细化和过迟的模糊性，前者指的是过早的精确后面要得到什么，使得一味的向目标靠近反而浪费了成本。过迟的模糊化导致在最后需求已经被完成后不符合单方预期，导致需求双方的分歧。
时间管理
番茄工作法
拒绝杂事
适时离席
项目立会，每天一个会议，每次不超过十分钟。“昨天干了什么，今天打算干什么，遇到什么问题”。
凡是不能再五分钟内解决的整论，都不能靠辩论解决