程序員真是一個看起來挺牛逼，實際上又挺悲催的職業(yè)。

[[438558]]

雖然說用代碼創(chuàng)造世界是一件很爽的事情，但很多時候可能某個瞬間就會被整破防，情緒一激動一上頭來那可是啥事都干得出來!

最近做需求比較煩躁，時常讓我感覺到崩潰。有時候不僅app crash了，人也崩潰了。于是乎總結(jié)了一下讓程序員 crash 的 8 個瞬間。

一、當產(chǎn)品變更需求時 

作為開發(fā)的死對頭，產(chǎn)品經(jīng)理的存在一定是為了不讓程序員好過才被設(shè)立出來的吧。

就像是為了防止物種入侵一樣，產(chǎn)品的存在就是制約程序員過度繁殖，從而導致生態(tài)毀滅。

而產(chǎn)品的有效武器大概就是通過不斷地修改需求，來達到控制程序員數(shù)量的目的。

當產(chǎn)品經(jīng)理在需求群里 at 某個程序員的時候，大概率是沒好事的。所以在產(chǎn)品經(jīng)理開始 at 你，讓你修改需求時，大概是想打人的心都有了吧。

然而最可怕的是，當你辛辛苦苦百度谷歌了幾天，用了一系列非常極客的技術(shù)來實現(xiàn)了某個功能，最后產(chǎn)品在群里一句話， 「這個先不做了吧」 直接讓人破防。

不僅如此，某些產(chǎn)品還會在發(fā)版日或者發(fā)車日變更需求，明明你已經(jīng)開開心心地準備合碼下班了。

然后他告訴你把哪兒再改下，直接讓人整不會了。

二、當編譯環(huán)境又崩了 

可能很多人不知道，許多公司都有著一群基礎(chǔ)技術(shù)部門的存在。這些部門的人從來不干業(yè)務(wù)的事，但專門給業(yè)務(wù)部門搞事。

基礎(chǔ)技術(shù)部門一般會負責開發(fā)平臺的搭建，效率工具研發(fā)或者開發(fā)流程準入和把控之類的事情。

有時候，本地編譯好好的，但是在遠端就是編譯不過;又或者明明編譯過了，但是由于各種未周知的規(guī)則卡口，導致合碼流程被 block 等情況發(fā)生。

特別是當你滿懷期待地覺得成功解決了一個 bug，但是看著 pipeline 上滿是紅叉❌和感嘆號，瞬間一股子惱火就上來了。

三、當線上出現(xiàn)穩(wěn)定性問題 

對于月活日活較大的軟件來說，線上的穩(wěn)定性問題分分鐘能夠讓人崩潰，到時候不只是軟件崩潰了，人也崩潰了。

穩(wěn)定性問題算是很嚴重的事故，比如服務(wù)端下發(fā)字段的變更導致客戶端大規(guī)模 crash，或者服務(wù)端 oom 使得上下游服務(wù)全部宕機。這些一出現(xiàn)基本上都與事故報告掛鉤。

所以當程序員在摸魚劃水的時候，突然線上激增異常報警，那絕對是讓人痛不欲生的一瞬間了。

四、debug 時死活走不進斷點位置 

我們知道，找 bug 時設(shè)置斷點是非常穩(wěn)健且有效的方式。但是很多時候，斷點并不是我們以為的就能夠走到。

有些項目可能通過直接鏈接二進制文件來加快編譯速度，所以程序在運行時可能并不是編譯你打斷點所在的代碼，這就導致你以為斷點達到了，實際上根本走不到。

而還有些情況，由于 IDE 本身處于某些未知狀態(tài)，使得程序在運行時也是沒辦法斷點，這也是非常讓人惱怒的時候。

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

不知道大家有沒有經(jīng)歷過，有些 bug 一看你就明白是哪兒出了什么問題。但是等到自己去修復(fù)的時候，就是死活修不好。

看起來很簡單，但是改起來還有可能是修了 1 個 bug，但又引入了 10 個 bug。

六、當看到很久都沒維護的代碼時 

老有人說其實大公司大項目的代碼都是屎山，不僅沒有注釋，還各種亂依賴亂調(diào)用。我一直都不信，直到我也進了大廠。

不過說起來這倒是很容易理解的現(xiàn)象，畢竟大公司一起寫代碼的人太多了，很難要求別人按照統(tǒng)一的規(guī)范來開發(fā)。

經(jīng)常是你自己寫了幾段代碼后，一段時間沒有維護，過了一陣子再回來看，已經(jīng)慘不忍睹了。

當代碼成為屎山的時候，只要是寫過一行代碼，就不是無辜的。

七、當有人直接在 master 分支各種操作時 

master 分支是許多程序員可望不可及的存在，因為沒人敢輕易(并且也沒權(quán)限)直接 push 到 master 分支，甚至直接在 master 分支上做各種操作。

因為 master 分支直接影響的是整個項目，一旦出了問題可能會導致整個團隊開發(fā)效率的降低。

而特別是當你正在著急修復(fù)一個線上 bug，但是被告知 master 被人改壞的時候，那個瞬間簡直令人抓狂。

八、當項目排期倒排時 

一般大公司很喜歡按流程說話，也就是做需求做項目，都是按人力按工作量進行排期，排多少天就做多少天。

而當聽到某些產(chǎn)品要求對需求倒排的時候，程序員們的第一反應(yīng)都是很反感。

因為在實際開發(fā)的過程中，可能會遇到這種未知的問題，很難通過前期的調(diào)研來充分保證開發(fā)的進度。

所以一旦項目需要倒排，最終的結(jié)果可能大多數(shù)開發(fā)質(zhì)量不過關(guān)，或者就是要開始構(gòu)建屎山了。