程式設計師真是一個看起來挺牛逼，實際上又挺悲催的職業。
雖然說用程式碼創造世界是一件很爽的事情，但很多時候可能某個瞬間就會被整破防，情緒一激動一上頭來那可是啥事都幹得出來！
最近做需求比較煩躁，時常讓我感覺到崩潰。有時候不僅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 被人改壞的時候，那個瞬間簡直令人抓狂。
八、當專案排期倒排時
一般大公司很喜歡按流程說話，也就是做需求做專案，都是按人力按工作量進行排期，排多少天就做多少天。
而當聽到某些產品要求對需求倒排的時候，程式設計師們的第一反應都是很反感。
因為在實際開發的過程中，可能會遇到這種未知的問題，很難透過前期的調研來充分保證開發的進度。
所以一旦專案需要倒排，最終的結果可能大多數開發質量不過關，或者就是要開始構建屎山了。
