焦油坑

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

• “張三，快，服務(wù)起不起來(lái)了”
• “李四，客戶反饋說(shuō)保存按鈕連續(xù)點(diǎn)兩次軟件就會(huì)崩潰”
• “王五，新版本在VPN下連不上服務(wù)器了”
• “趙六，你提交代碼后應(yīng)用開發(fā)組的客戶端一運(yùn)行就Crash”
• “秦八，客戶說(shuō)他一看別人分享的視頻盒子就黑屏”
• “黃九，1.3.9版本的共享桌面功能沒(méi)法用了”

我覺(jué)得我應(yīng)該帶上耳塞式耳機(jī)，邊聽Katie Melua邊寫代碼，這樣才能屏蔽掉這些嘈雜的有關(guān)故障的申訴和對(duì)話。然而我不能，有時(shí)我也是被呼喚的那位程序員。

這種被Bug和故障抽著被迫火急火燎地旋轉(zhuǎn)的開發(fā)過(guò)程，我稱之為“故障驅(qū)動(dòng)開發(fā)”。是的，故障驅(qū)動(dòng)開發(fā)。和那個(gè)注著名的“測(cè)試驅(qū)動(dòng)開發(fā)（TDD）”類似，然而卻具有明顯的無(wú)奈和消極。

對(duì)于故障驅(qū)動(dòng)開發(fā)，我有兩個(gè)問(wèn)題：

1. 我們是怎樣陷入故障驅(qū)動(dòng)開發(fā)窘境的？
2. 怎么走出故障驅(qū)動(dòng)開發(fā)的泥沼？

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

我打算從三個(gè)方面來(lái)談?wù)勎覀兪窃鯓酉萑牍收向?qū)動(dòng)開發(fā)的：

• 開發(fā)能力失配
• 績(jī)效導(dǎo)向
• 有問(wèn)題再說(shuō)的思想

一邊談原因一邊給出應(yīng)對(duì)策略，不一定對(duì)，拋磚引玉吧。

開發(fā)能力失配

很早之前我在另一篇文章“無(wú)Bug不生活”（點(diǎn)擊閱讀原文可以查看）中說(shuō)過(guò)一句話：“程序員在生產(chǎn)軟件，也在生產(chǎn)BUG”。這是程序員的宿命，再牛X的程序員，也注定終生與Bug共患難，不死不休。

然而這個(gè)殘酷的定律并不一定會(huì)導(dǎo)致故障驅(qū)動(dòng)開發(fā)，導(dǎo)致故障驅(qū)動(dòng)開發(fā)的，是另一個(gè)殘酷的真相：

大部分程序員的能力都配不上他所做的工作

舉個(gè)簡(jiǎn)單的例子吧。假如公司的軟件是用CEF（The Chromium Embedded Framework） Web的形式開發(fā)的，開發(fā)團(tuán)隊(duì)里就會(huì)有這樣的基礎(chǔ)分工：

• 搞JS的程序員
• 搞C 的程序員

搞JS的程序員用HTML、CSS、JS等寫前端界面。

搞C 的程序員基于CEF做框架開發(fā)，還用C 實(shí)現(xiàn)一些核心的業(yè)務(wù)，比如私有數(shù)據(jù)傳輸協(xié)議、音視頻編解碼等。

那JS代碼一定會(huì)調(diào)用底層的C 代碼，C 代碼里的有些狀態(tài)也一定會(huì)需要反饋到JS中再展示給用戶。

那么問(wèn)題來(lái)了，6個(gè)寫JS的，5個(gè)寫C 的，這其中有幾個(gè)能融會(huì)貫通CEF、JS、C 的？一個(gè)？?jī)蓚€(gè)？三個(gè)？還是只有半個(gè)？

Ok，假如有10個(gè)能貫通JS、CEF、C ，那這個(gè)團(tuán)隊(duì)的技術(shù)能力鋼鋼的??！JS調(diào)用C 出的問(wèn)題，JS程序員可以搞定；C 調(diào)用JS出的問(wèn)題，C 程序員可以搞定；萬(wàn)一兩者各自搞不定，交流一下也搞定了——那種你不會(huì)JS我不會(huì)C 雞同鴨講的事兒根本就不會(huì)發(fā)生。

上面的情況有點(diǎn)兒極端和理想化，但我覺(jué)得這樣的團(tuán)隊(duì)，起碼有2到3個(gè)人能打通JS、CEF、C 這三層，才能保障項(xiàng)目的順利進(jìn)行。實(shí)際情況呢……就一個(gè)，尼瑪還是半吊子！現(xiàn)狀呢……

大部分JS程序員覺(jué)得自己無(wú)需了解CEF是怎么回事兒，也沒(méi)必要知道C 怎么暴露接口給他，那都是C 程序員的事兒。大部分的C 程序員覺(jué)得上面有JS，我把接口做好導(dǎo)出到V8 Context里就好了。所以，到后來(lái)，大部分的Bug將會(huì)聚集在JS和C 交互這一塊或間接由這一塊引起。

