摘要：影響軟件工程進度的原因有很多種，而代碼重寫無疑是最耗費時間的變更之一。那么重寫的時候需要注意哪些細節才能把資源開銷控制到最低或可接受的程度呢？本文作者Edmond Lau在其博文中進行了闡述。以下為譯文。
前幾周，一位年輕的初創企業工程師過來尋求我有關代碼重寫的建議。其管理層希望她的團隊在4周內完成Web產品的代碼重寫工作。這已進行了3個多月，但估計還要多花2個月才能完成。她們每周的工作時間將近80多個小時，伴隨的還有一堆堆的錯誤需要更改。時間對于初創公司來說無疑是重中之重，她們該如何處理目前這個困境呢？
在今年初，我與Sam Schillace會面時也討論過有關重寫的問題，它是Box的技術副總裁，前Google Apps負責人。我向他提了一個問題，“你們工程團隊曾遇到過的最昂貴的錯誤是什么？”
我還在Google工作時，我知道Google的軟件堆棧是不支持C#的。所以當Schillace說到這里時，我很自然地問到，“當你們進行從Writely到Google Docs的轉換時，你們是不是只能從零開始？”。
“這真的真的非常痛苦。”Schillace說道。繼續奮戰12個星期后，他們最終完成了一個“令人驚訝的，奇怪的，晦澀難懂的”代碼庫。但它也最終在Google數據中心里成功運轉了，這也創造了一項紀錄——被收購后最快適應Google架構的轉換項目。如果他們不是摒棄了過多的目標，也許還不能這么快就完成。同時如果他們把更多精力放在代碼質量上，時間也會用得更多，因為需要修正一堆堆的正則表達式。相反地，他們的目標是使Writely先盡快運轉起來。