為毛你深陷故障驅動式開發

　　我坐在自己的工位上，盯著電腦熒屏，手撫鍵盤寫程式碼，耳朵裡不斷迴響著下面這些話：

　　“張三，快，服務起不起來了”

　　“李四，客戶反饋說儲存按鈕連續點兩次軟體就會崩潰”

　　“王五，新版本在VPN下連不上伺服器了”

　　“趙六，你提交程式碼後應用開發組的客戶端一執行就Crash”

　　“秦八，客戶說他一看別人分享的視訊盒子就黑屏”

　　“黃九，1.3.9版本的共享桌面功能沒法用了”

　　我覺得我應該帶上耳塞式耳機，邊聽Katie Melua邊寫程式碼，這樣才能遮蔽掉這些嘈雜的有關故障的申訴和對話。然而我不能，有時我也是被呼喚的那位程式設計師。

　　這種被Bug和故障抽著被迫火急火燎地旋轉的開發過程，我稱之為“故障驅動開發”。是的，故障驅動開發。和那個注著名的“測試驅動開發（TDD）”類似，然而卻具有明顯的無奈和消極。

　　對於故障驅動開發，我有兩個問題：

　　我們是怎樣陷入故障驅動開發窘境的？

　　怎麼走出故障驅動開發的泥沼？

　　你喜歡故障驅動開發這種工作模式嗎？要是你感到只有這樣自己才被需要才能彰顯自己的價值和重要性，那就此打住，別往下看了，你可以繼續去享受它帶給你的快感了，霍霍，讓快感來得更猛烈些吧。

　　我打算從三個方面來談談我們是怎樣陷入故障驅動開發的：

• 開發能力失配
• 績效導向
• 有問題再說的思想

　　一邊談原因一邊給出應對策略，不一定對，拋磚引玉吧。

　開發能力失配

　　很早之前我在另一篇文章“無Bug不生活”中說過一句話：“程式設計師在生產軟體，也在生產BUG”。這是程式設計師的宿命，再牛X的程式設計師，也註定終生與Bug共患難，不死不休。

　　然而這個殘酷的定律並不一定會導致故障驅動開發，導致故障驅動開發的，是另一個殘酷的真相：

　　大部分程式設計師的能力都配不上他所做的工作

　　舉個簡單的例子吧。假如公司的軟體是用CEF（The Chromium Embedded Framework）+ Web的形式開發的，開發團隊裡就會有這樣的基礎分工：

• 搞JS的程式設計師
• 搞C++的程式設計師

　　搞JS的程式設計師用HTML、CSS、JS等寫前端介面。

　　搞C++的程式設計師基於CEF做框架開發，還用C++實現一些核心的業務，比如私有資料傳輸協議、音視訊編解碼等。

　　那JS程式碼一定會呼叫底層的C++程式碼，C++程式碼裡的有些狀態也一定會需要反饋到JS中再展示給使用者。

　　那麼問題來了，6個寫JS的，5個寫C++的，這其中有幾個能融會貫通CEF、JS、C++的？一個？兩個？三個？還是隻有半個？

　　Ok，假如有10個能貫通JS、CEF、C++，那這個團隊的技術能力鋼鋼的啊！JS呼叫C++出的問題，JS程式設計師可以搞定；C++呼叫JS出的問題，C++程式設計師可以搞定；萬一兩者各自搞不定，交流一下也搞定了——那種你不會JS我不會C++雞同鴨講的事兒根本就不會發生。

　　上面的情況有點兒極端和理想化，但我覺得這樣的團隊，起碼有2到3個人能打通JS、CEF、C++這三層，才能保障專案的順利進行。實際情況呢……就一個，尼瑪還是半吊子！現狀呢……

　　大部分JS程式設計師覺得自己無需瞭解CEF是怎麼回事兒，也沒必要知道C++怎麼暴露介面給他，那都是C++程式設計師的事兒。大部分的C++程式設計師覺得上面有JS，我把介面做好匯出到V8 Context裡就好了。所以，到後來，大部分的Bug將會聚集在JS和C++互動這一塊或間接由這一塊引起。

　　於是，因為我們的能力不夠，接下來就會發生很多有趣的事情：

• JS遇到解決不了的問題就說是C++的介面不好
• C++接到問題就會說JS根本就不理解介面，調都調錯了
• JS說C++程式碼不穩定，有新版本也不能上
• C++說JS老抱著陳舊的版本不願意更新，Bug遲遲無法解決，新特性也沒辦法應用
• 技術經理說JS和C++之間的分層不清晰，需要不斷開會討論制定更清晰的介面
• 高層領導說整個團隊的能力不行，得找個牛逼的專案經理來盯著
• 牛逼的專案經理來了，釋出的產品還是問題多多，高層領導說得找個牛逼的測試經理來把關
• 牛逼的測試經理來了，釋出給使用者的軟體還是Bug多多，高層領導說得找個牛逼的運維經理來盯著
• 牛逼的運維經理來了，被線上系統弄得焦頭爛額，說以後測試測過的軟體要給我們先內部試用，試用後釋出出去還是問題多多……
• 於是，高層領導、運維經理、專案經理、測試經理、技術經理、質量管理經理統統都過來盯了，兩天一小會三天一大會，尼瑪，就不信這個邪，這麼多人盯著你還能把活給幹日踏了！

