29 | 加班：加班逃不过，如何用正确姿势加班？

2020-07-22 臧萌

职场求生攻略

进入课程



讲述：臧萌

时长12:48大小11.73M



你好，我是臧萌。咱们程序员，尤其是互联网行业的程序员，都基本逃不过加班这件事。加班的原因，我总结了三个：任务太多，有紧急的事情以及强制加班。今天我就根据不同的加班原因，来仔细和你聊聊加班这档子事儿。
任务太多首先就是任务太多，事情做不完。大部分情况下，造成工作任务繁重的原因，都是一些现实因素。
比如说系统的架构，已经不能够高效地应对现在的业务，每次增加新的业务用例都很繁琐，而且容易出错。又比如公司里各种系统都不好用，工作中用到这些系统，就费时费力，还可能来来回回折腾很多次。这些现实情况，让本来听上去没太大工作量的工作，实际做起来要用的时间却会多很多。
提高自己的效率如何应对这种情况呢？我们要去思考这些让自己效率低下的原因。为什么会效率低下？根据我的观察和切身体验，其实很多时候，加班并没有让自己的产出更多。程序员的产出是不能用代码量来衡量的。
如果非要衡量的话，可以用代码完成的功能这个维度来简单衡量。很多时候我们加班，并不是完成了更多的工作，而是用更长的时间，去完成自己本应该用作时间就可以完成的工作。这就是效率低。
回到增加业务用例的情况，我们可以问自己这样一个问题：如果系统重新设计重新做，是否可以让增加业务用例的时间大大缩短？如果是的话，现有系统架构陈旧就是效率低的原因。再看工具的问题，你能不能找到一个合适的工具，让系统更加简单自动化？
这里我举一个自己工作中遇到的例子。我曾经参与过一个系统的开发，系统的输出是一条条互不相关的 key-value 记录，总数大概五百万到七百万条。
为了验证输出的结果是否正确，要和上次系统运行的结果做对比。但是这个对比工作没有很好的工具，当时的做法就是将两份数据导入 MySQL 数据库，然后对于怀疑有问题的数据，用 key 去查询两份数据，逐个字段地进行比较，找出数据有差异的原因，再分析原因是否合理。
这是一个纯人工的工作，每一步都需要人来操作，如果有这么十几二十个记录要核验，那基本上半天就搭进去了。这种事情如果是偶尔搞一次，那也无妨。但是随着系统的发展，这个事情几乎每周都要来个几次，甚至有时候一天就要搞好几次。那这就完全是一种低效率的工作方式了。
我当时思来想去，觉得几百万的数据量也并非一定要用数据库。于是我写了一个程序，可以将两份数据文件做对比，自动找出变化大的数据，并自动对比各个字段。这样，生成的对比文件，就可以直接用来判断这次运行的结果是否有问题，并且可以很方便地，对每个差别比较大的数据进行查找和比对。最后我再把这个程序对接到生成系统输出的任务上，做到自动化执行。
当然，在很多时候，系统重构也是很好的方式。举个例子，如果数据的 schema 经常需要根据业务需求做改变，但是查询条件就只是根据 key 来单条查询，那就可以考虑搞一个 text 字段，把动态增加的业务字段转成 JSON 来存储，当然，也可以考虑转到对数据的 schema 变化更友好的 NoSQL 数据库。
不论你是选择合适的工具，还是去重构系统，都是在选择一种用更短时间去完成工作的方式。重点不是在于你去选择什么特定的方式，而是在加完班之后，你得好好思考一下，今天的工作效率高吗？有没有什么事情让自己觉得没技术含量？你是不是可以避免这些没技术含量的事情？是不是可以让这些没技术含量的事情自动起来？
我们是软件工程师，我们要让每天做的事情，对得起自己的能力。加班不仅仅是在浪费自己的时间，更是在浪费自己的才华和能力。有时间加班，为什么不用这个时间，搞个系统替自己加班呢？
紧急的事情其次就是有紧急的事件。可能是线上出问题了，也可能是忽然有个优先级特别高的项目，需要自己在的组协助，甚至有可能是你直接被抽调去做某个高优先级的项目了。
至于线上问题，这个基本上是不能逃避的。我们能做的，就是防患于未然。比如增强监控，要监控的不仅仅是自己的系统，还有自己依赖的系统和依赖自己的系统。又比如尽量避免在周五上线，因为如果周五上线出了问题，就要加班去搞等等。
至于优先级高的项目，在我看来，更多的是一个机会。这些项目无论是新业务新方向，还是系统升级更新，都是一个让自己刷新技能、扩展眼界的机会。这时候阶段性地付出一些时间，对自己的职业生涯来说，是挺值得的。
拿我自己来说，我是个比较懒的人，有时候对很多系统的了解也是浅尝辄止。但是我被抽调参与过几次紧急项目的开发后，对这些系统和业务的认识提升了很多，反过来再看自己的系统，也更能理解一些之前没注意到的细节了。
强制加班最后就是被大家“深恶痛绝”的强制加班。事情嘛也没啥事情，就是公司的氛围就是这样，大家都在位子上好像都没啥事情做，下班回家吧，又显得突兀——毕竟大家都没走。甚至公司可能会强制规定延长工作时间。即使公司不硬性规定，也可能用各种政策和福利影响你，让你半推半就地加班。比如比法定下班时间推迟几个小时才有“免费”晚餐，或者推迟几个小时下班才有班车等等。
我们站在工作的角度，先看看公司为什么原因让员工没事做，也得留在公司里。
我总结下来，大概有这么三个原因。首先，员工留公司里肯定会做更多的工作。即使你不想做和工作相关的事情，只要在公司里呆着，也难免会不自觉地做一些工作。
其次，是方便彼此协作。即使你自己本身不加班，如果别人加班需要你协助的话，可以直接找到你人，你也不好意思面对面地拒绝别人。
最后，就是公司文化等原因，公司愿意营造出这么一个大家都在努力奋斗的氛围。
那么我们应该如何应对这种类型的加班呢？在我看来，既然选择了这家公司，还是尽量遵守公司的默认上下班时间。那么在你没事做还得加班的时候，在公司能干什么呢？
做些对自己有附加值的事情公司是一个可以专注的环境。如果不得不呆在公司，那对自己最有利的选择，就是做一些对自己有附加值的事情。这里我列举两个例子。
学习和探索新技术首先自然是学习新技术。一个选择是把自己白天没时间弄清楚的技术整明白。不要放过程序中任何一个错误日志，不要放过工作中任何一个没想通的事情。然后就是看看哪些技术可以用在我们自己的系统上，放心大胆地试试看。毕竟这不是被安排的任务，不需要背负产出的压力。
不要止步于抱怨每个组、每个系统，肯定都有大家一直在抱怨的小事情。这些事情不做也可以，但是做了会让自己组的效率更高。这时候，可以选择自己有兴趣且力所能及的点，把痛点修正掉。一个系统既然有人抱怨，还在一直用它，那就说明这个系统解决了实际的业务问题，是有价值的，是值得做好的。
一个被抱怨的大户，就是大名鼎鼎的遗留系统。也许它的技术很落后，也许它的系统设计千奇百怪，也许它的代码很丑陋，也许它各种不好用各种容易崩溃，也许它在技术的角度说，怎么都让人看不上眼。
但是遗留系统，尤其是那些大家都在骂，甚至深恶痛绝，但是却每天都在用的系统，可以说是一块璞玉。因为这些遗留系统帮你积攒了最有价值的东西：货真价实的用户需求，而且是怎么恶心用户都恶心不走的需求，简称刚需。抛开里面的技术不谈，这些业务需求，是值得我们一点点理解和掌握的。
理解了这些需求，就可以找机会改造或者设计新的系统，来替代老系统。需要特别强调的一点是，这个前提和基础在于一定要深入理解这里面的需求。如果你仅仅是从技术和代码层面觉得系统烂，就想重新做一个，大概率做出来的系统还是会烂。因为你如果没有对业务需求的完整理解，新系统的架构设计大概率也会无法很好地容纳这些业务。
老的系统也是因为架构设计没跟上业务的发展，才会被一会儿一个补丁、一会儿一个临时解决方案、一会儿一个 hotfix，慢慢给弄得乱七八糟的。那么如果你在设计新系统的时候，不去全盘理解业务问题，设计更优化的业务模型，那么很可能会重复老系统的坑，疲于应对自己无法处理的业务需求，然后变成第二个大家眼中的烂摊子。
举个简单的例子，业务需求是要在遍布泥滩和小水沟的地面行驶，而老系统则是造了一辆普通的车。时间久了，普通的车自然无法很好地应对这种路面环境，这里进水，那里生锈，还时不时抛锚，慢慢成了大家眼中的烂系统。
如果你再重新造一辆车，用更好的引擎、轮胎、底盘。对应到软件上，就是用了最新的技术，比如升级 SDK、升级各种软件包和技术栈、上云、用 Docker 等等。这些技术层面的东西，当然对车有帮助。而且新系统刚开始因为没有历史包袱，看上去好像还不错。但是慢慢地，这辆车也会和原来的车一样变成一辆烂车，因为传统的车就根本不适合在遍布泥滩和小水沟的地面行驶。
技术升级无法解决架构的问题。对于遗留系统，很多时候需要考虑的不是升级技术，而是升级架构。比如面对遍布泥滩和小水沟的地面环境，就应该用履带车，而不是用传统的四轮汽车。
总结程序员加班的现状，是由不同的原因造成的。我们能做的就是不断反思、好好利用加班，让加班的时间尽量短，让加班的时间尽量对自己的发展更有好处。
如果是效率低，那就尝试提高效率。如果是有紧急任务，那就好好做、好好学。紧急的事情，是公司层面优先级更高的事情，更值得我们花时间做好。而对于现在被大家诟病的强制加班，也不能浪费了自己的时间。毕竟时间是自己的，一旦浪费了，损失的其实还是你自己。
不浪费时间的好方法，就是做一些没有业务压力，但是可以提升自己的事情。比如去把白天不懂的事情弄懂，优化现有的系统，或者去遗留系统里淘金。这些都是在为自己的发展积蓄能量。即使这些事情都没得搞，还可以多和同事闲聊一下，沟通沟通。大家都在公司，又不忙，是多么好的一个沟通的机会呀。
思考题你现在的工作需要经常加班吗？你是如何应对的呢？你加班的时候，效率高吗？
欢迎在评论区和我交流。也欢迎把这篇文章分享给你的朋友或者同事，一起交流一下。

