亚洲一区在线观看免费_ 十年程序員血與淚：千萬(wàn)別重構代碼！

重寫(xiě)代碼消耗了12個(gè)月！

我們從頭開(kāi)始重寫(xiě)代碼浪費的時(shí)間。

你能想象在軟件行業(yè)，12個(gè)月的時(shí)間沒(méi)有任何新產(chǎn)品推出，沒(méi)有任何新版本更新嗎？

真的，我不由自主地問(wèn)自己這個(gè)問(wèn)題：

在這個(gè)快速發(fā)展的世界里，12月的時(shí)間能讓我們做多少事情？

“2015年1月20日，星期二，下午5:10，AntiMalware軟件終于進(jìn)入了第一次公測?！?/span>

經(jīng)過(guò)幾十個(gè)小時(shí)的不眠不休后，第一個(gè)版本的軟件說(shuō)明書(shū)終于發(fā)布到了網(wǎng)站上，這標志著(zhù)我們的新旅程的開(kāi)始。

我在一家為企業(yè)和終端用戶(hù)提供安全軟件的小型網(wǎng)絡(luò )安全公司工作。我們開(kāi)發(fā)的軟件保護用戶(hù)免受惡意軟件的侵害。如果用戶(hù)的電腦被惡意軟件感染，我們的軟件會(huì )幫助他們清理。AntiMalware就是其中一個(gè)軟件。

第一個(gè)測試版收到的反饋令人鼓舞。我們有四個(gè)開(kāi)發(fā)人員為這個(gè)產(chǎn)品工作，不斷地修復Bug, 改進(jìn)產(chǎn)品功能，推出新版本。

第一個(gè)穩定版本

經(jīng)過(guò)兩個(gè)月的糾錯、功能改進(jìn)和編碼工作，我們發(fā)布了AntiMalware的第一個(gè)穩定版本。

看看用戶(hù)怎么說(shuō)？

大多數用戶(hù)的反饋都很好，他們喜歡這個(gè)產(chǎn)品。這讓我們的團隊深受鼓舞，大家卯足了勁地干活，來(lái)改進(jìn)這個(gè)產(chǎn)品的核心功能。

進(jìn)入市場(chǎng)

2016—2017。

大風(fēng)暴來(lái)臨前的黃金歲月。

AntiMalware軟件處于它的最佳期，它成為了我們的旗艦產(chǎn)品。用戶(hù)紛紛把它推薦給他們的朋友們。所有與安全相關(guān)的博客和論壇也都在推薦這個(gè)軟件。它成了拯救被惡意軟件感染的用戶(hù)的首選軟件。

下載、安裝、銷(xiāo)售，一切都向好的方向發(fā)展，用戶(hù)群在幾個(gè)月內迅速增長(cháng)。創(chuàng )始人很高興，團隊也是如此。大家都在想：“我們做到了！像其他大公司一樣，我們認為我們創(chuàng )造了自己的成功故事?！?/span>

新機遇（至少我們這樣認為）：進(jìn)入企業(yè)市場(chǎng)

后來(lái)，公司決定進(jìn)入企業(yè)市場(chǎng)。一個(gè)新的企業(yè)產(chǎn)品團隊成立了。原產(chǎn)品負責人離開(kāi)了公司，我們的CTO接任成為新的產(chǎn)品負責人（這是災難的開(kāi)始，稍后我會(huì )解釋?zhuān)?/span>

一些開(kāi)發(fā)人員離開(kāi)了公司，但沒(méi)有什么影響。我們把每件事情處理得很好，AntiMalware軟件仍然是市場(chǎng)上最好的選擇。

好日子結束, 麻煩開(kāi)始

正如我前面所說(shuō)，我們的CTO成了AntiMalware的產(chǎn)品負責人，他需要處理AntiMalware的方方面面。而且他還是該軟件的首席開(kāi)發(fā)人員，負責不間斷地發(fā)布更新和功能提升。同時(shí)，他的職位讓他還需要處理公司的其他事務(wù)。

