剛學(xué)編程的時(shí)候有種想法，認(rèn)為難題應(yīng)該只解決一次。 但漸漸接觸多了前端開發(fā)，經(jīng)常要重復(fù)編寫代碼，特別是生成頁面時(shí)。 是什么原因?qū)е铝舜a無法重用呢？

來看看大家是怎樣看待這個(gè)問題的吧，也許會有所啟發(fā)。

Aa:主要的問題在于，如果一個(gè)問題你沒有去在不同的環(huán)境下解決很多遍，你很難分得清楚，哪個(gè)部分是通用的，哪個(gè)部分是跟你當(dāng)前的環(huán)境緊密相關(guān)的。如果你什么都不懂，你做出來的代碼當(dāng)然也沒辦法很好的被重用。所以問題不可能只被解決一次，我們追求的只能是每一次解決的時(shí)候花的代價(jià)要更少，長遠(yuǎn)來講趨向于0。

Ab:因?yàn)閺?fù)用并非無代價(jià)，而且代價(jià)往往還很高。

從工程上說，任何特性都不是無代價(jià)的。復(fù)用提供了解決一類問題的靈活性，而靈活性作為一種功能，同樣有代價(jià)——正如過多地使用虛函數(shù)有性能損失，而過多地使用 interface 則一定程度上降低代碼可讀性。如果構(gòu)建靈活性的基石皆有代價(jià)，那么我們不可能期望靈活性可以免費(fèi)獲得。

而所有的問題解決之道本質(zhì)上都一樣：我們需要權(quán)衡每一個(gè)選擇的好處和壞處，做出對我們現(xiàn)在的項(xiàng)目最有利的方案。舉例來說：我們不會在項(xiàng)目最緊張的時(shí)候討論把業(yè)務(wù)邏輯抽取出來做一個(gè)通用的框架，原因很簡單：時(shí)間不夠用。我們也不會在討論怎么設(shè)計(jì)通用框架的時(shí)候過多地討論我們具體項(xiàng)目的邏輯，因?yàn)樽非笸ㄓ眯缘脑O(shè)計(jì)目的導(dǎo)致我們不可能完全為某一個(gè)具體的業(yè)務(wù)優(yōu)化。

所以從這個(gè)意義上來說，阻礙代碼重用的最大原因，事實(shí)上來自項(xiàng)目自身：復(fù)用代碼在絕大多數(shù)情況下，都不是一個(gè)項(xiàng)目的最終目的。對任何項(xiàng)目來說，唯一絕對存在的目的，是在指定的時(shí)間內(nèi)完成客戶給出的需求。當(dāng)短期內(nèi)完成功能的需求和復(fù)用發(fā)生沖突時(shí)，理智的項(xiàng)目管理者都不會選擇將注意力放在復(fù)用上。當(dāng)然，熱衷于復(fù)用的程序員必然會以長遠(yuǎn)的好處為理由為復(fù)用辯護(hù)；但正如前面的規(guī)則指出的，這依然是一個(gè)工程上的選擇問題，因而仍然需要折衷。在遇到問題時(shí)，總是先倒向某一個(gè)結(jié)果再試圖解釋，這不是折衷，而是預(yù)設(shè)立場，這恰恰是工程的大忌。

至于第二個(gè)問題，回答是：是的，對任何問題只解決一次是理想狀態(tài)，但重復(fù)解決三到五次問題并非十惡不赦。客戶關(guān)心的是我們能不能解決他們的問題，而不是能不能對任何問題都只解決一次。——不要把自己的需求誤以為是用戶的需求，這仍然是一個(gè)工程問題。

Ac:可復(fù)用的東西（小到函數(shù)，大到框架），一定是從諸多應(yīng)用場景中抽取出來的，換句話說，一定要先有場景，在場景達(dá)到一定數(shù)量一定復(fù)雜度之后才能抽象出來可復(fù)用的部分，也就是常說的重構(gòu).一開始就追求復(fù)用性沒什么意義，浪費(fèi)時(shí)間不說，更可能假象的場景根本就不存在，或者實(shí)際情況超過想象.一些老手們經(jīng)驗(yàn)足夠豐富，之前遇到過的問題越多，在開始設(shè)計(jì)的時(shí)候就能兼顧到更多的復(fù)用場景.做開發(fā)，成長的幾個(gè)階段必不可少:

1. 不做設(shè)計(jì)（新手階段，能實(shí)現(xiàn)就好）

2. 過度設(shè)計(jì)（了解的東西多了，總想追求完美）

3. 簡化設(shè)計(jì)（認(rèn)知逐漸深入，學(xué)會取舍）

4. 最優(yōu)設(shè)計(jì)（熟練掌握，知道概念適配場景）