　　於是，壯觀的景象出現了：一堆做支援性工作的人員盯著幾個能力不匹配的開發人挖坑。下圖是非常形象的說明：

阿猿在挖坑

　　然而這並沒什麼卵用！程式設計師照樣可以在你眼皮底下搞出Bug來，原因很簡單——臣妾做不到啊！

　　【應對策略】

　　說起來比較簡單，找幾個牛逼的程式設計師，把那些做支援性工作的人都趕走（留一個搞搞服務，需要裝置給裝置需要安慰給安慰），這樣基本就OK了。

　　假如招人很難，那管理者就要注意創造寬鬆、積極的環境，讓我們的程式猿們願意拋開不合理的基於技能的分工，把自己培養成一專多能的猿中之王。

　　3個能力與需求匹配的程式設計師的生產率，超過錯配的10個人。

　績效導向

　　你知道技術經理、專案經理、部門經理的績效是怎麼評估的？你知道程式設計師的績效是怎麼評估的？裡面都有什麼問題？建議看看我之前釋出的文章——“績效/加薪/年終獎，虐你如初戀”。

　　對於技術管理、專案管理類的一線管理者，他們所帶的隊伍乾的活越多，並行的工作越多，釋出的版本越多，交付得越快，他們的績效就越好。

　　由於這樣的績效導向，很多團隊的技術經理、專案經理實際上就容易重視數量和速度，忽視質量和可維護性，最終就會導致只管拉屎不管擦屁股的管理作風。尼瑪，先上了再說，先滿足領導的時間要求再說。

　　所以，技術方案選擇，快定快定快快定，差不多就行了。架構設計，快定快定快快定，趕緊開始寫程式碼吧。開發進度，今天20%明天50%後天就90%了。當一個程式設計師憂心忡忡地表示技術方案不合理、架構設計存在缺陷、程式碼寫得太快又髒又亂深海潛雷又多時，得到的答案往往是“來不及了，後面有時間再重構再完善吧”。

　　這要不出問題，就真日了鬼了。

　　所以，後面你就看吧，拆東牆補西牆，這邊貼膏藥，那邊打補丁，服務不穩定就再寫個監控服務管著它，記憶體洩露經常把伺服器搞死就定期重啟，今天Hotfix，明天緊急修復……作為程式設計師，你要不被折騰操折騰走那就是有人燒香保佑你了。

　　God Bless You！

　　【解決方案】

　　要從管理層就貫徹下面的原則：

　　在一段時間內，做好做精一件事。

　　要用資料讓管理層明白：

　　匆匆上馬的軟體產品的維護成本遠遠大於（通常數倍於）開發成本，求快反慢，求廉反貴！

　　調整績效指標，引導績效指向：

　　要把軟體釋出後的執行情況作為績效考核的一個重要參考因素。

　有問題再說的思想

　　你有沒有過這樣的經歷：

• 明知道程式碼有潛在問題也懶花時間得改
• 明知道貼塊膏藥打個補丁只能暫時規避問題可還是那麼做了
• 明知道張三的程式碼邏輯上有個漏洞還是睜一隻眼閉一隻眼算了
• 明明有時間把某個模組的程式碼梳理一下重構一下想想沒什麼外在回報就放棄了
• 明明看著需求莫名其妙還是接受了
• 明明某個介面的UI設計反人類還是從了
• 寫完程式碼編譯通過就扔給測試去測

　　這都是很常見的現象，很多程式設計師都遇到過，都想想算了，先這樣吧，有問題再說，反正有的是理由：

• 時間緊任務急，考慮不了那麼細
• 別人定的，我管不了那麼多，幹好我自己的就成了
• 出力不討好，不定還被誰不待見
• 反正回頭還會Bug迴歸，先往前趕進度要緊
• 對得起老闆給我的這麼點錢就行了

　　一件事你不想做不想做好，總是找得到理由的。然而，在軟體開發這件事上，你總得有一個環節需要認真，而且這個環節越靠前越好，越往後付出的代價越大效率越差效果也差。

　　要麼你在需求分析時認真，要麼你在設計和編碼時認真，要麼你在測試時認真，要麼你在運維時認證，要麼你在處理故障時認真……你總需要在一個地方認真，假如你什麼地方都不認真，那就只好認真找工作了……

　　然而《無間道2》裡的倪永孝早看穿了這一切：

出來混遲早要還

　　然而混日子的還是很多，當一天和尚不撞一天鐘的還是很多……要知道，你現在怎麼做，代表著你以後怎麼活，你的將來，是你現在的選擇造就的。

　　雖然環境拖人下墜的慣性很強，雖然選擇很難，雖然改變自己萬般不易，然而《英雄本色2》裡的龍四還是回頭了：

　　選擇做一個好人

　　我想要說的是，對技術要有一顆嚴謹和敬畏的心，想清楚了再幹，幹好了再給別人用。對技術負責，對產品負責，就是對你自己負責。