當然，一開(kāi)始都很順利，我們的情況就像所有軟件開(kāi)發(fā)一樣，我們不間斷地維護和改進(jìn)我們的軟件。

正如我們應該預料到的（顯然我們沒(méi)有），不知何故，軟件開(kāi)發(fā)過(guò)程開(kāi)始慢下來(lái)。

新的版本更新開(kāi)始延期了，這種情況持續了一陣子，很快就變成沒(méi)有版本更新了。這讓我很不安，有一天我問(wèn)CTO：

“這個(gè)產(chǎn)品出了什么問(wèn)題？為什么版本更新要花費那么多時(shí)間而且開(kāi)發(fā)進(jìn)展緩慢？”

他深吸一口氣，開(kāi)始回答：

“我們的代碼太復雜，它的結構不好，耦合太緊。架構設計完全錯誤，用戶(hù)界面和核心邏輯代碼混雜在一起，每當修復一個(gè)Bug或作某些改變時(shí)，其他部分就會(huì )受影響。即使是小的改變也很難做好。每次更新，都會(huì )引起新的問(wèn)題。
一些方法竟然有20個(gè)參數，方法體的代碼有兩頁(yè)長(cháng)！你能想象嗎？有許多不應該實(shí)現的東西不知為何都實(shí)現了。

這就是為什么每次更新都要花費很長(cháng)時(shí)間而我們無(wú)法推出新功能的原因。每次我們推出一個(gè)新版本，我都擔心可能會(huì )引入新的Bug，而那些現在工作得很好的核心功能則有可能因此無(wú)法工作。在這種情況下，發(fā)布新版本太冒險了，我們可能會(huì )失去我們的用戶(hù)，我們的軟件無(wú)人再愿意使用?！?/span>

他的回答中提到的一系列問(wèn)題其實(shí)我們都知道。只是，我們期望從他的口中說(shuō)出來(lái)。

我還問(wèn)了一個(gè)問(wèn)題。負責這個(gè)軟件的前任首席開(kāi)發(fā)人員為這個(gè)軟件開(kāi)發(fā)了一年時(shí)間，而他都在CTO的管理下，那么CTO為什么允許這樣混亂的代碼出來(lái)呢？

“我不想打擊他的積極性，我們必須盡快進(jìn)入反惡意軟件市場(chǎng)，他很擅長(cháng)這個(gè)，所以我才沒(méi)有制止他這樣做?！?/span>

CTO這樣回答。

也就是說(shuō)，為了以最快的速度進(jìn)入市場(chǎng)，我們犧牲了代碼質(zhì)量，這樣做也等于破壞了這個(gè)產(chǎn)品的未來(lái)。

經(jīng)驗教訓：

要在第一時(shí)間對不好的代碼設計說(shuō)“不”，不要讓“面條式代碼”毀了你的產(chǎn)品的未來(lái)。要確保做出的軟件產(chǎn)品有可持續開(kāi)發(fā)性。

那么，如何修復這個(gè)可怕的代碼？

“我們都是程序員，而程序員的心中都駐著(zhù)個(gè)建筑師，當他們到達一個(gè)地方的時(shí)候，他們想做的第一件事就是把這個(gè)地方夷為平地，然后在上面建造一些宏偉的建筑。我們對那些漸進(jìn)式的更新不感興趣：如小修小補、改進(jìn)、種種花草等等?！?/span>
-?Joel Spolsky，Stackoverflow公司CEO

開(kāi)發(fā)人員總是傾向于拋棄舊代碼然后從頭開(kāi)始，他們有這樣做的理由。因為他們認為舊代碼都是無(wú)用而且凌亂的。但是這只是想當然的理由。當我們試圖找出背后的真正原因時(shí)，我們會(huì )發(fā)現：

我們可能錯了！

舊代碼對我們來(lái)說(shuō)可能看起來(lái)很凌亂，必須從頭重寫(xiě)的原因并不是因為代碼本身，而是因為一個(gè)重要的，基本的編程法則：

讀代碼比寫(xiě)代碼難。

