太难了！让程序员崩溃的八个瞬间

虽然说用代码创造世界是一件很爽的事情，但很多时候可能某个瞬间就会被整破防，情绪一激动一上头来那可是啥事都干得出来！

程序员真是一个看起来挺牛逼，实际上又挺悲催的职业。

虽然说用代码创造世界是一件很爽的事情，但很多时候可能某个瞬间就会被整破防，情绪一激动一上头来那可是啥事都干得出来!

最近做需求比较烦躁，时常让我感觉到崩溃。有时候不仅app crash了，人也崩溃了。于是乎总结了一下让程序员 crash 的 8 个瞬间。

一、当产品变更需求时

作为开发的死对头，产品经理的存在一定是为了不让程序员好过才被设立出来的吧。

就像是为了防止物种入侵一样，产品的存在就是制约程序员过度繁殖，从而导致生态毁灭。

而产品的有效武器大概就是通过不断地修改需求，来达到控制程序员数量的目的。

当产品经理在需求群里 at 某个程序员的时候，大概率是没好事的。所以在产品经理开始 at 你，让你修改需求时，大概是想打人的心都有了吧。

然而最可怕的是，当你辛辛苦苦百度谷歌了几天，用了一系列非常极客的技术来实现了某个功能，最后产品在群里一句话， 「这个先不做了吧」 直接让人破防。

不仅如此，某些产品还会在发版日或者发车日变更需求，明明你已经开开心心地准备合码下班了。

然后他告诉你把哪儿再改下，直接让人整不会了。

二、当编译环境又崩了

可能很多人不知道，许多公司都有着一群基础技术部门的存在。这些部门的人从来不干业务的事，但专门给业务部门搞事。

基础技术部门一般会负责开发平台的搭建，效率工具研发或者开发流程准入和把控之类的事情。

有时候，本地编译好好的，但是在远端就是编译不过;又或者明明编译过了，但是由于各种未周知的规则卡口，导致合码流程被 block 等情况发生。

特别是当你满怀期待地觉得成功解决了一个 bug，但是看着 pipeline 上满是红叉?和感叹号，瞬间一股子恼火就上来了。

三、当线上出现稳定性问题

对于月活日活较大的软件来说，线上的稳定性问题分分钟能够让人崩溃，到时候不只是软件崩溃了，人也崩溃了。

稳定性问题算是很严重的事故，比如服务端下发字段的变更导致客户端大规模 crash，或者服务端 oom 使得上下游服务全部宕机。这些一出现基本上都与事故报告挂钩。

所以当程序员在摸鱼划水的时候，突然线上激增异常报警，那绝对是让人痛不欲生的一瞬间了。

四、debug 时死活走不进断点位置

我们知道，找 bug 时设置断点是非常稳健且有效的方式。但是很多时候，断点并不是我们以为的就能够走到。

有些项目可能通过直接链接二进制文件来加快编译速度，所以程序在运行时可能并不是编译你打断点所在的代码，这就导致你以为断点达到了，实际上根本走不到。

而还有些情况，由于 IDE 本身处于某些未知状态，使得程序在运行时也是没办法断点，这也是非常让人恼怒的时候。

五、一看就懂的 bug，但就是修不好

不知道大家有没有经历过，有些 bug 一看你就明白是哪儿出了什么问题。但是等到自己去修复的时候，就是死活修不好。

看起来很简单，但是改起来还有可能是修了 1 个 bug，但又引入了 10 个 bug。

六、当看到很久都没维护的代码时

老有人说其实大公司大项目的代码都是屎山，不仅没有注释，还各种乱依赖乱调用。我一直都不信，直到我也进了大厂。

不过说起来这倒是很容易理解的现象，毕竟大公司一起写代码的人太多了，很难要求别人按照统一的规范来开发。

经常是你自己写了几段代码后，一段时间没有维护，过了一阵子再回来看，已经惨不忍睹了。

当代码成为屎山的时候，只要是写过一行代码，就不是无辜的。

七、当有人直接在 master 分支各种操作时

master 分支是许多程序员可望不可及的存在，因为没人敢轻易(并且也没权限)直接 push 到 master 分支，甚至直接在 master 分支上做各种操作。

因为 master 分支直接影响的是整个项目，一旦出了问题可能会导致整个团队开发效率的降低。

而特别是当你正在着急修复一个线上 bug，但是被告知 master 被人改坏的时候，那个瞬间简直令人抓狂。

八、当项目排期倒排时

一般大公司很喜欢按流程说话，也就是做需求做项目，都是按人力按工作量进行排期，排多少天就做多少天。

而当听到某些产品要求对需求倒排的时候，程序员们的第一反应都是很反感。

因为在实际开发的过程中，可能会遇到这种未知的问题，很难通过前期的调研来充分保证开发的进度。

所以一旦项目需要倒排，最终的结果可能大多数开发质量不过关，或者就是要开始构建屎山了。
《linux就该这么学》不错的linux自学书籍