于是，因?yàn)槲覀兊哪芰Σ粔?，接下?lái)就會(huì)發(fā)生很多有趣的事情：

• JS遇到解決不了的問(wèn)題就說(shuō)是C 的接口不好
• C 接到問(wèn)題就會(huì)說(shuō)JS根本就不理解接口，調(diào)都調(diào)錯(cuò)了
• JS說(shuō)C 代碼不穩(wěn)定，有新版本也不能上
• C 說(shuō)JS老抱著陳舊的版本不愿意更新，Bug遲遲無(wú)法解決，新特性也沒(méi)辦法應(yīng)用
• 技術(shù)經(jīng)理說(shuō)JS和C 之間的分層不清晰，需要不斷開會(huì)討論制定更清晰的接口
• 高層領(lǐng)導(dǎo)說(shuō)整個(gè)團(tuán)隊(duì)的能力不行，得找個(gè)牛逼的項(xiàng)目經(jīng)理來(lái)盯著
• 牛逼的項(xiàng)目經(jīng)理來(lái)了，發(fā)布的產(chǎn)品還是問(wèn)題多多，高層領(lǐng)導(dǎo)說(shuō)得找個(gè)牛逼的測(cè)試經(jīng)理來(lái)把關(guān)
• 牛逼的測(cè)試經(jīng)理來(lái)了，發(fā)布給用戶的軟件還是Bug多多，高層領(lǐng)導(dǎo)說(shuō)得找個(gè)牛逼的運(yùn)維經(jīng)理來(lái)盯著
• 牛逼的運(yùn)維經(jīng)理來(lái)了，被線上系統(tǒng)弄得焦頭爛額，說(shuō)以后測(cè)試測(cè)過(guò)的軟件要給我們先內(nèi)部試用，試用后發(fā)布出去還是問(wèn)題多多……
• 于是，高層領(lǐng)導(dǎo)、運(yùn)維經(jīng)理、項(xiàng)目經(jīng)理、測(cè)試經(jīng)理、技術(shù)經(jīng)理、質(zhì)量管理經(jīng)理統(tǒng)統(tǒng)都過(guò)來(lái)盯了，兩天一小會(huì)三天一大會(huì)，尼瑪，就不信這個(gè)邪，這么多人盯著你還能把活給干日踏了！

于是，壯觀的景象出現(xiàn)了：一堆做支持性工作的人員盯著幾個(gè)能力不匹配的開發(fā)人挖坑。下圖是非常形象的說(shuō)明：

阿猿在挖坑

然而這并沒(méi)什么卵用！程序員照樣可以在你眼皮底下搞出Bug來(lái)，原因很簡(jiǎn)單——臣妾做不到?。?/p>

• 【應(yīng)對(duì)策略】

說(shuō)起來(lái)比較簡(jiǎn)單，找?guī)讉€(gè)牛逼的程序員，把那些做支持性工作的人都趕走（留一個(gè)搞搞服務(wù)，需要設(shè)備給設(shè)備需要安慰給安慰），這樣基本就OK了。

假如招人很難，那管理者就要注意創(chuàng)造寬松、積極的環(huán)境，讓我們的程序猿們?cè)敢鈷侀_不合理的基于技能的分工，把自己培養(yǎng)成一專多能的猿中之王。

3個(gè)能力與需求匹配的程序員的生產(chǎn)率，超過(guò)錯(cuò)配的10個(gè)人。

績(jī)效導(dǎo)向

你知道技術(shù)經(jīng)理、項(xiàng)目經(jīng)理、部門經(jīng)理的績(jī)效是怎么評(píng)估的？你知道程序員的績(jī)效是怎么評(píng)估的？里面都有什么問(wèn)題？建議看看我之前發(fā)布的文章——“績(jī)效/加薪/年終獎(jiǎng)，虐你如初戀”。

對(duì)于技術(shù)管理、項(xiàng)目管理類的一線管理者，他們所帶的隊(duì)伍干的活越多，并行的工作越多，發(fā)布的版本越多，交付得越快，他們的績(jī)效就越好。

由于這樣的績(jī)效導(dǎo)向，很多團(tuán)隊(duì)的技術(shù)經(jīng)理、項(xiàng)目經(jīng)理實(shí)際上就容易重視數(shù)量和速度，忽視質(zhì)量和可維護(hù)性，最終就會(huì)導(dǎo)致只管拉屎不管擦屁股的管理作風(fēng)。尼瑪，先上了再說(shuō)，先滿足領(lǐng)導(dǎo)的時(shí)間要求再說(shuō)。