這解釋了代碼重用困難的原因，也解釋了為什么我們認為舊代碼象頭發(fā)一樣凌亂。因為這個(gè)原因，當我們閱讀另一個(gè)開(kāi)發(fā)人員的代碼時(shí)，我們的潛意識會(huì )不斷對著(zhù)我們耳語(yǔ)“扔掉它，重新開(kāi)始”。

像所有開(kāi)發(fā)人員一樣，我們也落入了這個(gè)陷阱。只是讀一遍我們的凌亂的代碼就足夠讓我們下決心考慮從頭重寫(xiě)了。

在一系列的會(huì )議之后，即使CTO對重寫(xiě)代碼有抵觸（他是對的），他最終還是被說(shuō)服了，我們決定從頭重寫(xiě)代碼。

然而，重寫(xiě)代碼的決定并沒(méi)有持續太久…

那是一個(gè)周末，星期日，我邊喝早茶邊讀一些推送文章。就像我的推送知道該向我展示什么一樣，我讀到了那篇最著(zhù)名的關(guān)于重寫(xiě)代碼的文章，就是Joel Spolsky寫(xiě)的Netscape 的代碼重寫(xiě)故事（https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/）。

讀完那篇文章后，我立馬分享給了AntiMalware開(kāi)發(fā)團隊，包括CTO。

然后我們開(kāi)始了新的討論。

本來(lái)說(shuō)服CTO作出代碼重寫(xiě)的決定就已經(jīng)很難了。他在讀完那篇文章后馬上改變了主意，他決定中止代碼重寫(xiě)。這讓其他團隊成員生氣了，他們沖我大喊大叫：

“你為什么給他看那篇文章？我們都已經(jīng)說(shuō)服他了。這個(gè)產(chǎn)品必須從頭重寫(xiě)，這是唯一的解決方案?！?/span>

我們的第一次重寫(xiě)代碼的嘗試到此結束了。關(guān)于這個(gè)話(huà)題的討論也終止了。我們的CTO相信我們可以管理好這個(gè)糟糕的代碼，并有能力在它之上發(fā)布新版本，直到嚴酷的現實(shí)擊倒我們?yōu)橹埂?/span>

一年沒(méi)有任何更新…

真的，這不是玩笑。真的一年沒(méi)有更新了！

“為什么沒(méi)有更新？“

“自上次更新到現在已經(jīng)有好幾個(gè)月過(guò)去了?！?/span>

每天，我們都得面對這些來(lái)自用戶(hù)的負面評論。作為一家小公司，我們需要管理的產(chǎn)品太多了，而且，我們又進(jìn)入了企業(yè)市場(chǎng)，這些加在一起，使得我們陷入了這樣的困境。

把所有這些結合起來(lái)，你就會(huì )得出這樣的結論：我們忘記了我們的用戶(hù)。

回想一下，我們不想發(fā)布新的版本，因為我們不想失去用戶(hù)。

但事實(shí)應該是相反的：如果我們不發(fā)布新的更新，我們肯定會(huì )失去用戶(hù)，而我們已經(jīng)一年半沒(méi)有給他們任何新版本了。

在被現實(shí)打了一巴掌之后，我們決定回頭。對我們來(lái)說(shuō)，除了重寫(xiě)代碼別無(wú)它途。我們做到了。

當前

“2018年12月17日，星期一，21:40。測試的電子郵件準備好了，即將發(fā)送給我們的內部測試組?！?/span>

經(jīng)過(guò)12個(gè)月筋疲力盡的工作，代碼重寫(xiě)終于完工。我們準備了第一個(gè)測試版本說(shuō)明，就像上次這個(gè)產(chǎn)品面市的第一天一樣。

我們又回來(lái)了…

這個(gè)產(chǎn)品的重寫(xiě)版本仍處于測試階段。測試已經(jīng)快一個(gè)月了。我們正在修復錯誤，傾聽(tīng)用戶(hù)的意見(jiàn)，審查用戶(hù)反饋……一切就像4年前一樣……

