剛學編程的時候有種想法，認為難題應該只解決一次。 但漸漸接觸多了前端開發，經常要重復編寫代碼，特別是生成頁面時。 是什么原因導致了代碼無法重用呢？

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

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

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

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

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

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

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

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

1. 不做設計（新手階段，能實現就好）

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

3. 簡化設計（認知逐漸深入，學會取舍）

4. 最優設計（熟練掌握，知道概念適配場景）

其中23兩個狀態可能會往復多次，最終達到找到一個平衡的位置.

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

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

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

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

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

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

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

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

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

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

同樣的問題應該只解決三次。第一次，你怎么知道這段代碼能夠重用呢？第二次，也許只是巧合？第三次，看來這確實是個重復出現的問題。然后你就該重構以重用代碼了。

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

Af:過早優化是萬惡之源。

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

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

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

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