经常加班，怎么兼顾个人能力提升？

当我们在讨论加班与提升的时候，需要首先明白，加班背后的原因。

加班并不简单粗暴的等于，工作太多，正常上班时间无法完成，所以需要加班。

从主观和客观上，我们大致梳理了导致程序员加班的“几宗罪”：

主观看上：

• 接触新的业务，初步的熟悉阶段。一般这种情况在刚入职或者接触一个新的领域/业务中比较常见，这种加班通常是阶段性的。
• 接触新的技术领域，技术转型，这里就包括使用的技术语言的调整，接触的技术环境的变化等。这种加班和上一点一样，在熟悉熟练后，会有所缓解。
• 个人技术追求提升，修整以前觉得不够优雅的解决方案。这就是一个程序员对自己技术上的追求了，比如方案优化或者重整，这些都是对技术精进的需求。再加上有的时候一些解决方案上的提升会涉及到比较繁琐的重构，一般这种重构都不会有专门的时间处理，通常都需要程序员自发进行加班。

客观上看：

• 业务的增长过快或开发人手短缺；
• 为解决线上突发情况，疲于奔命

总而言之，这就是业务需求的不断增长和程序员人手短缺的基本矛盾。

认为，自我修炼不一定只能在加班后的私人时间进行，加班本身就是一次进行自我修炼的绝好时机，聪明的程序员知道如何充分利用好它。

具体的修炼建议见下：

业务导向：在业务实现基础上，多想一步

直白的讲，这就是做一想二：即当我们要实现一个业务功能时，我们不能仅仅停留在功能实现的层面。怎样可以多想一步？

• 不了解多想一步的思路时，不如多确认一步。作为技术人员，其实对业务的理解或者问题的理解与负责业务人员思考的角度是不同的。需求的提出方可能比你更加了解他未来的呈现，当你在实现功能A的时候，不如多和他们交流，这样你在实现功能的时候，自然就会对他可能会有的扩展性有一定的把握，方便你留出未来的预案了。
• 换位思考，把自己当产品的主人如果你十分害羞，实在不想和业务打交道，其实你也可以考虑经常“换位思考”，把自己当成这个产品的设计者，想想这个功能/需求 是为什么出现的，它要解决什么问题，未来会有什么需求。

技术导向：把你的代码当成自己的孩子

什么叫做把代码当成自己的孩子，其实就是要建立好：把技术的精进当成终生奋斗目标的观念。

举个例子，当你完成了一个简单的需求，你的业务的响应时间从10毫秒增加到了100毫秒，你就要有一种心痛的感觉（危机意识），不断地反复扪心自问，为什么慢了这么多。当你对自己有一个技术上的目标时，你就会打开自己的雷达，努力提高自己代码的性能。

那么，我们怎么做到进一步的技术提升呢？

首先，我们需要明白现阶段待解决的问题的关键核心点，找到影响你解决这个问题的缺口。刚刚那个例子，为什么我们会从10毫秒增加到100毫秒，你需要找到响应时间延长的原因。

怎么找到这个影响解决的缺口呢？

首先，你要对每个逻辑都了熟于胸；其次，你需要一个强大的监控数据的支持，找到关键的路径，集中进行性能调优。如果确实是因为业务复杂导致，可以考虑采用并行处理、横向扩展的方案。

勤于总结：不要在同一个坑里摔倒 N 次

程序员的工作，在接触A领域时，你可能踩了一部分坑，花了很多时间去寻找解决方案。但可能只是短短一个月没有接触A领域，你就渐渐忘记了曾经踩的坑。等到你又要去接触它的时候，又栽在了相同的N个坑里，再重新找解决方案。听上去就效率低下，所以如果实在觉得摔在坑里太疼，不如记下来吧。这样就做成了一本专属于自己的踩坑指南。

另外，就像Henrik Warne在《程序员，你会从Bug 中学习么？》所说：Nassim Nicholas Taleb 在 《Antifragile》中写到：“错误包含丰富的信息”。Bug 帮助我们更好地理解系统，告诉我们怎样提高编码、测试和调试技巧。

所以我认为尽可能从 bug 中学习经验，是再正常不过的事了。我发现为每个有趣的bug 记录下来，让我轻易学习到很多。在记录的行为中我会对发生的事情思考得更深刻。同样，一旦记录下来，我可以在之后检查发生的事情。偶尔，我也会浏览文件，只阅读教训部分，对我认为是从 bug 中学到的最有价值的经验加强记忆。

这里分享一个BUG修补记录的例子：

【日期】：2004-08-17

【问题】：当解码 Q.931 信令时无限循环

【原因】：当在Q.931信令中发现一个未知的元素id时，我们试图通过读取它的长度来跳过它，并且将位置指针迁移几个字节。但是，在这个例子中的长度是零，导致我们反复跳过相同的元素 id。

【怎么发现的】：在解码一个 Ethereal 从 Nortel 追踪到的安装信息时发现了这个问题。他们的信息是 1016 字节长度（包含大量快速启动元素），但我们的 MSG_MAX_LEN 是 1000。通常我们会收到一条来自 common/Communication.cxx 的信息，但现在，当直接输入需要解析的数据时，数组末端内存访问越界，其恰好是 0，暴露了这个问题。为了找到它，我仅仅在 9931 解码中添加一些打印输出。但很幸运数据恰好是零。

【修复】：如果长度是零，设置为 1。这方式总是行得通。

【在哪些文件修改了】：callh/q931_msg.cxxcallh/q931_msg.cxx

【我导致的】：是的

【解决Bug的时间】：1 小时

【教训】：信任收到信息中获得的数据。不仅仅是产生大量可能导致问题的数据。显示长度为 0 也同样不好。

PS，善用搜索、多多交流 比独自思考，会更提升效率。

保持好奇心：持续学习、拓展技术圈

技术总是不断变化的、快速迭代的，想要跟上新的技术变化潮流，可以给自己整理出专门的时间去泡一泡技术论坛，多勾搭一些技术达人，进行以技术为目的的社交。当然，最重要的还是要保持对新技术的好奇心。

技术的追求是无止尽的，多看源码、多看成熟的解决方案、多了解方案背后的原理、多看看视频，多写代码，在实践中强化能力。这些其实就是Stay hungry, stay foolish的基本知识点。

说了这么多方法，这里还有容易带来不必要加班的雷点分享给你：

• 简单的c-c&c-v可能给自己带来无穷的工作量。当一段逻辑在很多地方都需要用的时候，可能有时，我们就去简单的c-c&c-v了。但一个功能是不断拓展的，可能一开始你还记得这些地方引用了这些代码，但随着业务逐渐复杂，可能改了A处、B处，发现C、D、E处没有改，然后就只能加班了。

这就是一时的偷懒带来的多余工作，当你发现很多地方都用到同一套逻辑，不如把它封装成一个函数，可能这个写起来比你c-c&c-v需要更长的时间，但是其实节约的是未来的时间，以及培养的是考虑代码复用性及程序的鲁棒性的思维。

• 如果没有风险意识 可能就真的只能加班见了

当每次上线新的版本的时候，仅仅考虑function well的状态，忽略万一挂了的状态，带来的后果，可能就是真的挂掉，加班解决了。所以，做好风险把控，做足测试，克服万难做好回滚措施，不要掉以轻心，真的可以帮你少紧急加班哦。

以上就是关于这个问题， 想要分享的方法论。还是希望大家健康作息，少加班，多成长。