程序员为了少加班想了这几招

news2024/11/19 17:50:27

📣📣📣📣📣📣📣

🎍大家好，我是慕枫
🎍前阿里巴巴高级工程师，InfoQ签约作者、阿里云专家博主，一直致力于用大白话讲解技术知识
🎍在这里和大家分享一线互联网大厂面试经验、技术人成长路线以及Java技术、分布式、高并发、架构设计方面的经验总结
🎍感恩遇见，希望我们都能成为更好的自己
📣📣📣📣📣📣📣

谁偷走了程序员的时间

源源不断的会议

业务需求KO会议

技术评审会议

测试评审会议

故障复盘会议

其他会议

开发

碎片化的杂事

如何避免不必要的加班

不必要的会议能不参加就不参加

避免表面一致

琐碎事情统一处理

加强代码质量管理

总结

天天开会，我还有时间写代码吗？

接口自测过没，怎么联调还有这么多问题？

需求怎么又变了，PD到底有没有个准信？

又是版本发布倒排，需求这么多能做的完吗？

以上各种场景大家在日常的工作中是不是经常碰到，今天慕枫就和大家聊一个非常有意思的话题，程序员为什么总是要加班，到底谁偷走了程序员的时间，我们应该怎么做才能避免不必要的加班。

谁偷走了程序员的时间

要想少加班就要搞清楚是什么因素导致了程序员加班才能完成工作，也就是说我们得先弄明白程序员的时间到底被谁偷走了。我们先分析下程序员每天的工作主要包含了哪些内容，因为只有搞清楚程序员时间都用在哪里了，我们才能对症下药制定相应的优化计划，避免时间黑洞浪费精力资源在一些不重要的事情上，把时间和精力更多投入到重要的事情上以及需要完成的任务上。

有的同学可能会说，程序员嘛，工作不就是码代码嘛。如果真的只是这样，我想大家真的要烧高香了，实际上程序员的日常工作远远不至于写代码一个事情，甚至有的时候一天代码没写几行都在开会。

慕枫将程序员的工作主要划分到以下三大块内容中，接下来我们来具体分析下如何在这些繁杂的事项中把本该属于程序员编码、思考设计的时间给抢回来。

源源不断的会议

业务需求KO会议

在阿里，一般当业务方需求过来之后，PD或者产品经理会组织会议对技术同学进行产品需求进行KO或者澄清。在会议中PD或者产品经理需要讲清楚为什么要做这些需求、需求的内容是什么以及想要达到的业务效果，同时接受来自技术同学汹涌而来的挑战，一般这种会议打底要1到两个小时，有的时候讨论激烈的话可能都不止，甚至可能需要多次会议来回讨论才能确定需求。

技术评审会议

需求确认过之后，技术同学就需要进行对应的方案设计，我们想清楚如何做这个需求，同时输出相应的设计文档，设计文档中主要包含实现逻辑、修改点、时间计划、灰度策略等等，设计方案完成之后组内会先过下方案，把关下质量。同时负责这次整体需求的技术PM需要组织业务全链路节点的技术同学来对焦各自的技术方案，看看有没有什么遗漏之处，需不需要上下游业务节点的支撑，这个会议基本上1到两个小时。

测试评审会议

技术方案确认之后，测试同学就需要根据PRD文档以及设计方案来编写测试用例，也会组织会议找技术同学来看看测试方案合不合理，测试用例还有没有遗漏的地方。这个会议基本上1到两个小时。

故障复盘会议

这个会议大概是程序员最不想参加的会议了，在互联网公司出现故障是需要进行复盘的，一旦要开故障复盘会议就意味着出现了线上故障。程序员最担心的就是出现线上故障，如果搞出来一个P0级别的，基本一年就白干了，提前预定本财年3.25。

其他会议

还有一些其他会议，比如项目KO会议、平台对接会议、方案讨论会议、交互评审会议等等。

开发

技术同学开发编写代码以及功能自测，完了之后再和前端同学或者上下游业务的同学进行联调，这个过程也是比较耗时间的。因为在联调的时候总是会遇到这样或者那样的问题，比如环境问题、数据问题、代码Bug等等。其中最主要的就是代码Bug问题，因为有的技术同学可能由于时间关系根本没来得及自测就和大家进行联调，直接把联调当作自己的单元测试和功能自测了，所以这种情况下基本都是一边联调一边修改的状态。另外在联调的时候可能也会发现一些设计上对不齐的地方，这个时候也需要进行修改，同样需要耗费时间。

碎片化的杂事

杂事就很多了，比如别的团队的技术同学来向你咨询业务问题，你得花费时间向别人解答。小组内每个同学都需要进行技术分享，那你就得准备PPT，还得认真准备，因为我们需要不断建立自己的技术影响力，如果讲的东西太水了，实际上浪费自己的时间也浪费别人的时间。功能发布上线之前，TL以及组内的同学需要review你的代码，这也会耗费一个小时左右的时间。线上如果出现报警，我们就需要排查定位问题修复bug。类似这种碎片化的杂事充斥在我们的工作中。

如何避免不必要的加班

我们分析完了每天的时间都花在哪里之后，就可以进行针对性的进行时间压缩。

不必要的会议能不参加就不参加

这里举个栗子，在需求澄清会议中，一般会对一批需求进行澄清，这些需求很多时候只有一小部分和我们相关，所以在会议上我们对和我们相关的需求进行重点讨论和理解，在确认完需求内容之后就可以撤了，其他和自己不相关的需求没有必要再耗时间在会议上，这样可以大大压缩参加会议的时间。

避免表面一致

在整个研发活动中我们需要避免表面一致情况的发生，什么意思呢？就是我们需要真正把需求弄明白想清楚再动手写代码，否则在没搞清楚需求情况下写代码，很容易出现做出来的功能和产品要求的出现偏差的情况，那么在验收的时候就容易不通过，然后就是互相扯皮，研发说产品当时没有讲清楚，产品说是研发没有理解透需求。最后就是返工重新修改，白白浪费了时间。所以我们不如在需求确认阶段，多花点时间和产品经理进行需求的深入沟通，把需求吃透了确保没有理解上的偏差，避免表面一致，这样可以帮助我们节约很多时间。

琐碎事情统一处理

我们所负责的业务不可避免的会有业务合作方来咨询你如何用平台以及对接的事情，比如平台如何使用，有哪些开放能力等等。来咨询的同学一般呈现散点状，也就是说不固定时间来咨询，有的时候你正在奋笔疾书写代码，但是别人过来咨询就会打断你的编码思路占用开发时间。所以这个时候你可以考虑专门下午四点到五点固定时间段拉个群来统一回复别人的问题，或者说如何对接的写一篇文档，有别人过来问的就先让文档，这就好比智能客服一样，这样可以帮助你挡掉70%左右的问题。不免这种业务答疑打乱你原本的开发工作。