其中23兩個(gè)狀態(tài)可能會往復(fù)多次，最終達(dá)到找到一個(gè)平衡的位置.

所以我覺得題主的狀態(tài)正是逐漸進(jìn)入過度設(shè)計(jì)的狀態(tài)，想追求絕對的復(fù)用，沒什么不好，有想法就去實(shí)踐，讓結(jié)果來驗(yàn)證你的觀念，很多東西的度不是別人能教會的，是必須要親自體驗(yàn)才能了解的和掌握的.

Ad:重用的代碼，底層的好寫，上層的難寫。

底層代碼抽象的是機(jī)器，服務(wù)的是程序員。程序員就那么點(diǎn)追求，讀寫數(shù)據(jù)，操作數(shù)據(jù)，要快，要穩(wěn)，要容易用，滿足就行了。

上層代碼抽象的是需求，服務(wù)的是用戶。用戶的需求各不相同，但每個(gè)人都覺得自己的需求特有道理，特正義。你說這個(gè)我們做不到，因?yàn)橛昧薠X lib，立馬被噴。

那么多前端庫前仆后繼，折戟沉沙，卻又層出不窮，無非是因?yàn)槟承┬枨鬂M足不了。需求總在變，庫也跟著花樣翻新，但總是差了一兩步。說到底，是什么阻止了重用？

是人心吶，是變幻莫測得人心。

人心是一個(gè) moving target，以固定的 pattern 來揣摩人心，結(jié)果就是一段想要解決十個(gè)需求，卻一個(gè)需求都解決不好的代碼。

所以，底層庫可以自頂向下的設(shè)計(jì)；而面向客戶的代碼，還要以解決當(dāng)前問題為先，等到類似的問題多了，再考慮重用。不要?jiǎng)傆龅揭粋€(gè)問題，就想寫個(gè)通用的解法，這樣的往往悲劇。

長恨人心不如水，等閑平地起波瀾。

Ae:一句話介紹不清楚的,是因?yàn)閼卸琛?/p>

同樣的問題應(yīng)該只解決三次。第一次，你怎么知道這段代碼能夠重用呢？第二次，也許只是巧合？第三次，看來這確實(shí)是個(gè)重復(fù)出現(xiàn)的問題。然后你就該重構(gòu)以重用代碼了。

當(dāng)然還可能是因?yàn)槠珗?zhí)。重構(gòu)容易出一些很明顯的問題，特別是當(dāng)你使用的語言類型系統(tǒng)不夠強(qiáng)大而你又沒有足夠的測試的時(shí)候。這種時(shí)候，維護(hù)者通常的反應(yīng)是：重構(gòu)代碼首先放測試版，出了小問題就修正，只要不是很難處理的大問題一切好說。但是遇到偏執(zhí)的維護(hù)者嘛，就只好放棄了： 放棄 you-get，轉(zhuǎn)投 youtube-dl。

Af:過早優(yōu)化是萬惡之源。

編寫代碼時(shí)，對“可復(fù)用”和“擴(kuò)展性”的考慮，都應(yīng)限定在一個(gè)很小的范圍內(nèi)。否則的話，在當(dāng)前版本多消耗的時(shí)間要遠(yuǎn)遠(yuǎn)大于未來復(fù)用代碼時(shí)省下的時(shí)間。

從“編程藝術(shù)”的角度來講，這種解決方法一點(diǎn)都不漂亮。每個(gè)人初學(xué)開發(fā)時(shí)都會有這種想法：要完美、要考慮周全、為了不存在的需求而編寫一堆“預(yù)備代碼”。但是，在經(jīng)歷過幾個(gè)項(xiàng)目后總結(jié)一下，就會發(fā)現(xiàn)這種事是多么浪費(fèi)時(shí)間和精力，當(dāng)初預(yù)想的需求90%沒有出現(xiàn)，出現(xiàn)的那部分也和設(shè)想大相徑庭了。

Ag:編寫代碼時(shí)，如果考慮今后的重用，工作量一般是只為當(dāng)前情況考慮的三倍。（參見《人月神話》）「考慮今后的重用」只能靠猜，一般都是錯(cuò)的。

讀代碼比寫代碼難，所以那些「只為當(dāng)前情況考慮的」代碼很少在問題稍稍發(fā)生變化的時(shí)候被改寫成更通用的代碼。補(bǔ)充一下，原來的第三條寫的太簡短。第三條雖然再說一個(gè)困難的現(xiàn)狀，但是它也同時(shí)說明這是正確的重用方式。就是每次寫代碼的時(shí)候，只為當(dāng)前情況考慮。準(zhǔn)確的說是只為迄今為止遇到過的情況考慮。這樣一份代碼會經(jīng)歷從專用到通用的過程。但是這個(gè)過程也是非常困難的。