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