程序员为什么加班太多？有可能是代码写得烂
加班是大家老生常谈的话题了，国内互联网公司加班现象更是严重，而互联网公司中则要数程序猿加班最为厉害。很多人是在加班，但不代表很多人愿意加班，可能刚入职场的小白倒是干劲十足，成了工作狂，或者是热爱工作，又想证明自己的人生价值不断投身于事业中的人…
于是，众猿们议论纷纷，好像在密谋什么大事……
比如反抗：
@ooppstef：
一个是不知道怎么反抗，离职到下一家加班的概率也大，BAT 大部分团队都加班。另外，竞争大，很多时候自己也想提速做产品，加班也是自愿的。
@15015613：
根本原因是缺少反抗的组织者。一个人反抗，完全是找死。联合起来才有希望，想要联合起来便要有组织者、带头人，代表工人利益的工会跑哪去了？
@suilongfei：
别较真，不然大家都没饭吃。
也有人觉得加班是必要的，不然会被干掉的：
@sagaxu：
如果 A 流水线工资是 B 流水线的 2 到 10 倍，B 流水线的人会不会愿意免费加班换取 A 流水线的一个职位? 说到底还是供需决定的，互联网是少数既不需要拼爹又没有很高门槛的高薪行业。
@zartouch：
互联网是工作量大节奏快，要高薪就要承受大工作量。你加班只是因为你工作做不完而已，拿多少钱做多少事，这么简单的事情不用我再强调了吧？
大部分人都是客观吐槽：
@EleanorKusosaki：
根据我对我司的 JAVA 的观察，我发现是这样的。他们一般都是单身租房，回去也没事干，不如在公司里面消磨一下时间，写写代码吃吃饭看看书，还能赚个晚饭补（当然长此以后就更加找不到对象了）。然后，不然就是家庭不圆满不想回家做家务…就熬到半夜再回去，不然就是做不完活。
@mytsing520：
你得证明确实是公司让你加班，而不是你主动加班。公司让你加班，按法律来说必须付给加班费；主动加班，事后公司认可的，也要付给加班费；如果纯粹是为了处理完问题而主动加班，法律不认可其加班事实。
@coderluan：
1. 行业产出太难评价，不像流水线工人可以按件计费，所以加班就有钱，难免有人磨洋工，加班费就就不如绩效好操作。
2. 这个行业其实人很多了，中国年轻人压力又大，很多人都是主动选择加班的工作的，毕竟工资肯定高一些，而就行业 1+1<2 的特点来说，公司肯定偏向于能加班的。
3. 环境确实有问题，但是中国问题多了去了，而大部分人只关心自己遇见的问题，所以任何问题就解决不了。
那么回到一开始的问题：程序员为什么加班太多？有可能是代码写得烂
那怎么写出好代码，从而不加班呢？
请注意：这不是一篇证明谁导致程序员加班太多的论证文，也不想给大家灌鸡汤，让大家一夜之间都变成编程高手，但是至少说一些实实在在的经验和方法。总之让大家多看一点就多获得一点实际的价值。
一、不要一上来就开始写代码
你可能性子急，也可能早已按耐不住跃跃欲试昨天刚学会的一个编程小技巧，我想要告诉你的是，不急，收起你那磨刀霍霍的表情，在你拿到需求准备写出你第一行代码之前还有更重要的事情要做。我想怎么强调这件事情的重要性都不为过，在我以前写的自己非常满意的代码经历中，我都采用了这个方法，它能消灭原来可能会被测试提的 90% 的 Bug 单，甚至做到零缺陷，当然做到这点可能需要一个过程。
拿到需求之后你首先要问下自己对需求是不是已经充分理解了，得到肯定的回答之后，我们就可以开始了：
1) 先在你忙碌的工作中，找出你能完全掌控的一个小时时间段，这一个小时完全属于你自己，保证这一个小时不会有任何打扰，或者任何能影响到你执行不下去这个方法的打扰。要记住这一个小时非常重要，比你后面要执行的所有活动的时间都重要，它绝对值得。
2) 在第一张白纸的上方写下「该需求特性的正常流程和影响范围」，然后在白纸下方逐条开始写下该需求特性正常流程包含的内容，大概会使用到哪些库函数，会提供出哪些接口，是否会影响版本升级，是否影响资源文件，是否影响原有的接口等等。
3) 在第二张白纸上方写下「该需求特性所有的异常场景和本人以往经常会犯的一些错误点」，然后在白纸下方一条一条的开始往下写。
4) 不断重复第 2)、3) 步。
你可能会觉得这不就跟写的需求澄清材料差不多吗，我要告诉你的是这是两回事，它不是一项质量专员要求你做的质量过程活动，这是你自己和自己之间的一次深层次对话，这不需要告诉任何人，不需要向其他领域输出任何交付物，这是对自己要写出优秀代码的一次自我驱动。
一开始你可能会觉得很难，写几条就写不出来了，或者闪过「这玩意儿是不是真的有用」的念头，不用着急，起身去窗户边呼吸一口新鲜空气或者去打杯水喝，总之不要中断，除非办公室着火了不要去干让这件事继续不下去的事情。当你慢慢往下写到第 20 或者第 30 条答案的时候，你可能突然会有一种「这么隐晦的一个异常点都被我发现了，简直太牛了!」的情感涌出，这个时候你会暗暗惊呼有点难以抑制自己的兴奋，这说明你快要接近成功完成了，后面每写出来的一条都会让自己感动。记住，中间不要放弃，你坚持下去的决定会将这一个小时变成你整个需求实现当中最重要的一个小时。
二、先忘掉后面还有该死的质量活动
所有编码之外的质量活动，都是基于公司对于你写代码水平的不信任产生的。也就是说公司花了大量的钱招来质量专员、网元测试、解决方案测试这些人都是因为你没把代码写好造成的浪费。
常见一些开发人员，刚来的时候对质量专员安排的质量活动颇有微词，「我以前公司做项目根本不需要做这些东西还不是一样能把项目做完」，「这些质量活动，简直就是对编码时间的侵占」。说这些都没问题，但是你一边说着这些一边写完代码后 Bug 就乌泱乌泱上来，是不是有点不要脸? 质量专员设计的这些活动，就是为了不让你的烂代码一泻千里的冲到客户面前设计的一个个检查站，当你对于「写出好代码」什么事都没做，只想着取消这些质量活动的话，就只能理解为耍流氓了。
那么，做好质量活动就能「写出好代码」吗? 答案是不能。质量活动只是质量专员的监管手段，它既不是目标甚至也不是方法，你写代码的目标不是要满足质量活动标准，而是要追求零缺陷，也不会因为你 Wbit 测试做的好就能写出好代码。你要做的一个是「不要一上来就开始写代码」, 另外一个就是掌握尽量多的重构方法，重构思维方式，掌握重构并不一定是要对原来代码的重构，而是下笔之前就知道好代码该怎么写。
我让大家忘记质量活动，不是让大家不听质量专员的话，而是大家在写代码的时候要心中存有敬畏，代码写完之后所有的活动都是你造成的浪费，你要为消除这些浪费而竭尽全力。
三、你要记住，你写的代码是给人看的
我之前听一位同事讲他上一家公司的一件听来十分惊悚的故事，他原来公司的一位同事离职了，留下的是一堆十分复杂，看了会让人神经错乱的 C++代码，他走了之后，发现整个项目组的人没有一个人能接手得了他的模块，项目经理不得不高价加请客吃饭的方式让他过来给全项目组的人讲两天他的代码。这个家伙大有「看吧，只有我才能搞定」的「衣锦还乡」姿态。我好奇的是这个项目经理为什么没有尽早的开除他，简直就应该报警啊。
好的代码是让人看来赏心悦目的，任何能力不够或者炫技成分的增加人的阅读障碍的行为都需要被改进，你能不能三两句话就能说清楚你自己写出来的代码的脉络，当然这同样涉及到你要掌握尽量多的重构方法和重构思维方式。
另外还有一个自我评判的标准，就是你扪心自问一下，「你写了这么多代码，你曾经为之动心过吗?」你是否写完之后会忍不住的反复阅读自己写完的代码，并连连暗暗惊叹代码之美?
作为一名程序员，希望在你某天离开公司后回想起的若干个开心时刻中，有一个会是因为你面对自己刚刚出炉了一份让自己心动的代码的那份感动，而不要成为上面提到的那个「离开后，公司才知道他有多么重要」的家伙。
四、现在开始，刻意练习
你是否发现自己长期维持着「刚刚好能完成 story」的代码水平，写了好几年代码仍然会被测试人员追着屁股提单? 种种疑惑是因为代码能力的提高跟你写了多少年代码没有直接关系，你需要做的是刻意练习。
比如把我前面提到的方法反复练习，或者把你自己琢磨出来的方法分解成一项项的环节，刻意的去练习，从测试那里得到反馈，然后不断加以改进，慢慢你就会从一个整天被测试人员追着跑的人，变成发现自己很容易就能达到质量过程标准的人，再慢慢就会发现你写出来的代码测试人员越来越难发现问题，最后只要你状态好点就能经常性的写出零缺陷的代码。
其实有些道理我们貌似都知道，但是我觉得离真正懂得还差了两步，第一就是你需要亲身去经历、践行这些道理和方法，第二就是你要能够转述并让其他人也能够明白。所以最好的学习方式就是亲身经历，然后写下来分享给大家，这样才能让你真正懂得那些你原来认为懂得了其实未必懂得的道理。
