在我職業生涯早期，也曾碰到過類似的困境——原本估計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所做的，不妨為專案設定一個有限的目標集合然後使之儘快實現並不斷完善。如果你所在的團隊陷入了一個一再延遲的專案，你需要站出來，指出商業目標和實際工作的差距—看是否需要減少過多功能，是否需要設定更切實可行的目標，是否把專案看成是沉沒成本而徹底終止。對於採取何種策略，需要實事求是，而不能生搬硬套。（編譯：伍昆 責編：張紅月）
來自：CSDN
相關閱讀
評論(1)