本文是從 Startup Suicide – Rewriting the Code 這篇文章翻譯而來。

　　敏捷開發(fā)和最小化功能組合的好處是能持續(xù)得到客戶反饋，快速迭代，防止無用程序的產(chǎn)生。但是隨著時(shí)間的推移，如果開發(fā)人員不注意，那些為早期客戶編寫的程序會(huì)變得笨拙不堪，難以維護(hù)，無法擴(kuò)展。你最終會(huì)諷刺的得到和敏捷方法完全相反的結(jié)果。而且問題的嚴(yán)重程度會(huì)隨著公司的壯大呈指數(shù)級(jí)增長。合理的解決方案是什么？把產(chǎn)品“重構(gòu)重寫”。

　　對(duì)于處于快速變換的市場中的一個(gè)公司，這通常是走向滅亡的開始。

　　看似很合理

　　我剛好和一位朋友在加州的Palo Alto共進(jìn)午餐，他是一個(gè)科技公司的創(chuàng)始人，現(xiàn)在出任董事會(huì)主席。幾年前他聘請(qǐng)了一位職業(yè)經(jīng)理做CEO。我詢問他工作做的如何(“非常好，謝謝你的關(guān)心，五年來，公司現(xiàn)在的市值已經(jīng)達(dá)到5千萬美元”)，但他卻想跟我談一個(gè)在他腦子里想了很久的問題。“隨著公司的壯大成長，我們對(duì)市場變化和客戶反饋的反應(yīng)越來越遲鈍。雖然現(xiàn)在我們的營業(yè)收入看起來還不錯(cuò)，但如果我們不能使公司的產(chǎn)品平臺(tái)跟上客戶需求的快速變化，一兩年內(nèi)我們就可能完蛋。我們的CEO沒有技術(shù)背景，但他也為公司不能開發(fā)出他想要的一些新功能和平臺(tái)(Facebook,iPhone,Android等)而沮喪。在最近的一次董事會(huì)會(huì)議上，我們主管技術(shù)的副總裁指出問題的根源在于‘我們的程序積累了太多的技術(shù)債務(wù)‘，程序?qū)嵲谑窃阃噶耍覀儸F(xiàn)在根本沒法處理。他告訴董事會(huì)，如果想在其上做我們想要的修改，那只能重寫這個(gè)產(chǎn)品。”我的朋友補(bǔ)充道，“這聽起來很合理，所以CEO打算批準(zhǔn)這個(gè)計(jì)劃。”

　　舉槍自殺

　　“那么董事會(huì)在聽到這種魯莽的計(jì)劃后沒有做任何反應(yīng)嗎？”我問道。“沒有，”朋友回答道，憂郁的搖搖腦袋，“董事會(huì)成員都感覺這像個(gè)好主意。”

　　經(jīng)過更詳細(xì)的詢問后，我了解到他們的已經(jīng)膨脹巨大的代碼庫中還保留著公司早期在拓荒階段為客戶開發(fā)的代碼遺跡。當(dāng)初針對(duì)客戶的產(chǎn)品技術(shù)設(shè)計(jì)對(duì)于公司當(dāng)前所面對(duì)的新平臺(tái)的擴(kuò)展任務(wù)來說并不是正確的設(shè)計(jì)。

　　我提醒我的這位朋友，我從來沒有做過技術(shù)管理，所以任何我給他的建議都是來自于經(jīng)歷過這種事情的他人。

　　引誘非技術(shù)出身的CEO的美妙海妖歌聲

　　CEO在其職業(yè)生涯中至少會(huì)遇到一次這樣的“重寫”問題。如果他是被請(qǐng)來替代技術(shù)創(chuàng)始CEO的，那這個(gè)決策似乎很好定——只需要對(duì)比一下負(fù)責(zé)技術(shù)的副總裁提供的重寫(短期)進(jìn)度計(jì)劃和保留老代碼、增加新功能(長期)的進(jìn)度計(jì)劃就行了。而事實(shí)上，這是個(gè)愚蠢的決定。技術(shù)團(tuán)隊(duì)也許會(huì)知道使用舊程序的困難和問題所在，但不會(huì)知道如果重寫代碼庫將會(huì)面對(duì)多少的困難和問題。