提建议

28 | 沟通原则：什么时候应该妥协，什么时候应该坚持？

30 | 焦虑：程序员怎样才能越干越给力？

 写留言

精选留言(4)

sugar

2020-07-24

这篇谈及了软件工程师这个职位很大的一个痛点，加班问题。但是感觉老师可能是受限于种种约束，一个很关键的点没讲透。加班的非常普遍的一个原因：项目排期不准确。软件工程师打交道的东西是软件，而软件的开发存在诸多不确定性因素。不同于传统的工业制造，你问一个车间的工人这批零件什么时候能出来，经验足够的工人能给出非常接近准确的时间，小时级别甚至分钟级别都不是没可能，因为整个工序每个流程都是清楚的，之前都做过；软件的开发大不相同，事实上在我从业的职业生涯中，我很少做“重复”的事，如果一个SE（software engineer）总做重复的事，他的薪资一定很低甚至面临被淘汰的风险。这是SE本身的职场定位和精进目标所决定的，却也造成我们往往很难在项目开始之前对项目工期进行准确的预估。为什么会给出这么不准确的排期坑自己呢？（当然有些团队里，担任team leader的人会替别人排期）对这个问题的答案，我曾经迷信于求助学院派提出的“软件工程”方面的很多理论知识，像《人月神话》（放在当今国内而言，该改为人日神话比较贴切）这样的书里描写的那样。然而，如今随着工作年限和经历过的项目，我越来越怀疑为软件项目提前预估排期是否科学？单纯地，对一个项目进行整个项目时间上的预估，有可能吗？我目前的看法是，如果一个人跑来问你，xx这件事要做多久你给我个时间点，你可以在脑中把这句话翻译为：“你tm给我加班吧”。所以对这种人或这类问题，你真正该做的不是拍脑袋给出一个x天/x周的绝对时间（这是最蠢的回答，如果你的答案还牵涉到你组里的其他小兄弟一起加班，那你更蠢），而是该给出一个 y = k * x + b 或者其他更高级的函数，y是他想要的绝对时间值，要用后边的变量经过一系列计算得出。变量是你作为一名软件工程师无法确定的东西，而软件工程师的职业素养和能力也不体现在直接给出准确的y值，而是体现在给出这个公式的准确性上面，这需要经验了。这样给出的答案，也有一个言外之意是：“我是名软件工程师，是打工者，我可以提供我的专业能力尽可能让排期确定化，但确定化 != 确定，这其中的不确定因素带来的风险，不该由打工者来承担”。现实生活中听到的措辞肯定不是这样直接、不讲情面的话语，但我反复观察很多有经验的架构师、项目经理，其实越是有经验的软件行业从业者，他就越是会遵循y=kx+b的方式给出排期，而非直接给你一个绝对时间。不知老师怎么看？是否同意我的观点呢，我也想听听老师的经验。谢谢！

