基于代碼無法重用的詳細分析

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

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

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

Ab:因為復(fù)用并非無代價，而且代價往往還很高。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

那么多前端庫前仆后繼，折戟沉沙，卻又層出不窮，無非是因為某些需求滿足不了。需求總在變，庫也跟著花樣翻新，但總是差了一兩步。說到底，是什么阻止了重用？

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

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

所以，底層庫可以自頂向下的設(shè)計；而面向客戶的代碼，還要以解決當前問題為先，等到類似的問題多了，再考慮重用。不要剛遇到一個問題，就想寫個通用的解法，這樣的往往悲劇。

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

Ae:一句話介紹不清楚的,是因為懶惰。

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

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

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

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

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

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

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