最近你加班了吗？

最近加班挺多，心里有点惆怅。现在偷得一点时间，反思了一下这段时间加班的原因，希望能自己以后能够“好好生活，少加点班”。

工作量的评估

代码写不完，一个很重要的原因就是工作量评少了。老大布置了一项任务，让你评估一下时间。结果因为自己太过乐观（一般都是too young too simple），导致评估时间过少。而老大大多只要结果，说出去的话，就像泼出去的水。为了达成规定时间提测的承诺，我们不得不加班加点。 吃了苦也只能自己咽下去~
so，工作量评估的时候，一定一定要留buffer~

前方有坑，小心翻车

公司里的代码几乎不可能都是一个人写的，所以，我们经常需要接手别人的代码，在上面缝缝补补，添砖加瓦。这其中就难免会碰到前人埋的“坑”，一不小心，自己就翻车了。加班加点都是小事，最怕就是造成产线事件，结果写代码将自己写走了。。。

俗话说，“文人相轻，自古而然”。其实，程序员也不例外，大家都觉得自己的活儿干的好，其他人都不如自己。所以就导致自己觉得很炫的代码，很酷的操作，也许在后人看来，就觉得脏、乱、差。这一点其实很难避免。程序员水平的参差不齐，这使得一切良好的设计、优雅的实现很容易变成后人眼中的“坑”，加班加点，在所难免。

so，当遇到不理解的代码的时候，我们除了要努力提高自己的水平外，一定要看当初的需求和设计文档！自己写设计也要详细、代码多注释，减少被吐槽挖坑的几率（这个真心避免不了。。。😂）

紧急需求！需求变更！

事实上，程序员加班很大程度上是来自于需求的变更。
最近也是接了几个紧急需求，这也导致了加班。这一点来说，其实没啥好吐槽的，大家都知道。
其实需求没啥好怕的，我想说的其实是，当一个系统变大变复杂，每一次改动都会牵扯万千。在产品同学看起来很简单的一个改动，可能就要“大改”。这其中深度的原因可能是系统设计的不合理、“技术债”的累计，当这又刚好碰上紧急需求，程序员又要头疼了~

代码写得快 OR 写得对

在时间充裕的情况下，我们当然可以追求卓越、将代码写好。但是假如你的时间是有限的呢？有限到可能根本完成不了呢？
我最近就遇到这样一个场景。老大布置了一项任务，相对“任重而道远”的那种吧，当然时间也很紧张。后续发现任务无法达成，所以准备这一版先上线，不启用，下一期再启用。这时候一个问题就摆在眼前了：是 先把这一期代码写完，但不保证正确呢？还是先尽量代码写对，但不求写完？

这样一个问题，我觉得确实值得思考。

对于老大来说，当然愿意听到代码已经写完了、只差自测这样的“好消息”。但是代码写完之后的自测，真的是非常痛苦。

对，我就是后面接手“只要自测”代码的倒霉鬼。任务看起来很简单，只是自测调试。但是几乎一步一个坑，搞的人快要崩溃。因为跨系统调用很多，几乎每一个系统调用参数传递都有问题，造好的数据根本就不够用，代码一直都要修改，再打包部署，时间浪费很严重，真让人崩溃。加班加点调试不说，老大还觉得功能都写完了，就调试一下，没啥工作量。。。😭

所以，程序员之间就不要相互伤害了，大家先把代码写对吧。。。😂

外界干扰

大多程序员其实并不害怕写代码，害怕的是你打扰他写代码。

外界干扰是一个老生常谈的话题了，我们在干一件事的时候，就怕突然被打断。等处理完回头继续干活，思路又断了，又得重新整理思绪。这样效率就会变得很低。

每天都会有大量的外界干扰影响着程序员写代码，如产线问题的处理排查、各种会议的参加扯皮、同事问题的协助、甚至喊你下楼一起买瓶饮料。。。这样的事情太多了，处理不好，很容易就变成了白天基本感觉啥事没干，晚上埋头写代码的“常态”。

这样的问题很多，个人觉得要针对各个问题分别总结一下处理方法，提高效率，减少不必要的活动是关键。
例如 产线问题的排查处理。产线问题当然不能不查，但是查的多了，其实也可以发现一些共通的问题。能优化的问题，通过版本迭代优化掉；不能优化的，可以汇总一个产线问题知识库，总结问题特征和处理方法模板，这样下次就能快速处理。能节省不少时间。

总结

最近加班有点多，希望后面加班少点。好好生活，少加点班。

最近你加班了吗？为啥加班了呢？