但是在這12個(gè)漫長(cháng)的月中，我們錯過(guò)了什么呢？如果不是重寫(xiě)，我們會(huì )做出什么新產(chǎn)品？！

許多問(wèn)題可以在這里提出來(lái)。但我知道我們只有重寫(xiě)一條路，我們看不到任何其他的解決方案。

如果你也落入了這個(gè)陷阱，開(kāi)始思考“我是否應該從頭開(kāi)始重寫(xiě)代碼”，那么在開(kāi)始代碼重寫(xiě)的第一步之前，就考慮自己提問(wèn)下面的問(wèn)題，每個(gè)開(kāi)發(fā)人員都應該問(wèn)問(wèn)自己：

你準備好拋棄關(guān)于舊代碼的所有知識了嗎？

這個(gè)問(wèn)題很重要！請誠實(shí)地回答：你真的準備好拋棄所有的知識，所有收集到的錯誤和修復，年復一年的編碼結果嗎？拋棄舊代碼并從頭開(kāi)始，真的是你所期望的嗎？當你從這個(gè)角度來(lái)審視代碼重寫(xiě)的決定，你會(huì )發(fā)覺(jué)很痛苦，不是嗎？所有那些試圖修補bug的不眠之夜都會(huì )在你眼前閃過(guò)。相信我，因為我有切身體會(huì )。

你必須和很多用戶(hù)交談才能找到導致你的軟件不能正常工作的問(wèn)題所在，然后你要在你的軟件中定位這個(gè)錯誤，重現這個(gè)問(wèn)題，然后找到解決方法，然后……等等。

你能保證你會(huì )做的比第一次更好嗎？

這點(diǎn)很重要：當你從頭開(kāi)始的時(shí)候，沒(méi)有人能保證你會(huì )比第一次做的更好。

因為你選擇拋棄關(guān)于這個(gè)軟件的所有知識和已經(jīng)收集的錯誤和修復，所以同樣的錯誤很可能再次出現在你的新代碼里。

可能代碼重寫(xiě)團隊已經(jīng)不是第一個(gè)版本的開(kāi)發(fā)團隊。所以你實(shí)際上沒(méi)有“更多的經(jīng)驗”。你會(huì )犯下舊版本中的大部分的的錯誤，并帶來(lái)一些新錯誤，而這些新錯誤在舊版本中并不存在。

如果你沒(méi)有很好地計劃重寫(xiě)工作，你可能面臨新版本比原始版本更糟的風(fēng)險。然而，既然作出了重寫(xiě)的決定，你就要承擔這個(gè)風(fēng)險，這個(gè)風(fēng)險可能導致你失去你的客戶(hù)。

你準備好將幾個(gè)月/幾年的時(shí)間優(yōu)勢拱手送給你的競爭對手嗎？

你知道需要多少時(shí)間來(lái)重寫(xiě)你的軟件嗎？

代碼重寫(xiě)牽扯到大量的精力、計劃和準備工作。你必須把每項任務(wù)計劃好，然而一個(gè)接一個(gè)地沖刺。你必須確切地知道完成這個(gè)痛苦的過(guò)程的最后期限。沒(méi)人知道你會(huì )不會(huì )錯過(guò)這個(gè)最后期限。有很大的可能你不能準時(shí)完成這個(gè)過(guò)程。

你不得不在數月或數年時(shí)間內只能交付舊版本給用戶(hù)，這將置你于極其危險的境地。你完全無(wú)法進(jìn)行任何戰略改變或對市場(chǎng)所需的新功能作出反應，因為你沒(méi)有任何新代碼可以交付。

你的客戶(hù)可能會(huì )拋棄你，因為你除了不斷地提供一成不變地舊版本外，無(wú)法給他們任何新的東西。

這些你都考慮到了嗎？、

從代碼重寫(xiě)中我們學(xué)到了什么？

從頭開(kāi)始重寫(xiě)一個(gè)系統，本質(zhì)上就是承認作為一個(gè)設計師的失敗。它其實(shí)是在聲明，“我們未能設計一個(gè)可維護的系統，因此必須重新從頭開(kāi)始?！?/span>
——摘自 Max Kanat-Alexander的 Code Simplicity

