代码整洁之道--读书笔记(9)

代码整洁之道

简介:

本书是编程大师“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):如果你掉进了坑里,别挖。
  • 专业开发人员不会执拗于不容放弃也无法绕开的主意。他们会保持开放的头脑来听取其他意见,所以即使走到尽头,他们仍然有其他选择。

泥潭:

  • 比死胡同更糟的是泥潭。泥潭会减慢你的速度,但不会让你彻底停下来。泥潭会阻碍你前进,但如果使尽全力,你仍然可以取得进展。
  • 之所以说泥潭比死胡同更麻烦,是因为在泥潭中,你仍然可以看到前进的道路,而且看起来总是比走回头路要短(虽然实际不是这样)。
  • 在泥潭中继续前进的危害是不易察觉的。面对简单问题,你给出解决方案,保持代码的简单、整洁。之后问题不断扩展,越来越复杂,你则扩展代码库,尽可能保持整洁。
  • 走回头路看起来代价很高,因为要把已有代码推翻重来,但是走回头路绝对是最简单的方法。如果继续前进,系统就可能陷入泥潭,永远不得脱身。

结论:

  • 专业开发人员会用心管理自己的时间和注意力。他们知道优先级错乱的诱惑,他们也珍视自己的声誉,所以会抵制优先级错乱。
  • 他们永远有多种选择,永远敞开心扉听取其他解决方案,他们从来不会执拗于某个无法放弃的解决方案。
  • 他们也时刻警惕着正在显露的泥潭,一旦看清楚,就会避开。最糟糕的事情,莫过于看到一群开发人员在徒劳地拼力工作,结果却陷入越来越深的泥潭。