所以，技術(shù)方案選擇，快定快定快快定，差不多就行了。架構(gòu)設(shè)計(jì)，快定快定快快定，趕緊開始寫代碼吧。開發(fā)進(jìn)度，今天20%明天50%后天就90%了。當(dāng)一個(gè)程序員憂心忡忡地表示技術(shù)方案不合理、架構(gòu)設(shè)計(jì)存在缺陷、代碼寫得太快又臟又亂深海潛雷又多時(shí)，得到的答案往往是“來(lái)不及了，后面有時(shí)間再重構(gòu)再完善吧”。

這要不出問(wèn)題，就真日了鬼了。

所以，后面你就看吧，拆東墻補(bǔ)西墻，這邊貼膏藥，那邊打補(bǔ)丁，服務(wù)不穩(wěn)定就再寫個(gè)監(jiān)控服務(wù)管著它，內(nèi)存泄露經(jīng)常把服務(wù)器搞死就定期重啟，今天Hotfix，明天緊急修復(fù)……作為程序員，你要不被折騰操折騰走那就是有人燒香保佑你了。

God Bless You！

• 【解決方案】

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

在一段時(shí)間內(nèi)，做好做精一件事。

要用數(shù)據(jù)讓管理層明白：

匆匆上馬的軟件產(chǎn)品的維護(hù)成本遠(yuǎn)遠(yuǎn)大于（通常數(shù)倍于）開發(fā)成本，求快反慢，求廉反貴！

調(diào)整績(jī)效指標(biāo)，引導(dǎo)績(jī)效指向：

要把軟件發(fā)布后的運(yùn)行情況作為績(jī)效考核的一個(gè)重要參考因素。

有問(wèn)題再說(shuō)的思想

你有沒(méi)有過(guò)這樣的經(jīng)歷：

• 明知道代碼有潛在問(wèn)題也懶花時(shí)間得改
• 明知道貼塊膏藥打個(gè)補(bǔ)丁只能暫時(shí)規(guī)避問(wèn)題可還是那么做了
• 明知道張三的代碼邏輯上有個(gè)漏洞還是睜一只眼閉一只眼算了
• 明明有時(shí)間把某個(gè)模塊的代碼梳理一下重構(gòu)一下想想沒(méi)什么外在回報(bào)就放棄了
• 明明看著需求莫名其妙還是接受了
• 明明某個(gè)界面的UI設(shè)計(jì)反人類還是從了
• 寫完代碼編譯通過(guò)就扔給測(cè)試去測(cè)

這都是很常見的現(xiàn)象，很多程序員都遇到過(guò)，都想想算了，先這樣吧，有問(wèn)題再說(shuō)，反正有的是理由：

• 時(shí)間緊任務(wù)急，考慮不了那么細(xì)
• 別人定的，我管不了那么多，干好我自己的就成了
• 出力不討好，不定還被誰(shuí)不待見
• 反正回頭還會(huì)Bug回歸，先往前趕進(jìn)度要緊
• 對(duì)得起老板給我的這么點(diǎn)錢就行了

一件事你不想做不想做好，總是找得到理由的。然而，在軟件開發(fā)這件事上，你總得有一個(gè)環(huán)節(jié)需要認(rèn)真，而且這個(gè)環(huán)節(jié)越靠前越好，越往后付出的代價(jià)越大效率越差效果也差。

要么你在需求分析時(shí)認(rèn)真，要么你在設(shè)計(jì)和編碼時(shí)認(rèn)真，要么你在測(cè)試時(shí)認(rèn)真，要么你在運(yùn)維時(shí)認(rèn)證，要么你在處理故障時(shí)認(rèn)真……你總需要在一個(gè)地方認(rèn)真，假如你什么地方都不認(rèn)真，那就只好認(rèn)真找工作了……

然而《無(wú)間道2》里的倪永孝早看穿了這一切：

出來(lái)混遲早要還

然而混日子的還是很多，當(dāng)一天和尚不撞一天鐘的還是很多……要知道，你現(xiàn)在怎么做，代表著你以后怎么活，你的將來(lái)，是你現(xiàn)在的選擇造就的。

雖然環(huán)境拖人下墜的慣性很強(qiáng)，雖然選擇很難，雖然改變自己萬(wàn)般不易，然而《英雄本色2》里的龍四還是回頭了：

選擇做一個(gè)好人

我想要說(shuō)的是，對(duì)技術(shù)要有一顆嚴(yán)謹(jǐn)和敬畏的心，想清楚了再干，干好了再給別人用。對(duì)技術(shù)負(fù)責(zé)，對(duì)產(chǎn)品負(fù)責(zé)，就是對(duì)你自己負(fù)責(zé)。

相關(guān)閱讀：

• 績(jī)效/加薪/年終獎(jiǎng)，虐你如初戀
• 怎樣成為技術(shù)達(dá)人
• 大齡程序員的未來(lái)在何方