>>>  創業先鋒 眾人拾柴火焰高  >>>

簡體     傳統

影響軟件工程進度的原因有很多種，而代碼重寫無疑是最耗費時間的變更之一。那么重寫的時候需要注意哪些細節才能把資源開銷控制到最低或可接受的程度呢?本文作者Edmond Lau在其博文中進行了闡述。以下為譯文。

前幾周，一位年輕的初創企業工程師過來尋求我有關代碼重寫的建議。其管理層希望她的團隊在4周內完成Web產品的代碼重寫工作。這已進行了3個多月，但估計還要多花2個月才能完成。她們每周的工作時間將近80多個小時，伴隨的還有一堆堆的錯誤需要更改。時間對于初創公司來說無疑是重中之重，她們該如何處理目前這個困境呢?

在我職業生涯早期，也曾碰到過類似的困境——原本估計4個月完成的項目，在通過重寫后，最終用了9個月才完成。在這個痛苦的過程里，最令人抓狂的事情之一是如果市場出現新的機遇，由這引起的改動是最優先的。換言之，我們只能不斷的縫縫補補。打這以后對于項目重寫，我變得慎之又慎。

Google docs的故事

在今年初，我與Sam Schillace會面時也討論過有關重寫的問題，它是Box的技術副總裁，前Google Apps負責人。我向他提了一個問題，“你們工程團隊曾遇到過的最昂貴的錯誤是什么?”

他的回答是，“嘗試從零開始開展代碼重寫。”

Schillace的創業公司在2006年被Google收購了，他們當時的團隊有4人，產品名字是Writely即Google docs的前身。在他們發布了一個試驗性的C#原型作品后，用戶數很快就突破了50萬。加入Google后，他們收到的第一個商業任務是進行項目遷移，從而充分利用Google的架構體系以實現高容量和高擴展性。每天用戶數仍在快速增長，而他們也開始意識到之前所寫代碼的擴展瓶頸。

我還在Google工作時，我知道Google的軟件堆棧是不支持C#的。所以當Schillace說到這里時，我很自然地問到，“當你們進行Writely到Google docs的轉換時，你們是不是只能從零開始?”。

Schillace的回答是，“是的。”當他們開展重寫工作時，有個合伙人提出邊轉換邊重寫，因為如果進行徹底推翻，將極大增加工作量。Schillace并不認同。最終，他說服團隊只設置一個非常有限的重寫目標，延后其它更多的目標工作。他們定下一個清晰的目標先把系統在Google數據中心運轉起來，然后再整合12種不同的Google技術。他們花費了一個星期來調試并最終編譯成功。調試過程中，很多錯誤是由于Java和C#不同的語義表達引起的，例如==雙等號的不同含義。

“這真的真的非常痛苦。”Schillace說道。繼續奮戰12個星期后，他們最終完成了一個“令人驚訝的，奇怪的，晦澀難懂的”代碼庫。但它也最終在Google數據中心里成功運轉了，這也創造了一項紀錄—被收購后最快適應Google架構的轉換項目。如果他們不是摒棄了過多的目標，也許還不能這么快就完成。同時如果他們把更多精力放在代碼質量上，時間也會用得更多，因為需要修正一堆堆的正則表達式。相反地，他們的目標是使Writely先盡快運轉起來。

經驗教訓

以上所說并不代表重寫或推倒重寫就是絕對的對或錯。MongoDB的創始人Eliot Horowitz曾說過，“我們應該把代碼看成有3-5年的半生命周期，因此應該定期進行更新。”MapReduce，Bigtable等技術的Google架構師Jeff Dean也曾說過，“我們不妨以放大10倍的規模來設計軟件，這樣一來我們會發現它的與眾不同。”

如果我們一口氣就把整個代碼進行重寫，問題便會出現。我們會傾向于低估了開銷而高估了益處。

當我們缺乏經驗時，這是很正常的。我們沒有足夠的底氣和知識來阻止過激的進度計劃，同時也沒有劃分好先后優先級的技能。我們可能會想，一個好的工程團隊會有人能完成這一切。因此可能會認為只要按部就班、兢兢業業地去做事就萬事大吉了。

經過一段時間歷練，也不一定就能避免所有錯誤，因為評估工作仍然復雜而我們也會因為有了經驗而高估了自己。這是一個有關虛幻優越感的事例。如果你去調查100位駕駛員的駕駛水平，80%的人會認為自己的水平是中上的。如果調查100位教練，68%的人會認為自己處于前列。類似的情況在IQ測試，自我評價等測評中屢見不鮮。所以，對于軟件工程師來說，很自然會認為不能按時完成任務只會在較低水平團隊中出現，所以當真的出現超期情況時，會使得重寫工作一再拖長。

一旦重寫出現超期，我們往往會自欺欺人地認為只要多加幾天班，多開幾次會就能把進度趕上。我們也不會再去想別的途徑。一兩次或許可以僥幸通過，但長期來看這是不能持續的，“羅馬非一天建成”。

最佳的策略是全方位評估推倒重寫的價值。如果需要這樣做，例如Schillace所做的，不妨為項目設置一個有限的目標集合然后使之盡快實現并不斷完善。如果你所在的團隊陷入了一個一再延遲的項目，你需要站出來，指出商業目標和實際工作的差距—看是否需要減少過多功能，是否需要設置更切實可行的目標，是否把項目看成是沉沒成本而徹底終止。對于采取何種策略，需要實事求是，而不能生搬硬套。

原作者：Edmond Lau    本文譯者：伍昆

來源：產品中國

CocoaChina 2015-08-23 08:49:28