寫一個自己的開源框架需要有哪些能力和基礎?

01-03

從頭開始寫一個的框架需要有哪些能力, 需要從哪些方面去著手準備?
有哪些必讀的書目?

首先你得多寫程序。如果你的幾個程序互相之間有關聯，那麼他們就需要共享代碼。共享的部分越抽象，就越像一個庫。等你習慣了這種做法之後，以後寫框架、API、類庫就像寫業務邏輯一樣簡單。

先寫文檔，先寫api，先做同類框架的調研，先對比一下再動手，不要面面俱到，但要有自己獨特的優勢，測試用例一定要全，實現完了一定要發穩定的release出來再預熱宣傳，學一些seo技巧和知識，最好再找個運營和美術ui更好，別問我為什麼知道…

你平時寫東西，總有很多類似的玩意要寫，寫多了之後把可以復用的玩意採集起來，就成了庫。

然後再往下來，解決問題除了調庫，還要搭架子：計算總要數據分類分配採集結果，網路總要收發處理……架子搭多了就會發現一類問題總有通用性，所以開始用框架。

用的框架不順手不省心不符合要求，就開始拿開源框架打補丁。

補丁打多了覺得還不如自己做個架子實在。於是就順其自然地開始自己寫框架了。

最為關鍵的是，要有快感。

第一，你寫之前要自己有快感，大概知道自己要寫的是什麼東西。

所謂框架，就是對於某個具體領域問題的DSL，這個具體領域，相對於具體項目和具體問題來說又是一種universal的東西。所以，你一直都是在strike a balance between universality and locality，你如果一開始就太universal，那必然大而無當，解決自己其實不需要解決的問題，不如專門去寫編譯器和解釋器（也是一種專門的學問，後續會講），而如果一開始就太local，你不如去寫項目代碼，兩段程序並為一個函數，也是一種框架嘛。

其實寫框架，你的idea一定要清晰，可以不著急立即開始寫，而是畫一畫，列一列要點。

第二，你寫框架的時候，寫著寫著要有快感。

是選擇A方案還是選擇B方案？要選地有感覺。是寫成這樣還是寫成那樣？要寫地有感覺。是把步驟分成這樣，先實現這個，還是先實現那個？要有感覺。每個選擇都會聯繫到你的最終成果上面去。每個選擇，都是你對於問題本身的認知的體現，也是你對於問題的認知與問題的實際情形所發生的碰撞和火花，還是你在歷次解決問題和創造方案的過程中所積累的經驗的又一次生效，驗證，以及修正。所以，寫框架本身，就是修鍊內功的過程，也是享受創造的過程。

寫框架，就是用自己的一己之力（plus背後的他人的力量），將自己對於某個問題的認知付諸形式系統的過程。哲學家們只能構思形而上的系統，數學家構建的系統距離實際運作還有一定距離。而你構建的系統則是人類經驗通過你的頭腦而輸出的智慧的結晶。所以，這個結晶過程如何把握，火候如何？步驟如何？都必須有快感。

第三，你寫完一個框架，還要有快感。

你寫完了之後，回頭再看，仍然要有快感。這個快感，主要是方向感，即目前實現到了哪一步，在多大程度上實現了自己的想法？未來還要往哪裡走？對於自己和他人的其他項目有什麼用？如何布置用框架升級具體項目的步驟？如何向他人介紹自己的框架？自己的框架到底有什麼價值？不比較同類框架，自己的框架的價值幾何？比較同類框架，自己的框架價值又幾何？到底是僅僅自己用還是為了給大家用？這裡需要指出的是，給大家用的框架，其維護成本會大大高於自己隨便寫的框架。所以，這裡面的精力和激情之間的trade off，你怎麼平衡？別人一起參與，你們的idea如何？協作如何？都是要考慮的事情。

所以如果你在寫完框架考慮這些事情的時候，也能體會到快感，那麼恭喜你，你已經從程序員上升到了高級程序員了。

第四，最大的快感，是要有用。

誰都不想自己的代碼放到一堆誰都不知道的存儲區間裡面，也許被用一兩次，也許被用K次，但是不會留存到未來。所以，造輪子的諸位，心中所想的，一定是要流芳百世，或者流芳一年，總之不能誰都不知道，誰都用不上。寫輪子這個事情，關乎個人的智力價值，關乎個人的生存價值，關注作為程序員/碼農/計算機專業人士/計算機科學家的職業追求，關乎意義感。

最有意義的是什麼？自然是寫最基本的輪子。但是，大部分基本的輪子早就寫好了。不過，我們在寫框架的時候，自然可以借鑒這些最基本的輪子，那就是編譯器和解釋器以及運行時了。框架即為對於一組給定的原始操作primitives，在其前後執行這些primtive所蘊含的內在邏輯，而框架的用戶只需要利用這些primitive再做組合，即可以放心這些蘊含的內在邏輯可以被運行。另一方面，框架的用戶因為框架，則會在實現自己的邏輯要求的時候，得到更為簡便的表達式，以及表達方法（表達方法可以推廣為整體的編程體驗和實現項目/需求的整體複雜度）。所以，框架其實就是解釋器。