像其他設計師一樣，我們承認我們未能設計好我們的軟件，我們從這個(gè)精疲力盡的過(guò)程中學(xué)到了很多東西。在這里，我分享一些我們從中獲得的經(jīng)驗教訓。

代碼重寫(xiě)是開(kāi)發(fā)人員的一種錯覺(jué)，大多數情況下它不是解決方案。

當你的代碼遇到問(wèn)題時(shí)，準確地診斷問(wèn)題很重要。像每個(gè)開(kāi)發(fā)人員一樣，你最初的想法不應該是代碼重寫(xiě)。代碼重寫(xiě)只是一種錯覺(jué)。因為你在閱讀別人的代碼的時(shí)候，你會(huì )認為如果你從頭重寫(xiě)代碼，你能做得更好。在這種情況下，請始終牢記那個(gè)重要的，基本的編程法則。

在決定重寫(xiě)代碼前，考慮代碼重構

有針對性的重寫(xiě)對于處理代碼庫中最嚴重的錯誤很有用。如果可以限制范圍并解決大部分問(wèn)題，就不要進(jìn)行整體重寫(xiě)。例如，軟件的加載速度非常慢。但這只影響到項目的一小部分。通過(guò)小心地移動(dòng)代碼、重構和更改接口，這個(gè)問(wèn)題可以一次性解決。你不必重寫(xiě)所有代碼。

代碼重寫(xiě)是一條比預期耗時(shí)更長(cháng)、更困難、更容易失敗的路。

告訴大家一個(gè)開(kāi)發(fā)人員通常在錯過(guò)最后期限后才意識到的事實(shí)：一切都比想象的要花更長(cháng)的時(shí)間。代碼重寫(xiě)成本的估計通常很悲觀(guān)，然而實(shí)際的成本幾乎總是比你想象的更高，花費的時(shí)間也更長(cháng)。因為總是會(huì )有想不到的復雜問(wèn)題要解決，這些都會(huì )使重寫(xiě)過(guò)程變得更加困難和痛苦。最后，你很可能不得不接受失敗的結果。

確保重寫(xiě)后的產(chǎn)品能夠更好地解決用戶(hù)的問(wèn)題，至少相同，不能接受更差。

重寫(xiě)對用戶(hù)沒(méi)有直接的影響/好處。因為用戶(hù)不關(guān)心代碼，他們只想解決自己的問(wèn)題，僅此而已。在用戶(hù)看來(lái)，能夠解決他們問(wèn)題的產(chǎn)品就是好產(chǎn)品。否則，他們不會(huì )用它。用戶(hù)不關(guān)心你的代碼重寫(xiě)決定，所以重寫(xiě)后版本必須至少和舊版本一樣有效地解決他們的問(wèn)題。

保持對現有產(chǎn)品的維護和支持。

在我們的案例中，我們有一年的時(shí)間沒(méi)有向用戶(hù)提供任何軟件更新。這對于我們今天生活的世界來(lái)說(shuō)是太長(cháng)了。盡管我們的產(chǎn)品依然足夠優(yōu)秀，但是沒(méi)有更新用戶(hù)肯定會(huì )抱怨。當程序員重寫(xiě)代碼時(shí)，永遠不要停止維護當前正在使用的系統。在重寫(xiě)過(guò)程中，舊的代碼仍然需要維護，小的更新和錯誤修復需要及時(shí)提供給用戶(hù)。否則，你將面臨失去用戶(hù)的風(fēng)險。

讓用戶(hù)盡快參與設計過(guò)程

確保定期向用戶(hù)展示最新進(jìn)展，以便他們能夠幫助你捕獲最嚴重的錯誤。盡快與用戶(hù)見(jiàn)面是很重要的。他們的反饋將幫助您根據他們的需求設計新產(chǎn)品。不要實(shí)現任何不必要的功能，這將避免你的代碼庫過(guò)于復雜化。

