摘要：影響軟件工程進(jìn)度的原因有很多種，而代碼重寫無疑是耗費(fèi)時(shí)間的變更之一。那么重寫的時(shí)候需要注意哪些細(xì)節(jié)才能把資源開銷控制到低或可接受的程度呢？
影響軟件工程進(jìn)度的原因有很多種，而代碼重寫無疑是耗費(fèi)時(shí)間的變更之一。那么重寫的時(shí)候需要注意哪些細(xì)節(jié)才能把資源開銷控制到低或可接受的程度呢？本文作者Edmond Lau在其博文中進(jìn)行了闡述。以下為譯文。
前幾周，一位年輕的初創(chuàng)企業(yè)工程師過來尋求我有關(guān)代碼重寫的建議。其管理層希望她的團(tuán)隊(duì)在4周內(nèi)完成Web產(chǎn)品的代碼重寫工作。這已進(jìn)行了3個(gè)多月，但估計(jì)還要多花2個(gè)月才能完成。她們每周的工作時(shí)間將近80多個(gè)小時(shí)，伴隨的還有一堆堆的錯(cuò)誤需要更改。時(shí)間對(duì)于初創(chuàng)公司來說無疑是重中之重，她們該如何處理目前這個(gè)困境呢？
在我職業(yè)生涯早期，也曾碰到過類似的困境——原本估計(jì)4個(gè)月完成的項(xiàng)目，在通過重寫后，終用了9個(gè)月才完成。在這個(gè)痛苦的過程里，令人抓狂的事情之一是如果市場出現(xiàn)新的機(jī)遇，由這引起的改動(dòng)是優(yōu)先的。換言之，我們只能不斷的縫縫補(bǔ)補(bǔ)。打這以后對(duì)于項(xiàng)目重寫，我變得慎之又慎。
Google Docs的故事
在今年初，我與Sam Schillace會(huì)面時(shí)也討論過有關(guān)重寫的問題，它是Box的技術(shù)副總裁，前Google Apps負(fù)責(zé)人。我向他提了一個(gè)問題，“你們工程團(tuán)隊(duì)曾遇到過的昂貴的錯(cuò)誤是什么？”
他的回答是，“嘗試從零開始開展代碼重寫。”
Schillace的創(chuàng)業(yè)公司在2006年被Google收購了，他們當(dāng)時(shí)的團(tuán)隊(duì)有4人，產(chǎn)品名字是Writely即Google Docs的前身。在他們發(fā)布了一個(gè)試驗(yàn)性的C#原型作品后，用戶數(shù)很快就突破了50萬。加入Google后，他們收到的個(gè)商業(yè)任務(wù)是進(jìn)行項(xiàng)目遷移，從而充分利用Google的架構(gòu)體系以實(shí)現(xiàn)高容量和高擴(kuò)展性。每天用戶數(shù)仍在快速增長，而他們也開始意識(shí)到之前所寫代碼的擴(kuò)展瓶頸。
我還在Google工作時(shí)，我知道Google的軟件堆棧是不支持C#的。所以當(dāng)Schillace說到這里時(shí)，我很自然地問到，“當(dāng)你們進(jìn)行Writely到Google Docs的轉(zhuǎn)換時(shí)，你們是不是只能從零開始？”。
Schillace的回答是，“是的。”當(dāng)他們開展重寫工作時(shí)，有個(gè)合伙人提出邊轉(zhuǎn)換邊重寫，因?yàn)槿绻M(jìn)行徹底推翻，將極大增加工作量。Schillace并不認(rèn)同。終，他說服團(tuán)隊(duì)只設(shè)置一個(gè)非常有限的重寫目標(biāo)，延后其它更多的目標(biāo)工作。他們定下一個(gè)清晰的目標(biāo)先把系統(tǒng)在Google數(shù)據(jù)中心運(yùn)轉(zhuǎn)起來，然后再整合12種不同的Google技術(shù)。他們花費(fèi)了一個(gè)星期來調(diào)試并終編譯成功。調(diào)試過程中，很多錯(cuò)誤是由于Java和C#不同的語義表達(dá)引起的，例如==雙等號(hào)的不同含義。
“這真的真的非常痛苦?！盨chillace說道。繼續(xù)奮戰(zhàn)12個(gè)星期后，他們終完成了一個(gè)“令人驚訝的，奇怪的，晦澀難懂的”代碼庫。但它也終在Google數(shù)據(jù)中心里成功運(yùn)轉(zhuǎn)了，這也創(chuàng)造了一項(xiàng)紀(jì)錄—被收購后快適應(yīng)Google架構(gòu)的轉(zhuǎn)換項(xiàng)目。如果他們不是摒棄了過多的目標(biāo)，也許還不能這么快就完成。同時(shí)如果他們把更多精力放在代碼質(zhì)量上，時(shí)間也會(huì)用得更多，因?yàn)樾枰拚欢讯训恼齽t表達(dá)式。相反地，他們的目標(biāo)是使Writely先盡快運(yùn)轉(zhuǎn)起來。
經(jīng)驗(yàn)教訓(xùn)
以上所說并不代表重寫或推倒重寫就是絕對(duì)的對(duì)或錯(cuò)。MongoDB的創(chuàng)始人Eliot Horowitz曾說過，“我們應(yīng)該把代碼看成有3-5年的半生命周期，因此應(yīng)該定期進(jìn)行更新?！盡apReduce，Bigtable等技術(shù)的Google架構(gòu)師Jeff Dean也曾說過，“我們不妨以放大10倍的規(guī)模來設(shè)計(jì)軟件，這樣一來我們會(huì)發(fā)現(xiàn)它的與眾不同?！?/p>
如果我們一口氣就把整個(gè)代碼進(jìn)行重寫，問題便會(huì)出現(xiàn)。我們會(huì)傾向于低估了開銷而高估了益處。
當(dāng)我們?nèi)狈?jīng)驗(yàn)時(shí)，這是很正常的。我們沒有足夠的底氣和知識(shí)來阻止過激的進(jìn)度計(jì)劃，同時(shí)也沒有劃分好先后優(yōu)先級(jí)的技能。我們可能會(huì)想，一個(gè)好的工程團(tuán)隊(duì)會(huì)有人能完成這一切。因此可能會(huì)認(rèn)為只要按部就班、兢兢業(yè)業(yè)地去做事就萬事大吉了。
經(jīng)過一段時(shí)間歷練，也不一定就能避免所有錯(cuò)誤，因?yàn)樵u(píng)估工作仍然復(fù)雜而我們也會(huì)因?yàn)橛辛私?jīng)驗(yàn)而高估了自己。這是一個(gè)有關(guān)虛幻優(yōu)越感的事例。如果你去調(diào)查100位駕駛員的駕駛水平，80%的人會(huì)認(rèn)為自己的水平是中上的。如果調(diào)查100位教練，68%的人會(huì)認(rèn)為自己處于前列。類似的情況在IQ測試，自我評(píng)價(jià)等測評(píng)中屢見不鮮。所以，對(duì)于軟件工程師來說，很自然會(huì)認(rèn)為不能按時(shí)完成任務(wù)只會(huì)在較低水平團(tuán)隊(duì)中出現(xiàn)，所以當(dāng)真的出現(xiàn)超期情況時(shí)，會(huì)使得重寫工作一再拖長。
一旦重寫出現(xiàn)超期，我們往往會(huì)自欺欺人地認(rèn)為只要多加幾天班，多開幾次會(huì)就能把進(jìn)度趕上。我們也不會(huì)再去想別的途徑。一兩次或許可以僥幸通過，但長期來看這是不能持續(xù)的，“羅馬非一天建成”。
佳的策略是全方位評(píng)估推倒重寫的價(jià)值。如果需要這樣做，例如Schillace所做的，不妨為項(xiàng)目設(shè)置一個(gè)有限的目標(biāo)集合然后使之盡快實(shí)現(xiàn)并不斷完善。如果你所在的團(tuán)隊(duì)陷入了一個(gè)一再延遲的項(xiàng)目，你需要站出來，指出商業(yè)目標(biāo)和實(shí)際工作的差距—看是否需要減少過多功能，是否需要設(shè)置更切實(shí)可行的目標(biāo)，是否把項(xiàng)目看成是沉沒成本而徹底終止。對(duì)于采取何種策略，需要實(shí)事求是，而不能生搬硬套。（編譯：伍昆 責(zé)編：張紅月）
原文來自：The Effective Engineer
本站文章版權(quán)歸原作者及原出處所有 。內(nèi)容為作者個(gè)人觀點(diǎn)， 并不代表本站贊同其觀點(diǎn)和對(duì)其真實(shí)性負(fù)責(zé)，本站只提供參考并不構(gòu)成任何投資及應(yīng)用建議。本站是一個(gè)個(gè)人學(xué)習(xí)交流的平臺(tái)，網(wǎng)站上部分文章為轉(zhuǎn)載，并不用于任何商業(yè)目的，我們已經(jīng)盡可能的對(duì)作者和來源進(jìn)行了通告，但是能力有限或疏忽，造成漏登，請(qǐng)及時(shí)聯(lián)系我們，我們將根據(jù)著作權(quán)人的要求，立即更正或者刪除有關(guān)內(nèi)容。本站擁有對(duì)此聲明的最終解釋權(quán)。