寫框架，時不時會發現一些更為meta的問題的存在。而很多這些問題，在更為基礎的輪子那邊，其實有著相當多的解決方案和解決理論。寫框架的人，自然而然地，最後都會取材於編譯器，解釋器，運行時，編程語言設計，各種理論計算模型，以及從20世紀40年代至今的經典論文。要說寶藏在哪裡？寶藏不在於對於一篇文章的概述，或者說XXX就是什麼什麼這種類似的說法，寶藏在這些經典文章的字裡行間裡面。挖出寶藏，或者自己創造寶藏，都是可以選擇的路徑，更為常見的選擇是，兩者皆有，既相信前人的智慧和探尋，也相信自己的創造和判斷。

快感，就在於攀登這些高峰，並且最終實現有用的東西。對誰有用？有多大的用？最終解決這些問題的，還是你自己。這些，包括過程中的困難，都是快感的一部分。

你可以去看一些比較有名的開源項目，試圖去弄懂為什麼要那麼設計，原理是什麼？並搞清楚每行代碼是幹嘛的，然後去模仿，重構，比如jquery里的$.type的實現方式是什麼？有沒有其他的實現方式。不斷地深入探究，你可能還會學到除了用typeof做類型判斷外，還可以使用Object.prototype.toString.call這樣的方法來做類型判斷，兩者的區別是什麼？可能還會學到如何用正則表達式來做匹配，深入研究之後，你可能還會發現jquery的實例方法很多都是建立在底層的工具方法之上。諸如此類等等。

多研究框架，庫，組件的源碼，框架太大，都是日積月累不斷修改而來的，可以從他們最早的版本開始看起，那個時候的源碼會比較簡單易懂，越到後面的版本可能就越難弄明白了。

所以，以上都要建立在你具有強大編碼基礎和探索能力的基礎之上，一個合格的框架都是經過時間考驗不斷發展而來的。

關於框架這方面的書：前端方面的我知道有司徒正美的《JavaScript框架設計》

和高雲的《jQuery技術內幕》，一本是講框架的組成和結構吧，另一本是剖析源碼結構，可以當做入門書來看看。

（一點愚見#

說實話，不需要多牛逼，只需要 just do it ！不論好壞，寫著寫著，改著改著，都會成為頂尖的框架。

可以自己先模仿別人的框架下，慢慢地就會發現其中存在的問題，慢慢地學會將功能抽象起來GitHub - wenbo2018/fox: fox is a distributed, lightweight RPC framework

感覺需求以及提煉需求的能力，還有充分的時間保障更重要吧。

沒有必讀的書目，也沒有什麼必讀的資料。

你要做的就是，去山寨一個你喜歡的框架，盡量山寨到一模一樣，不懂的就去抄，然後不斷的重構，不斷的重複做輪子。最後你做出的輪子一定會比誰都圓都好，但大概只有1%的人能夠堅持到這一天！

寫框架跟開源出去是有一定的區別。

簡單來說就是：寫框架，跟寫個CMS什麼的差不多，區別只是顧及的面廣不廣（功能多不多），自定的語法奇葩程度而已。許多phper都自己寫過框架。

開源框架，那就是一個體力活，基本上更新、客服什麼都要做，跟寫玄幻小說差不多。最討厭的還是那種半槍手，總是變著法子黑你，真搞不懂國內做個小開源就那麼難~~~

坦白說不管寫框架也好，開源出去也罷，感覺更多的是做一個事情，事情做的好與壞，看你自己怎麼想而已

學習框架，幾乎沒有哪個寫總框架的軟體工程師是先理論學習書本在完全按照書本應用的。

大部分人還是從學習別人寫的好的框架和代碼開始。一開始不理解總體框架可能只從部分結構開始學習，並把理解的好用的部分結構抽出來不斷的用到自己的代碼里，寫著寫著就會寫出感覺。等理解了某個框架的百分之五十到七十左右，就可以回去重新看對應方法的書籍，這個時候很多不懂的就會理解了。

當然最重要的還是要多寫，只看不寫是不會理解的，更談不上用到自己的程序，更更談不上寫開源了。。。。。

太難，沒有極其紮實的代碼功底，開源出去基本等於找噴。

建議先去github看看成熟開源項目的代碼，你會發現居然看不懂耶- -

慢慢看懂之後，選擇工作中實際編寫的功能抽象出來，默默的寫就行了……

使用框架的目的是團隊協助、快速開發、方便後期維護。先不用任何框架寫幾個項目，發現項目中有哪些和以上目標不協調的地方，然後看一些框架思想比如MVC，然後你就會有想法了，如何用這些思想解決與目標不協調的問題，重寫一遍你會發現更多的問題，那再重寫一遍，慢慢的一個框架就這樣反覆被打磨出來了。

特別注意代碼質量，文檔和example

要看你寫哪方面的框架拉，假設你寫的是web方面的框架。那麼你用過幾個web方面的框架，都知道它們的不足在哪裡？如果知道則可以在你自己寫的框架中改進。如果不知道，你都是按照別人成熟的框架去做，必然有別人框架的影子。有必要重複造輪子么？

好啦，經過上面的自問，你仍然堅持要自己寫一個框架。那麼你需要圈定自己框架的邊界，就是做到什麼程度。是前端的框架還是做持久化的框架還是全部功能都有。

之後權衡的是開發者學習曲線，開發效率，代碼運行效率，兼容性（瀏覽器，資料庫），對上層代碼友好（不入侵），完善文檔和社區。

還有熟悉設計模式。