关于问题程序员加班最狠的一次是什么情况，有多辛苦？一共有 5 位热心网友为你解答:
【1】、来自网友【丁的生活小记】的最佳回答：
因为公司失误把政府组织的入市场资格测试内容搞错，提前准备的都废了。后来熬了 5 天 4 夜，通宵搞，就每天睡 3 小时，而且睡的不安稳，脑子里都是代码，基本没睡成。后来回去后每天睡觉留冷汗，吃了一个月中药才调理过来。想想我那时候真的傻
【2】、来自网友【华为云开发者联盟】的最佳回答：
分享菊厂一位 20 万行代码哥的经历：
“你肩上扛了 20 万行代码，搞得定不？”这是我刚进华为时听到最多的一句话。
2008 年 9 月新员工培训完，我没有回西安，而是直接飞到上海承接产品。刚进上海项目组，就受到了热情的接待。
“这次西安来了多少人承接我们模块?”上海 X 模块的 PL 问我。
我愣愣地指了指自己：“就我一个”。
“什么，就你一个？我们组有 20 万行代码，赶紧反馈再加人。 ”
其实，刚出校园的我对 20 万行代码并没有太多概念，但是看到他的反应，顿感不妙。我赶紧找到在其他项目组承接产品的西安 PL，却得到了安慰，“没有想象的那么严重，你那块业务我也知道一些，我给你分析看。X 模块代码逻辑比较简单，Y 模块基本不出问题可以暂时不学，这样……这样……你只要集中把这几个模块搞定就行了。 ”
加人是不可能的，于是我的培养计划也相应有了变化。入职前两个月，我每天的任务就是读代码，下班前半小时给全组讲解。而同期其他新员工在入职一个月时已经开始处理问题单和开发需求了。第三个月中期答辩时，其他人的胶片上呈现的都是“处理了 XX 个问题单，开发了 XK 代码的需求”，而我的胶片都是模块的代码功能介绍。
学习期结束后，20 万行代码的威力很快得以体现。为了让我快速熟悉业务，项目组把活最杂的接口人工作安排给了我，负责所有的网上问题、实验室问题定位以及几个高风险模块的问题单修改。很快，我就淹没在电话和邮件的海洋里，焦头烂额。
“问题定位没？邮件都发好几个小时了，环境不保留了。”
“这个问题我分析应该是你们模块的问题，快看下，下班前没结论我就转单了。”
“怎么回事，你名下问题单怎么不见少，版本都快过不了点了。”
……
是的，我成了各个组的“焦点”，同时也开始变得焦虑，虽然每天凌晨才回公寓，依然无法阻止上窜的 DI 值（问题密度），这下该如何是好？
很快，导师和 PL 注意到了我的窘境，伸出了援助之手。看现象，找原因，和我一起分析现状，一件一件分析手头的事务，传授四象限工作心得，把眼前的事务按照四象限法则排好优先级，再一一击破，慢慢坚持一段时间后，我终于开始变得从容起来。
就是为了晚上能睡安稳觉
转正之后，我很快就遇到了第一个网上问题，并且经历了一次深刻 bug 修复过程。依稀记得那是周日，凌晨两点，电话响起时我感觉像是刚躺下就被叫醒。
“我是在一线支撑的测试经理，新版本升级报错了，需要马上解决！”
“好的，什么情况？先尝试做下这几步恢复操作，再收集下日志，我马上去公司。”一听是现网的问题，本来一脸迷糊的我瞬间清醒，这可容不得半点马虎。快速穿好衣服，打车直奔公司。
还好，问题很快定位，之前现网的服务器出现过网卡故障，客户把服务器拆封，两块网卡拔出来擦拭金手指，插进去的时候交换了插槽位置，导致网卡的 PCI 总线编号发生变化。为了防止客户私装其他网卡，引起兼容性问题，新版本代码做了强制校验，但对于这种更换网卡位置的场景，却没有考虑到。
“这谁设计的功能，画蛇添足！老版本都没问题，这是致命 bug，我要求必须回溯！”虽然功能不是我开发的，但听到电话另一端的措辞严厉，也感觉像犯了大错，不敢吱声。这次的经历，让我再后续很长一段时间，一接到网上问题电话就非常紧张。
网上问题引起的风波还没过去，修改这个网上问题的任务就落到我头上，没有想到的是这次修改也不顺利。代码很快就修改完了，但是验证时遇到一个问题。由于老型号服务器存量并不多并且前几年已停止发货，三种老型号服务器，实验室只有一台了，其他两种类型的服务器没有办法验证，怎么办？
“代码判断的就是这几个信息，你可以通过模拟打桩，之前我都是这么测的”，在老员工的指导下，我很快完成了打桩测试，但心里总有点不踏实。
结果在版本内部转测试前的预验证环节，兄弟项目组的同事找到了我，他们的一台服务器装上新版本后运行不起来。我心里“咯噔”一下，不会是那两种没有验证的服务器吧？果然，经过实机分析，发现我用的打桩模拟方法和真实的硬件还是有差异。
对于这次的修改引入，PL 特地过来辅导：“这次主要是你经验不足，不要太放在心上。不过我们也要好好想想，遇到困难，是不是尽全力了。”再次修改时，还是有一种类型的服务器没找到，感觉真的没办法了。
一大早我只好再求助导师和 PL，几小时后，PL 过来对我说：“我已经给周边几个部门打过电话了，有几台服务器可能是我们要找的，我带你去确认下。
又经过几个小时，我们终于在一个实验室的角落找到了一台落满灰尘的服务器。拍拍灰尘，一看，好家伙，这不正是我们要找的么！找电源，接线，上电，安装版本……看到版本软件顺利启动，心里悬了很久的大石头总算落地了。
“好，我们再把交换网卡顺序的场景覆盖下。”然而折腾了半天，网卡还是没拔下来。原来这个型号的服务器硬件设计上也做了防呆，卸网卡需要专用的小工具。
半个小时后，网卡终于拔了下来，PL 手上不小心被划了口子，鲜血直流，他却蛮不在意：“为了晚上能睡个安稳觉，这点小伤，值了！”
后来每当看到“打造质量口碑，构筑质量文化的教堂”时，我想说我们的质量追求真的很简单，就是为了晚上能睡安稳觉。
没有定位不了的问题
“Hello，sir……”下班刚出公司，我就接到了一个老外的电话。竖起耳朵再加上熟练的“sorry”“pardon”，才终于搞清楚了，原来是之前在 espace 上交流过的印度一线小伙，马上要去客户机房操作了，还有两个操作步骤不太清楚。
从来没跟老外通过电话的我，一时语塞，面红耳赤，嘴巴几次想张但就是张不开，到嘴边的单词，就是说不出来。
对方还在时不时的“hello? hello?”以为我不在线。哎，平时都是由 GTAC 的兄弟帮忙沟通，这下没人帮忙了，这可如何是好……不管了，管他语法怎样，突然，一句“yes”蹦出了口，慢慢地，一个单词、一个单词地蹦出，虽然磕磕巴巴，但总算可以用英语交流了。
我在电话了说了一通，反复确认对方了解了我的意思后，才放下电话。一看手心紧张得都是汗。好在总算交流完了，顿感身心舒畅了许多。
就这样，入职两三年后，一切逐渐步入正轨，不管是遇到什么难题，我似乎都可以从容应对了。
不过，现网出现的两三起未定位的 Linux 系统挂死问题，一直是大伙儿笼罩在头顶的乌云。由于使用的 Linux 是几年前外购的版本，一直未升级，维测功能比较弱。而我们作为业务软件团队，也不具备定位这种疑难问题的经验，求助公司的 Linux 团队后，仍无法定位，只能以老旧 Linux 系统问题进行了答复。
没想到，不久，在一个大 T 局点又出现了这个问题。没办法，我们只能再次求助 OS、硬件相关人员，快速组建了攻关团队。由于缺少日志，大家从软件硬件各种角度进行大胆猜测，然后在实验室进行故障注入测试，持续了一个月后，实验室连问题都没有复现，更谈不上定位，所有人都很沮丧。好在新版本软件已经合入了挂死时自动复位的自愈功能，问题影响可以将到最低。一线也接受了自愈方案。第一次的集中攻关就这样心有不甘地以失败告终。
出来混，迟早要还的。问题攻关永远不会缺席，只是来得晚而已。大半年后，中国区的一起 Linux 挂死问题拉开第二次攻关序幕。由于是晚上出的问题，一线还没来得及处理，我们请求一线保留环境，立刻协调了公司 Linux 和硬件的专家马上出差到现场定位。
“这次抓到第一现场，总算能定位了。”我心里想。可惜从一线并没有传回好消息，只是进一步确认，确实是 Linux 系统挂死了，原因还是不知道。一时，又陷入僵局。
但是攻关不能因此停滞。我们再次静下心来，继续分析日志，看代码，分析这几个问题找共同点，很快发现这几个问题涉及的设备都是在运行了快一年左右时出现了问题。莫非与单板的运行时长有关系？累积效应的故障模式？大家很快调整了攻关方向。不久，就找到一篇关于 Linux 内核内存泄露的案例，经过计算，在我们的单板上正好在一年左右 Linux 系统一些关键内存就会耗尽，出现系统挂死。真是踏破铁鞋无觅处，得来全不费工夫。
后续我参与甚至主导过多起耗时长久、艰苦卓绝的疑难问题攻关，Linux 系统挂死攻关在这些问题中不是影响最大和最紧急，但却让我受益最多。经历过这次攻关后，面对任何疑难问题，我心中都有一个信念：在我司，从来没有搞不定的事，也从来没有定位不了的问题！
2014 年到 2017 年，由于工作调整，我转战产品开发，暂时离开了网上问题处理。2018 年我又重新回归。
又是一次半夜紧急电话，我急匆匆赶到 GTAC 的攻关室处理紧急问题，一进门，又见到以前的几位老伙计：“看见你来我就放心了”。这句话一时间又让我浑身充满了力量！
以上内容来自华为内刊《华为人》，请勿转载
【3】、来自网友【小小学编程】的最佳回答：
我自己的高强度加班有 2 次，都是自己创业
- 一次是连续 4 天 3 夜，中途仅仅是眯了一下，算是几乎没睡觉
当时这是个社区平台，有过千万用户了，一个核心系统升级，然后出了点问题，不能降级，没办法只能停了这个系统加班加点修改。
改了 4 天 3 夜，中途还接了用户近 200 个电话，好多是凌晨，用户还很惊讶，说那个时间还有人接电话。
最终解决了，用户也没有流失，睡了好几天补觉。
- 一次是连续 5 天 4 夜，也是几乎没睡觉
这是一个游戏接入项目，因为对方是一个大平台，用户量特别大，要上一个流量平台，一堆游戏 cp 抢着上，所以你不抢肯定赶不上第一波，而第一波绝对是资源最足的。当时开发团队分在 3 个城市，我来统一指挥，还需要跑去平台那边，相当于是 4 个地方，最终也是赶上了。虽然游戏没赚到钱，不过这个加班是太狠了。
当然，对方平台公司更夸张，为了他们流量平台项目，整体没日没夜加班 3 个月，每天到凌晨 3 点，早上还早早 9 点就到公司了，具体公司就不说了，我们对比他们简直算是早九晚五了。
另外从业 20 年，总结：
短期冲刺加班赶节点还是有点用，长期加班的项目成功概率太低了
遇上长期的，赶紧换公司走人
【4】、来自网友【二狗 come】的最佳回答：
你们可能没听过什么叫封闭式开发。
一个团队在一个地方独立办公，吃喝拉撒都在里面。
没有上下班时间，没有周末，没有任何娱乐。就这么连着干了俩个多月。有多辛苦，可以自己体会。
当时年轻，光棍一条，无牵无挂，也没觉得特别辛苦，干完后倒是特别有成就感。作为刚入行没多久的菜鸡，三个月的时间，技术方面成长肉眼可见。
半年后跳槽，工资涨了一倍多，特别开心[呲牙][呲牙][呲牙]。
【5】、来自网友【葛小波不见了】的最佳回答：
其他程序员怎么加班我确实不太清楚，就我个人的经历，最狠的一次加班是在 2009 年 1 月 1 日。
直到现在，我都清晰的记得当时的情况。那是的我还是一个普普通通程序员，2008 年的年末，我们接手了一个新的项目，是和苏州公司合作的一个项目，因此，苏州公司派了一名项目经理全程参与。
我还记得第一天项目启动会的时候，这位项目经理说：“我希望大家能够通力合作，完成项目。放心，我不会把大家当牛当妈的使唤的。”当时，我以为这是一句玩笑话。但是后来我明白，他果然没有把我们当牛马，都快要猪狗不如了。
2008 年 12 月底，由于项目快完成是产生了需要和设计的变化，而需求和设计的变化不小，导致代码改动很大，但是项目研发阶段的 deadline 临近，本来之前就加了不少班，大家就怨声载道了，现在更是只变需求不给时间，大家就更是不开心了。Teamleader 和项目经理是因为这个问题直接怼上了，最后，项目经理很不厚道的把“我们完不成任务”的情况汇报给了集团的高级总裁。
这件事也就不可收拾了，我们这里分公司的总经理扛不住，只有要求 Teamleader 按照项目经理的要求完成，如果完不成就提前说，咱们就换人。
最后，自然就定下了一个目标，1 月 7 日前完成所有的调整，保证质量的情况下进入集成测试阶段。
于是，惨无人道的 7 天生活就开始了。
2009 年 1 月 1 日，元旦节，我们在公司加班到了凌晨 1 点多，到处都没有人了，就连对面的华为（当时华为的园区还没有修好，所以就在我们公司对面）也没人了。我们大概 10 人左右的小分队就到了附近的烧烤摊，吃了顿烧烤，然后 3 点左右回到公司继续干活。到了凌晨 5 点多的时候，扛不住趴着睡了一下，9 点多又起来接着干。
2009 年 1 月 2 日，其他项目继续放假，我们接着干，中午的时候休息一下，下午开始又一直弄到完成 11 点多，然后回家。
2009 年 1 月 3 日，整个公司还是只有我们这一个小分队，9 点多到公司后开始干活，一直干到了晚上 9 点多，然后让一些女同事先回家了，毕竟女孩子要是一个人的话，太晚回家还是有安全上的风险。我们几个男同胞又接着干，到凌晨 3 点多，然后收工回家。
2009 年 1 月 4 日，公司正常上班了，我们也按时到了公司，这时候项目其实基本是赶工的成果，功能没有全部改完，也没有经过验证，风险很大。但是，集成测试前，有一个 UT 和 Checklist 是必须完成的，这个至少需要留一天时间，也就是留给研发的时间只有不到 3 天了。
于是，1 月 4 日这天又忙到了凌晨 3 点多，还是有很多问题没有解决。无奈，大部分人都快要扛不住了，还是回家吧。
2009 年 1 月 5 日，我大概 9 点多到的公司，然后继续开始了赶工之路，时间已经不多了，这天结果一直到了晚上 2 点多，还是有很多未完成的内容，Teamleader 带着大家出去觅食，结果便利店都关门了，只有无奈返回，继续干活。一干就干到了 1 月 6 日下午 5 点多。这个时候，大部分的问题都基本处理了，只剩下一些零散的内容。所以，到了晚上 8 点多，大家就撤了。
2009 年 1 月 7 日，对整个系统进行了自测，遇到问题处理问题，由于根本没有时间做 UT 用例，所以都是想当然的进行了验证，按照 Checklist 的内容一一跑了一下。最终，在晚上 9 点多的时候完成了所有的测试并进入了集成测试阶段。
终于，我们算是按照要求达到了目标，不过也度过了惨无人道的 7 天。什么凌晨 4 点的街道，什么凌晨 5 点的朝阳，呵呵。
以上就是关于问题【程序员加班最狠的一次是什么情况，有多辛苦？】的全部回答，希望能对大家有所帮助，内容收集于网络仅供参考，如要实行请慎重，任何后果与本站无关！