保持產(chǎn)品團隊同步步調一致

一個(gè)產(chǎn)品團隊不僅僅包括編程隊伍，營(yíng)銷(xiāo)、支持、編程、設計……所有團隊需要協(xié)力工作。通過(guò)定期匯報重寫(xiě)進(jìn)展情況來(lái)確保整個(gè)團隊步調一致。

在我們的案例中，我們遇到了很多這樣的問(wèn)題。例如，營(yíng)銷(xiāo)團隊準備產(chǎn)品測試活動(dòng)時(shí)，他們必須準確了解產(chǎn)品方面的情況，以便讓客戶(hù)為即將到來(lái)的產(chǎn)品改變做好準備。但是，有時(shí)我們在沒(méi)有通知他們的情況下做了一些更改。這害得他們必須從頭開(kāi)始準備他們的測試活動(dòng)。記?。翰灰速M任何人的時(shí)間。

不要對產(chǎn)品作重大更改。

了解你的產(chǎn)品的弱項和強項，這一點(diǎn)很重要。切記不要改變產(chǎn)品的強項，也即用戶(hù)喜愛(ài)的方面。如果用戶(hù)對用戶(hù)界面滿(mǎn)意，不要對用戶(hù)界面作大改動(dòng)。只做最小的更改和小的用戶(hù)體驗改進(jìn)。當您用重寫(xiě)后的版本替換現有版本時(shí)，確保你的用戶(hù)不會(huì )被新的巨大變化所困擾。有許多情況用戶(hù)放棄了新版本，因為他們找不到以前版本提供的相同的功能。不要讓同樣的事情發(fā)生在你身上。

不要讓你的產(chǎn)品只依賴(lài)于一個(gè)開(kāi)發(fā)者。

在我們的案例中，CTO是負責開(kāi)發(fā)我們軟件的首席開(kāi)發(fā)人員。由于他的立場(chǎng)，我們的產(chǎn)品開(kāi)發(fā)進(jìn)展緩慢。即使是很小的變化也需要幾個(gè)星期，有時(shí)甚至幾個(gè)月。我想表達的關(guān)鍵點(diǎn)是保持一直更新，永遠不要停止。

版本遷移/更換要循序漸進(jìn)。

當您確認新版本已經(jīng)準備好，開(kāi)始用新版本替換舊版本時(shí)。要一步一步，循序漸進(jìn)。

首先，從一個(gè)小型的內部測試組開(kāi)始，將您的產(chǎn)品發(fā)送到該組。收集他們的反饋和崩潰報告，修復錯誤，迭代新版本，然后重復這個(gè)過(guò)程，直到你確認你的產(chǎn)品已經(jīng)準備好公開(kāi)測試。

進(jìn)入公開(kāi)測試后，用戶(hù)的反饋是你最期待的。你的第一個(gè)目標應該是確保您的產(chǎn)品能夠解決用戶(hù)的問(wèn)題。當你確認新版本提供的功能與舊版本相同或者更好時(shí)，就可以進(jìn)行更換了。這時(shí)候開(kāi)始為新用戶(hù)發(fā)布新版本，并將現有用戶(hù)遷移到新版本。

以上這些都是我從代碼重寫(xiě)過(guò)程中吸取的關(guān)鍵經(jīng)驗教訓。代碼重寫(xiě)幾乎永遠都不應該是解決方案，重構才是更好的選擇。強烈建議采用代碼重構循序漸進(jìn)解決問(wèn)題。這樣做的風(fēng)險更低，客戶(hù)也更滿(mǎn)意。

什么時(shí)候重寫(xiě)代碼是合適的選擇

然而，有時(shí)候重寫(xiě)代碼也是合適的解決方案。下面我我列出了重寫(xiě)代碼的幾種情形：

切換到另一種語(yǔ)言或平臺：

當一種語(yǔ)言變得如此古老，導致你很難找到開(kāi)發(fā)人員，或者必須花大價(jià)錢(qián)才能找到時(shí)。

