代码整洁之道
简介：
本书是编程大师"Bob 大叔"40余年编程生涯的心得体会的总结，讲解要成为真正专业的程序员需要具备什么样的态度，需要遵循什么样的原则，需要采取什么样的行动。作者以自己以及身边的同事走过的弯路、犯过的错误为例，意在为后来者引路，助其职业生涯迈上更高台阶。
本书适合所有程序员阅读，也可供所有想成为具备职业素养的职场人士参考。
第九章 时间管理
8小时其实非常短暂，只有480分钟，28800秒。身为专业开发人员，你肯定希望能在这短暂的时间里尽可能高效地工作，取得尽可能多的成果。有什么办法能确保不浪费这宝贵的时间呢？怎样才能有效地管理时间？
9.1 会议
关于会议，有两条真理：
（1）会议是必需的；
（2）会议浪费了大量的时间。
专业开发人员同样清楚会议的高昂成本，他们同样清楚自己的时间是宝贵的，他们同样需要时间来写代码，来处理日程表上的事务。所以，如果会议没有现实且显著的成效，他们会主动拒绝。
拒绝：
邀请你参加会议的人并不负责管理你的时间，为时间负责的只有你。所以，如果你收到会议邀请，务必确保出席会议可以给自己目前的工作带来切实且显著的成效，否则不必参与。
有些会议是关于你已经完成的某些事项的，对目前的工作并没有现实意义。这时候，就应当权衡自己项目的损失与他人的收益。这话有点儿不中听，但你理应把自己的项目摆在最重要的位置。
还有些时候，有职权的人（比如其他项目的高级工程师或者主管）命令你必须参加某些会议。这时候应当问问自己，他们的职权是否比自己的工作计划更重要。同样，自己团队的同事和领导也可以帮忙决策。
离席：
这些年来，我学到了一条简单规则：如果会议让人厌烦，就离席。
重要的是，你应当明白，继续待在会议室里是浪费时间；继续参加对你没有太多意义的会议，是不专业的行为。因为你有责任合理分配老板给你的时间和金钱，所以，选个合适的机会商量如何离席，并非不专业的做法。
如果确实需要开会，确定议程与目标：
- 如果收到会议邀请，务必弄清楚指定的议题是什么，每个议题花多长时间，要取得什么成果。如果得不到确切的答案，你可以礼貌拒绝。
- 迭代计划会议： 迭代计划会议用来选择在下一轮迭代中实现的开发任务。在会议召开前必须完成两项任务：**评估可选择任务的开发时间，确定这些任务的业务价值。**如果组织得足够好，验收/组件测试也应当在会议召开前完成，或者至少要有概略方案。
- 迭代回顾和Demo展示：这类会议在迭代的末尾召开。团队成员讨论本轮迭代中什么做得对，什么做得不对。如果组织不当，这类会议可能浪费很多时间，所以不妨在最后一天下班前45分钟召开。花20分钟来回顾，花25分钟来演示。请记住，这类会议只牵涉到最近一两周的工作，所以没有太多内容要讨论。
- 争论\反对： ***凡是不能在5分钟内解决的争论，都不能靠辩论解决。**争论之所以要花这么多时间，是因为各方都拿不出足够有力的证据。所以这类争论依据的不是事实，而是信念。
- 如果观点无法在短时间（5～30分钟）里达成一致，就永远无法达成一致。唯一的出路是，用数据说话。
- 在争论中如果你同意对方的结论，就必须拿出行动来。
- 要小心这类会议：它们的目的是发泄情绪，或者让大家站队。如果会议上只有一面之词，就要避免参加。
- 如果争论必须解决，就应当要求争论各方在5分钟时间内向大家摆明问题，然后大家投票。这样，整个会议花的时间不会超过15分钟。
9.2 注意力点数：
- 编程是需要持续投入精力和注意力的智力活动。注意力是稀缺的资源，它类似魔力点数[2]。如果你用光了自己的注意力点数，必须花一个小时或更多的时间做不需要注意力的事情，来补充它。
- 职业开发人员会学习安排时间，妥善使用自己的注意力点数。我们选择注意力点数充裕的时候编程，在注意力点数匮乏时做其他事情。
- 注意力点数也会随时间流逝而减少。如果不及时使用，它就会消失。会议之所以具有巨大的破坏力，原因之一就在于此。如果你所有的注意力点数都用在了会议上，编程时就大脑空空了。
- 忧虑和分心也会消耗注意力点数。昨天晚上的夫妻吵架，今天早上的汽车剐蹭，上周忘记付款的账单，都会迅速耗光你的注意力点数。
睡眠：专业开发人员会安排好他们的睡眠，保证清晨有饱满的注意力点数去上班。
咖啡因：毋庸置疑，对有些人来说，适量的咖啡因可以帮他们更有效地使用注意力点数。但是请小心，咖啡因也会给你的注意力添乱。
**恢复：**一旦注意力点数耗尽，你就没法控制注意力。你仍然可以写代码，但是多半需要第二天重写，或者在几周或几个月之后备受这段代码的煎熬。所以，更好的办法还是花30到60分钟来换换脑子。
**肌肉注意力：**肌肉注意力有助于改善心智注意力，而且不仅仅是简单的恢复。我发现，定期训练肌肉注意力，可以提升心智注意力的上限。
9.3 输入与输出
关于注意力，我知道的另一重点是平衡输入与输出。编程是一项创造性劳动。我发现，如果能接触到其他人的创造性思维，我的创造力也最旺盛，所以我阅读大量的科幻小说。这些作者的创造力会激发我对软件的创造力。
时间拆分法和番茄工作法：
把厨房用的计时器（通常它的形状很像番茄）设定到25分钟。倒计时期间不要让任何事情干扰你的工作。如果电话响了，接起来并礼貌告诉人家，请在25分钟之后打来；如果有人来打断你问问题，礼貌地问他是否能过25分钟再来问。无论什么干扰，都必须等到25分钟结束再处理。
毕竟，几乎没有事情会紧急到25分钟都等不了。计时器响的时候，停下手上的工作，转去处理这25分钟内遇到的其他事情。之后休息5分钟左右。然后，再把定时器设定为25分钟，开始一个新的番茄时间段。每完成4个番茄时间段时间，休息30分钟左右。
9.4 要避免的行为
有时候你工作时会心不在焉。很可能是因为要做的事情让人恐慌、难受，或者厌烦。你可能会认为，工作是你被迫面对的，自己无从脱身。或者，你就是不喜欢这份工作。
**优先级错乱：**无论什么原因，我们都可以找到办法逃避真正的工作。你说服自己有些工作更紧急，所以转去处理，这种行为叫作优先级错乱------提高某个任务的优先级，之后就有借口推迟真正急迫的任务。
优先级错乱是自我麻醉的谎言，因为不能面对真正需要做的事情，所以我们告诉自己，其他事情更重要。我们知道这不是真的，但还是用它来欺骗自己。
死胡同：
- 所有软件开发者都要遇到死胡同。比如你做了决定，选择了走不通的技术道路。你对这个决定越是坚持，浪费的时间就越多。如果你认为这关系到自己的专业信誉，就永远也走不出来。
- 在走入死胡同时可以迅速意识到，并有足够的勇气走回头路。这就是所谓的坑法则（The Rule of Holes）：如果你掉进了坑里，别挖。
- 专业开发人员不会执拗于不容放弃也无法绕开的主意。他们会保持开放的头脑来听取其他意见，所以即使走到尽头，他们仍然有其他选择。
泥潭：
- 比死胡同更糟的是泥潭。泥潭会减慢你的速度，但不会让你彻底停下来。泥潭会阻碍你前进，但如果使尽全力，你仍然可以取得进展。
- 之所以说泥潭比死胡同更麻烦，是因为在泥潭中，你仍然可以看到前进的道路，而且看起来总是比走回头路要短（虽然实际不是这样）。
- 在泥潭中继续前进的危害是不易察觉的。面对简单问题，你给出解决方案，保持代码的简单、整洁。之后问题不断扩展，越来越复杂，你则扩展代码库，尽可能保持整洁。
- 走回头路看起来代价很高，因为要把已有代码推翻重来，但是走回头路绝对是最简单的方法。如果继续前进，系统就可能陷入泥潭，永远不得脱身。
结论：
- 专业开发人员会用心管理自己的时间和注意力。他们知道优先级错乱的诱惑，他们也珍视自己的声誉，所以会抵制优先级错乱。
- 他们永远有多种选择，永远敞开心扉听取其他解决方案，他们从来不会执拗于某个无法放弃的解决方案。
- 他们也时刻警惕着正在显露的泥潭，一旦看清楚，就会避开。最糟糕的事情，莫过于看到一群开发人员在徒劳地拼力工作，结果却陷入越来越深的泥潭。