展开

作者回复:
问题问的非常好，必须写一篇FAQ来聊聊～

https://xie.infoq.cn/article/b169d74e5509171260c0841ed

 1

 4
王智

2020-07-22

加班倒是没啥，但是最近公司这个制度有点想吐槽，暑假期间996接受了，日工作表也接受了，但是每天都要统计代码行数就很麻烦，又耗时又没有任何的意义。而且合同不到期提前离职加班时长清空，加班时长无法兑换工资，只能申请调休，但是调休又不能一次调多天，还得想理由，无力吐槽，默默的坐着想着我就是个打工的！！！！！！！

展开

作者回复:
这个制度确实有点过于僵化和形式了，而且对员工不大又好。



 2
卡卡

2020-07-22

单身的时候我是不排斥加班的，即使是强制加班我也会看一些技术书籍和博客，因为公司的环境还是相对利于静下心学习的。结婚后明显对无效加班心底里感到抗拒，因为家庭需要时间去经营，毕竟除了工作还有生活！

展开

作者回复:
是的，加班对生活的影响还是很大的。所以要提高自己的工作效率，减少加班的可能。



 2
Sdylan

2020-07-22

加班对于哪个行业都比较常见，只是程序员这个行业加班不会按照加班工资给你算。所以出现很多问题，你的活没干完。其实加班要找到原因,到底是什么让你加班：是效率低还是被强制的。不要说什么996、007啥，哪些都是表象，实质到底怎么回事呢。

有了家庭以后，强制性加班我也没有管。虽然也想在公司学习技术，但家里娃早上出门看一眼，晚上回家已经睡了。心里不忍心呀。

展开

作者回复:
软件公司加班费确实不能按照工作时间给。就好像程序员的工作量不能用代码行数衡量一样。否则这个太好作弊了。所以这个事情没有什么好的解决方案，公司和员工在加班和加班费上肯定有一方会吃点亏。

强制加班还是弊大于利的。毕竟自己没有主动权，对生活的影响就比较大。

 2

 1

