由漫画《Leave me alone ! 程序员怎样度过他的一天

写这篇文章的想法起源于女朋友微信发来的一个分享——漫画《Leave me alone ! 程序员怎样度过他的一天？》，她还附上简简单单的问句：你每天都是这么过的么？

相信程序员朋友们多多少少对漫画中程序猿主角的一天经历都有所熟悉，甚至于长啸一声道：这就是我啊！我们程序猿都是这么敬业！就是这么忙！

但我回了女朋友一个大写的“并不是啊！”。为什么呢？首先，文艺创作嘛，肯定会把工作中的一些经典场景提炼升华了。漫画中的一些场景并不会每天重重复复的上演。其次，漫画中的一天是很理想化的一天，基本上程序猿都会经历一些更狗血更刺激更有趣的时刻。在此，希望作者能再接再厉画出更多我们程序猿的心声。

然后，我陷入了思考：假设漫画中的主人公的一天是真的就是这样（注意，我并不是说漫画中的人物经历是假的，相信程序员们经历过类似的事情，只是说这些经历恰好组成了他的这么一天），那是什么原因造成了他会如此的“苦逼”，有什么方法可以改进他的码农生活么？

让我们试着进入主人公的虚拟生活，并试着分析一下：

对于主人公这种每天8点半起床，9点出门，10点到单位的生活，笔者表示十分羡慕！！

很经典的开局，召唤师钢琴手单中，出门带邮箱、git、机械键盘、早饭……

程序员是什么？喝下咖啡，挤出代码的生物啊！没有咖啡怎么行？！摔！

等等，什么？要开早会了？好吧，让我准备一下。

早会（我们称为Standup站会）已经是大多数公司的每日例行活动，在这里我的建议是在开早会前，程序员不应该马上着手于coding，而是打开你的看板工具Trello、Tower等（什么？你们公司并没有使用这些工具？好吧，你应该试着了解一下，相信我，你会喜欢上的），把卡墙速速游览一遍。这样做的好处有三：

• 不只是对昨天自己工作的一个回顾，也能了解到团队中其他人工作内容。
• 可以对今天的工作任务心里有数。
• 每人都做好准备，快速地总结发言，可以大大缩短早会的时间，更早地投入实际的工作。笔者曾经在一个10人（6人国内，4人国外）的团队，每天的standup还包含了每人必须发言的随机趣味问答，但整体时间却能控制在25分钟内完成。这是由于每个人都提前做好充足的准备。

至于早会的具体内容形式，那真的是见仁见智。各位可以根据团队的具体情况来制定。但有两点要注意的是：

• 早会的目的在于快速地总结昨天的工作，并对今天的工作作出规划。但凡出现需要消耗较大量时间讨论的问题，例如文中的大家提出建议和需要提供何种配合，应该另外规划出时间召集相关人员（而不是所有人）来进行深入讨论。
• 开早会竟然想订早饭？Excuse me？！这也太不专业了吧？拜托，与会人员的用心程度直接决定了会议的价值。如果开会没有意义，那跟咸鱼有什么区别？当然了，我相信作者在这里只是为了漫画效果这样写的，所以请不要上纲上线。

我们接着看：

程序猿中午的真实写照，给漫画作者一个大大的拥抱（亲人啊）！

赶紧赶忙处理完杂事后，终于可以开心的coding了，却……迎来了产品经理！

跟产品经理互相扯皮的事情，相信大多数程序员都有遇到。很多时候两方简直是鸡同鸭讲，恨不得把对方脑子掰开将口水直接灌进去。这是程序员开发中面临的一大难题：沟通成本。我曾经问过一个有10年以上编程经验的外国同事：你在编程中遇到的最大困难是什么？他想了会，答道：与人的沟通。电脑对输入会有直接的输出，但人不一样，我遇到的很多人在很多时候并不知道他们真正想要什么。

这反映出两点：

• 任务制定者（PM）可能对于某项任务（输入）能产生的效果（输出）并没有完全知悉，甚至对应不应该启动这个任务都没有考虑清楚。
• 任务完成者（Dev）可能对某项任务的启动原因、实现手段和最终效果会有误解。

所以，我们需要扯皮。

但这能解决沟通问题吗？大多数情况下，能，PM与Dev在大量消耗的时间和精力成本后，互相妥协，最终是能够达成一致。但双方所付出的成本上昂贵的，也是可耻的。如果有人能缓解这种状况，我想最好的选项中肯定会有BA（Business Analyst）

BA能在PM（或者客户）和开发人员中架起一道沟通顺畅的桥梁。一方面，他能帮助PM（或者客户）对某个将要启动的任务进行分析（有无必要启动，对整个业务线的影响，谁会是最合适的开发人员等等），另一方面，他能给开发人员制定出具体可执行的细分任务（拆分大任务成几个小任务，阐述清楚要求达到的效果和标准，完成时间等），让开发人员能专注进行coding这项本质工作。当然，制定任务计划并不会完全脱离开发人员，但引入了BA的角色，开发人员的效率会得到很大的提升。

我们继续：

不同技术组之间确实会发生这种看不懂，不会用别人组代码的事情。而这时候，统一的编程规范、表意的函数名和类名、表意的测试、完善的文档、充满善意并描述清楚的邮件会是你可靠的小伙伴。

可乐！我说怎么能没有可乐。好吧，6点的时候，终于完成了Todo List上第一个任务。但是我想下班了……

自己写代码多没劲呀，不如下次试试pair？

这确实挺烦人的。如果程序员能在实现之前写好测试，会被QA回头找的概率真的会减少。TDD（测试驱动开发）好不好，该不该用，真的是见仁见智。但是在我的经验范围内，它确实是一个良好的实践。

临时修bug是经常的，所以git和测试绝对是你的好伙伴！

女朋友快没了……

论在家里路由器上配vpn的重要性

深夜提交是可以的，但要记得用pull request哦！而且大半夜的就不要merge了，不然自动部署后，谁都不知道会不会产生bug，到时你就别想睡了。

还有，一整天过去了，竟然没有code diff（或者code review）？！不开心啊，code diff绝对是提升自己代码水平和业务水平的绝佳方式。试问，一群人围着你的代码，不断的涌现出WTF，你能不用心写好自己的代码吗？

就这样，程序员的一天就过去了。

写在最后

写这篇文章并不是对作者提出异议，相反，我觉得作者是一个真正很用心在工作并且愿意分享的coder。相信作者肯定还有很多想写但限于篇幅等原因没有写出来的场景，期待他的下一部作品。