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

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

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

　　看似很合理

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

　　舉槍自殺

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

　　經過更詳細的詢問后，我了解到他們的已經膨脹巨大的代碼庫中還保留著公司早期在拓荒階段為客戶開發的代碼遺跡。當初針對客戶的產品技術設計對于公司當前所面對的新平臺的擴展任務來說并不是正確的設計。

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

　　引誘非技術出身的CEO的美妙海妖歌聲

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

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

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

　　誰想要老的產品

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

　　這是一種預測的失敗

　　我認為這看起來像是技術副總裁藍景設計上的失敗——再加之沒有代碼重寫經歷的CEO推波助瀾——再經過想不出具有建設性的方案的董事會們的攪和。

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

　　我建議他應該在董事會會議上把這些情況陳列清楚。要求CEO詳細列出什么時候需要什么樣的功能和平臺特征，用什么樣的手段對進度計劃管理的風險進行控制。弄清楚這種完全不同的技術方案是否真的可行。(是否可以只重構目前需要追加新功能的部分模塊？在新的代碼庫上開發要求的新平臺系統？啟動一個獨立的分支工作團隊來開發新平臺？等等)