現有的代碼庫變得不可維護（像我們的情形）：

如何確認你的代碼變得不可維護呢？這個(gè)很難，但是如果你發(fā)現即使是很小的更改也很難實(shí)現，或者新的更新比正常需要花費的時(shí)間多得多，或者任何新的更改都會(huì )影響到軟件的其他部分并導致新的錯誤，那么你可以確認你的代碼變得不可維護了。

有足夠的資源可以同時(shí)維護現有系統和設計新系統：

重寫(xiě)代碼的時(shí)候，永遠不要停止維護當前正在使用的系統。只要系統在使用中，必須始終對其提供維護。記住，你的個(gè)人注意力也是一種必須考慮的資源，如果你打算同時(shí)為新系統和舊系統做設計工作，你要考慮是否每天有足夠的時(shí)間。

開(kāi)發(fā)人員變成了軟件開(kāi)發(fā)的瓶頸（像我們的情形）：

這不應該出現在重寫(xiě)代碼的原因列表中。因為你可以隨時(shí)在團隊中調配開(kāi)發(fā)人員，也可以雇傭新的開(kāi)發(fā)人員來(lái)解決瓶頸問(wèn)題。

然而，就像我們的情形一樣，有時(shí)你可能需要將它作為代碼重寫(xiě)的一個(gè)原因。因為我們的軟件使用的是舊技術(shù)，而CTO是唯一負責開(kāi)發(fā)它的人。我們很難找到一個(gè)新的開(kāi)發(fā)人員，因為這個(gè)平臺年代太久。即使我們能找到一個(gè)新人，對我們來(lái)說(shuō)也太昂貴。因此。我還是把它作為代碼重寫(xiě)的情形之一，列在這里。

軟件的年齡太長(cháng)（我說(shuō)的是10-20年或更長(cháng)時(shí)間）：

隨著(zhù)時(shí)間的推移，一個(gè)軟件的代碼會(huì )變得越來(lái)越凌亂，維護也會(huì )變得越來(lái)越昂貴。這是因為為了快速推出修復補丁，初始架構有時(shí)會(huì )被犧牲掉。而且，懂得舊技術(shù)的開(kāi)發(fā)人員越來(lái)越少，人員成本也越來(lái)越高。同時(shí)，很難找到適合舊的應用程序運行的硬件、操作系統和框架。此外，隨著(zhù)業(yè)務(wù)的發(fā)展，舊的系統很可能無(wú)法滿(mǎn)足新的業(yè)務(wù)需求。

所以，你必須在舊系統高昂的維護成本，新系統的潛在好處，以及從頭重寫(xiě)的成本之間作一個(gè)權衡。

如果你的情形符合上述一點(diǎn)或多點(diǎn)，代碼重寫(xiě)可能是你能接受的選項。否則，正確的做法是通過(guò)一系列簡(jiǎn)單的步驟改進(jìn)系統的設計，在不重寫(xiě)代碼的情況下處理解決現有系統的復雜性。

從頭重寫(xiě)代碼可能是你犯的最大錯誤，但同樣地，不重寫(xiě)代碼也可能導致相同的結果。我的建議是優(yōu)先考慮重構而不是重寫(xiě)。

有些開(kāi)發(fā)人員堅信所有系統最終都必須重寫(xiě)。記住這并非總是對的。設計一個(gè)不需要拋棄的系統是可能的?？傆熊浖O計師會(huì )告訴你，“無(wú)論如何，總有一天我們會(huì )丟掉所有的東西”。但是，如果軟件是從一開(kāi)始就設計得很好，而且一直有很好的維護，為什么它會(huì )被拋棄呢？

作者：Roman Luzgin，譯制：CSDN

本站僅提供存儲服務(wù)，所有內容均由用戶(hù)發(fā)布，如發(fā)現有害或侵權內容，請點(diǎn)擊舉報。

欧美性猛交XXXX免费看蜜桃,成人网18免费韩国,亚洲国产成人精品区综合,欧美日韩一区二区三区高清不卡,亚洲综合一区二区精品久久