　　曾經(jīng)經(jīng)歷過重寫噩夢或理解程序的復(fù)雜性的CEO會(huì)知道，沒有最初的技術(shù)開發(fā)團(tuán)隊(duì)，重犯以前曾經(jīng)犯過的錯(cuò)誤的幾率會(huì)非常的高。加之會(huì)引入以前不曾犯過的錯(cuò)誤，根據(jù)墨菲法則，不受約束的樂觀主義會(huì)使1年期的重寫計(jì)劃變成數(shù)年。

　　我的觀點(diǎn)是，CEO和主管技術(shù)的副總裁混淆了因果。客戶并不要求新的程序。他們要的是新的功能和平臺(tái)—— 在當(dāng)前。他們不太關(guān)心這些功能是由一堆糊涂代碼、還是由外星飛船、還是由一個(gè)新產(chǎn)品提供的。當(dāng)你在代碼重寫的過程中，那些不癡迷于架構(gòu)血統(tǒng)純度的競爭對(duì)手會(huì)擴(kuò)展他們的功能、平臺(tái)，拉攏客戶、增加市場份額。這種目前就增加這些功能、還是一兩年后再增加這些功能之間的區(qū)別代表著收入增長、還是被淘汰出局兩種境況之間的區(qū)別。

　　誰想要老的產(chǎn)品

　　也許這著手搞程序重寫最危險(xiǎn)的副作用就是當(dāng)你對(duì)舊的程序宣告死亡時(shí)卻沒有可替代的產(chǎn)品存在。當(dāng)副總裁和CEO宣告公司將來要采用新的程序時(shí)，誰還會(huì)去重視這充滿問題的舊程序呢？當(dāng)管理者說出“重寫”這個(gè)詞時(shí)，老的程序就死掉了。這后果就是，CEO沒有退路可走。如果技術(shù)副總裁的開發(fā)進(jìn)程最終是花了4年時(shí)間，而不是設(shè)想的1年，那么在這幾年期間對(duì)于系統(tǒng)新功能的增加不會(huì)有任何的進(jìn)展。

　　這是一種預(yù)測的失敗

　　我認(rèn)為這看起來像是技術(shù)副總裁藍(lán)景設(shè)計(jì)上的失敗——再加之沒有代碼重寫經(jīng)歷的CEO推波助瀾——再經(jīng)過想不出具有建設(shè)性的方案的董事會(huì)們的攪和。

　　給朋友的建議？指出市場的快速變化和競爭性，指出這種動(dòng)作會(huì)使公司致命。公司在前進(jìn)道路上的探索不應(yīng)該在時(shí)間對(duì)于市場至關(guān)重要的情況下、在客戶的需求快速轉(zhuǎn)換的情況下對(duì)代碼庫進(jìn)行重寫。重寫是在競爭周期比較長的市場條件下才可行。

　　我建議他應(yīng)該在董事會(huì)會(huì)議上把這些情況陳列清楚。要求CEO詳細(xì)列出什么時(shí)候需要什么樣的功能和平臺(tái)特征，用什么樣的手段對(duì)進(jìn)度計(jì)劃管理的風(fēng)險(xiǎn)進(jìn)行控制。弄清楚這種完全不同的技術(shù)方案是否真的可行。(是否可以只重構(gòu)目前需要追加新功能的部分模塊？在新的代碼庫上開發(fā)要求的新平臺(tái)系統(tǒng)？啟動(dòng)一個(gè)獨(dú)立的分支工作團(tuán)隊(duì)來開發(fā)新平臺(tái)？等等)

it知識(shí)庫：企業(yè)自殺行為：重寫程序，轉(zhuǎn)載需保留來源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請(qǐng)第一時(shí)間聯(lián)系我們修改或刪除，多謝。