您还未登录! 登录 | 注册 | 帮助  

您的位置: 首页 > 业务知识 > 正文

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

发表于:2021-12-06 作者:老九学堂 来源:今日头条

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

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

最近做需求比较烦躁,时常让我感觉到崩溃。有时候不仅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 被人改坏的时候,那个瞬间简直令人抓狂。

八、当项目排期倒排时

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

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

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

所以一旦项目需要倒排,最终的结果可能大多数开发质量不过关,或者就是要开始构建屎山了。