好代码的基本元素

前阵子看了电影《Up in the Air》，中文名是《在云端》。里面George Cloony有个著名的背包理论。用来安抚被裁的员工。其实这个理论用在GTD中也很有效果的。 上篇文章，说了GTD中最重要的两点的第二点。这次想说的是第一点收集。 执行GTD的开端就是收集，把你脑子里存在的任何事情都记录下载，存在一份叫做‘材料（Stuff）’的List里面。然后从中摘出来打算要做的，放入‘工作篮’中。 这一步其实也符合‘背包理论’，在这里你的大脑就相当于背包，如果你脑子里存在的事情太多了，导致背包超重，那么就没办法轻装上阵，被背包所束服，导致效率低下等等不良影响与情绪。写下来，无论是写到一张白纸还是电脑的Excel文档亦或是什么GTD软件，只要你把脑海中的一切写下来了。那么就相当于有个地方可以随时查阅到你原来存储在脑海里的事情，而你的大脑自然也就放心了，可以专心的一件事情一件事情的处理，而不必总在惶惶中度日。 而我想说的是，清空大脑是重要的第一步，接下来，还要想办法清空‘材料’和‘工作蓝’这两个list。你可以通过全部解决掉事情来清空，也可以通过别的方式。第一种方案，把所有事情做完，这在一定意义上是可行的，但现实中，一旦你的工作或生活到了一个量级，你就发现你真的是没办法做完所有的事情的，所以，更多时刻，我们可以考虑用别的办法清空或者尽量减少这两个list中item的数量。 保持‘材料’和‘工作蓝’中事项数量在一个尽可能小的范围是有好处的，因为人（特别是强迫症患者）总是会对数量敏感的，如果看到‘工作蓝’有上百个待做事项，肯定会对你情绪或多或少产生慌张或什么别的负面情绪。而如果‘材料’list中有着五页或者更多事项，那么你每天从中选取事项到‘工作蓝’本身都会成为一项很痛苦的事情。 所以，我们应该精简‘材料’、‘工作蓝’list。在清空大脑，把所有东西都放到‘材料’list之后，就应该review一边，把完全没用的，不重要的，不是事情的事情给删掉。如果这招会让你大脑又感到不安了，那就丢到一个叫做‘垃圾站’的list去，而且这个list应该是不需要关心的。这样子经常要看到的‘材料’list就一下子少很多事项了。每天晚上从里面挑选事项放入‘工作蓝’这个过程也就容易多了。 每天早上检查‘工作蓝’的时候，也要先快速review一遍，分类整理。按照自己做的/支配别人做的/需要别人配合的分成三类。先把后两项处理了。然后专心的再做自己应该做的。 这一步看起来简单，其实实施之后真的有很大的效果。举个例子：收到一封系统错误的邮件，流程是开发人员总是需要回复解释。这时候并不一定你直接回复了就好，根据错误的情况，你可能需要和小组成员协商，达成一致意见，有了详尽的描述和解决方案了再发，或者是应该直接交由你的上级或者以前约定好的外部接口发言人来处理。 总之，就是你只做你最应该做的并且能产生最大收益的事情，在一个完备的团队，程序员最重要的是写代码来正确的描述业务的需求，而测试的思路方法则是你的QA同事的工作重点，而线上的维护与更新则是运维团队的同事的工作重点。如果你在时间资源有限的情况下，过多的参与或者操额外的心在QA同事或者运维同事应该操心的地方，那么你自己的本质工作，写的代码自然就容易质量下降导致测试与部署更加费时费力。这就是越帮越忙的道理，团队就是为了每个人有明确的分工，才使得生产率提升的。如果你本末倒置，耽误了本行，程序写的不易测试，难以部署维护。哪怕你花再多的心思帮QA去测试，帮运维去升级，也是费力不讨好的。 你如果去登山，可能你的背包需要带上创可贴，可如果你就是下楼买包烟，还有必要带创可贴么，别开玩笑了，连背包都不需要拿着，光拿点零钱就够了。 所以，别着急塞满你的背包，让它里面尽量放的东西少一些，只有这样，当出现更重要的事情的时候，你才能轻易的放进来。而不至于超负荷运转。 程序员也是如此，你最重要的事情永远是写程序，不寻思着先把程序写到足够好，就花费精力在别的方面始终是不明知的。 程序正确，自然QA测试就轻松了。 程序扩展性好，自然你自己回头改起来就容易了。 程序容易部署，自然运维人员部署升级维护起来就简单了。 所以与其花费很多时间在教QA和运维怎么测试与部署你的程序，不如你先把程序写的足够容易的测试与部署更具性价比。 在我看来，重要的事情就是可以潜移默化的让你减少很多额外的大小事情大小麻烦的事情。 通过收集、整理、拚弃，不断的思考，最终使得to do list上存活的都是重要的事情。那么，就会形成一个良性循环，使得你的‘背包’越来越轻，从而跑的越来越快。