程序员的一天到底在干什么？

程序员一天会干很多事情。

这些事情可以分为两类：理想情况下干的事情，以及不理想情况下干的事情。

早上8:50，程序员小张走进办公室，坐到自己的工位上。他是工作起来很认真负责的那种人。

他做的项目，是程序员梦想中那种理想的项目。

他的这一天，是理想工作状态中的一天。

等我先把理想的情况讲完，再说不理想的情况。

9:00 开站会。每个人都向其他人，简短地汇报昨天的工作和今天的计划，还有碰到的障碍

他打开电脑，看了一下今天的日程安排。

因为每天早上9:00有10分钟的站会，所以他开始简单地回顾昨天的工作和今天的计划。

9:00 开站会。开发小组有3位后端开发，1位前端开发，1位测试，1位业务分析人员，外加1位项目经理。

小张是后端开发。

这7人，来到一个看板前，开了10分钟的短会。

每个人都向其他人，简短地汇报昨天的工作和今天的计划，还有碰到的障碍。

每个人顶多讲1分钟。

9:10 小张在看板上，把代表自己当天工作的卡片，移动到TODO那列。

他今天有两个工作。一个是修复测试人员发现的一个bug，另一个是完成业务分析人员编写好的一个新的软件功能。

他把其中代表那个bug的卡片，移动到DOING那列，表示他上午打算修复bug。

9:20 小张开始修复bug。他先设法重现了bug，然后思考修复方案。

之后他喊测试人员过来，澄清了有关这个bug的疑问，并讨论了检验这个bug是否修复好的验收标准。

一切都搞清楚了，他开始修复。

这个bug看起来比较好解决。半个小时后，他就修复好了。

他首先自己测试了一下。在确认已经修复好后，他喊附近的测试人员过来看一下。

9:50 测试人员走过来，看小张为她演示修复后的bug。

测试人员提了一点改进的意见。

10:00 小张根据测试人员的反馈，又改进了bug的修复。

再喊测试人员过来看一下。测试人员很快过来看了一眼，说很好，你提测吧。

10:10 小张把修复好的bug的代码提交到版本库，并开始观察自动触发的持续集成流水线上的自动化测试是否运行正常。

10:15 今天有点不走运，流水线报警，说他为修复bug所写的代码，让其他功能的自动化测试运行失败。

他于是开始修复这个问题。

他看了一下出错日志，然后找另外一位后端开发商量了一下，最后开始修复。

12:00 小张终于把流水线的自动化测试问题修复好。那个bug已经修复好。

他走到看板前，把代表那个bug的卡片，从DOING移动到DONE列。

然后他把那个代表新的软件功能的卡片，从TODO移动到DOING，表示他下午要为实现新需求写代码了。

他活动了一下发酸的脖子，开始往餐厅走，去吃午餐。

上午的工作是修复测试人员发现的一个bug

13:00 午休完毕，小张开始为实现那个新需求写代码。

和修复bug类似，他先阅读相关的需求文档，然后思考实现方案。

之后他喊业务分析人员过来，澄清了有关这个新功能的疑问，并讨论了检验这个新功能是否完成好的验收标准。

一切都搞清楚了，他开始为新功能编写代码。

这个新功能看起来比较好解决。1个多小时后，他就完成了。

他首先自己测试了一下。在确认已经没有问题后，他喊附近的业务分析人员和测试人员过来看一下。

15:00 业务分析人员和测试人员走过来，看小张为她俩演示完成后的功能。

业务分析人员指出了一些问题。小张记下了。

测试人员又提了一点改进的意见。小张也记下了。

15:30 小张根据业务分析和测试人员的反馈，修改好代码。

之后，他再喊她俩过来看一下。她俩很快过来看了一眼，说很好。

测试人员说，你提测吧。

16:00 小张把完成好的功能的代码提交到版本库，并开始观察自动触发的持续集成流水线上的自动化测试是否运行正常。

16:05 今天又有点不走运，流水线报警，说他为新功能所写的代码，缺乏自动化测试覆盖。

他于是为这个新功能，补充自动化测试代码。

18:00 小张终于把新功能的自动化测试补充好。流水线运行一切顺利。

他走到看板前，把代表那个新功能的卡片，从DOING移动到DONE列。

他看了一下表，下班时间到了。他于是背上包，离开办公室，往地铁走去。

说完了理想的情况。下面说说不理想的情况。不理想的情况，有时是常态。

不理想的情况下，他的日程会被打乱，进度会延期。他只能靠加班

在不理想的情况下，每天10分钟的站会，有时会延长到1～2个小时。

因为项目经理有时觉得好不容易大家都在，就会把很多与这个会无关的内容加进来，比如讨论需求、讨论bug修复、讨论公司的代码评审制度，等等。让这个会很低效。

在不理想的情况下，开发小组没有看板。

每个人的工作进展没有可视化出来。于是项目经理会要求小组每个人写日报和周报。

不知为什么，回忆这天或这周做了什么，往往很花时间。

在不理想的情况下，小张在修复bug和实现新功能之前，不会找测试和业务分析人员澄清。

在写完代码后，也不自测，且不会再找她俩验收。

也没有流水线的自动化测试的质量检测。

为何小张不做这些事情？

因为他曾经找过她俩，但她俩总是说忙，半天不来。他不想等了。

流水线跑自动化测试的事情，领导认为应该做，但往往由于忙，就搁置了。

最后小张的代码提交后，过了几天，测试人员发现了bug，就找他来修复。

但几天前的事情，小张早忘了。

他还得花时间去复现bug，回忆当时是怎么写的代码。这些往往也很花时间。

这些不理想的情况，打乱了小张每天18:00准时下班的节奏，于是他只能加班，去应付这些事情。

最后，不管是理想情况，还是不理想的情况，生产环境的意外事件难免发生。

想想去年几次著名的互联网系统崩了的意外事件。

此时，小张还要忙于修复意外事件。这或许要占用晚上和周末的时间。

程序员一天干了很多事情。

理想情况下，他的日程会安排得很满。

不理想的情况下，他的日程会被打乱，进度会延期。他只能靠加班。