前言
做爲一個程序員，在開發的過程中會發現，有框架同無框架，做起事來是完全不同的概念，關係到開發的效率、程序的健壯、性能、團隊協作、後續功能維護、擴展......等方方面面的事情。很多朋友在學習搭建自己的框架，很多公司也在創建或使用自己的框架，網上開源的框架多如牛毛，每年新上線的各種框架也不知多少。而不停的重複造輪子，也讓更多的朋友鳥槍換炮，越跑越快，工作效率越來越高。那麼什麼是框架呢？
什麼是框架
度娘上說：框架（Framework）是整個或部分系統的可重用設計，表現爲一組抽象構件及構件實例間交互的方法; 另一種定義認爲，框架是可被應用開發者定製的應用骨架。前者是從應用方面而後者是從目的方面給出的定義。
可以說，一個框架是一個可複用的設計構件，它規定了應用的體系結構，闡明瞭整個設計、協作構件之間的依賴關係、責任分配和控制流程，表現爲一組抽象類以及其實例之間協作的方法，它爲構件複用提供了上下文(Context)關係。因此構件庫的大規模重用也需要框架。
應用框架指的是實現了某應用領域通用完備功能（除去特殊應用的部分）的底層服務。使用這種框架的編程人員可以在一個通用功能已經實現的基礎上開始具體的系統開發。框架提供了所有應用期望的默認行爲的類集合。具體的應用通過重寫子類(該子類屬於框架的默認行爲)或組裝對象來支持應用專用的行爲。
應用框架強調的是軟件的設計重用性和系統的可擴充性，以縮短大型應用軟件系統的開發週期，提高開發質量。與傳統的基於類庫的面向對象重用技術比較，應用框架更注重於面向專業領域的軟件重用。應用框架具有領域相關性，構件根據框架進行復合而生成可運行的系統。框架的粒度越大，其中包含的領域知識就更加完整。
框架，即framework。其實就是某種應用的半成品，就是一組組件，供你選用完成你自己的系統。簡單說就是使用別人搭好的舞臺，你來做表演。而且，框架一般是成熟的，不斷升級的軟件。
上面是度娘百科——框架裏講的內容，講得挺理論挺全面的，直接複製了一些過來。
簡單來講，軟件開發框架可以理解爲我們起樓房時，用樑+柱子+承重牆做起來的鋼筋混凝土結構框架。而實現的軟件功能，也就像在這個框架結構中所要實現的不同類型、功能的房子，比如停車場、商場、酒店、飯店、商住房......
功能強大，結構紮實的框架，可承載的類型就更多，適用性就更強。
不論是什麼開發框架，都是爲現實不同的業務功能而創建的。好的開發框架能提高企業的競爭能力，包括降低開發成本、提高產品質量、改善客戶滿意程度、控制開發進度等。同時，開發框架也是某一領域爲實現某種業務的知識積累，它是一種持續性的活動，隨着特定業務功能實現而創建，且跳出軟件開發週期而存活。一個成熟的框架，不單單只是代碼而已，它除了將某一領域業務的基礎功能以代碼的方式實現外，還必須編寫對應的文檔、模型、流程圖、數據字典、開發使用說明.....等一系列的文檔來支撐，這樣的框架才更加成熟和健壯。
爲什麼要使用框架
軟件系統隨着業務的發展，變得越來越複雜，不同領域的業務所涉及到的知識、內容、問題非常非常多。如果每次都從頭開發，那都是一個很漫長的事情，且並不一定能將它做好。團隊協作開發時，沒有了統一標準，大家各寫各的，同樣的重複的功能到處都是。由於沒有統一調用規範，很難看懂別人寫的代碼，出現Bug或二次開發維護時，根本無從下手。（無框架不堪回首的黑暗日子請看前面章節的講述）
而一個成熟的框架，它是模板化的代碼，它會幫我們實現很多基礎性的功能，我們只需要專心的實現所需要的業務邏輯就可以了。而很多底層功能操作，就可以完完全全不用做太多的考慮，框架已幫我們實現了。這樣的話，整個團隊的開發效率可想而知。另外對於團隊成員的變動，也不用太過擔心，框架的代碼規範讓我們能輕鬆的看懂其他開發人員所寫的代碼。
搭建框架時，我們要如何定位
是不是框架的擴展性、可移值性、功能越強大就越好呢？
好的框架是相對的，它都有自己特定的應用領域，合適纔是最好。
個人覺得在實際開發中要根據具體情況來看的，因爲功能越全面它的複雜度就越大，所需要的開發人員能力和技能就會要求更高，付出的成本也就最大。比如做一個還未發展起來的電商網就想 將系統做成像京東那樣，直接用京東分模塊分佈式的框架來開發，那得怎麼來組建這個團隊？更不用說開發成本了。就算團隊有能力做到，也沒有那個必要這麼去做，因爲從成本預算和開發週期等方面來看，得不嘗失，更多的可能項目還未完成公司就給拖垮了。
一般來說，一箇中小型項目，1到5人左右的開發團隊，使用一般的三層結構就可以了，不用去細想框架要分三層還是五層，每個層之間要怎麼實現解耦，要用什麼設計模式.....因爲當今飛速發展的互聯網時代，快纔是王道，做一箇中小型項目能用一週完成的，絕不能拖了一個月還未做完。人工與時間成本纔是重點中 的重點，唯有快才能更好的生存下來並壯大。至於擴展功能、接口、分佈式、併發、大數據......等等問題，實際上過早考慮太多並不是好事情，有經驗的程序員在寫這個框架時早已留下擴展方案或思路，而沒到這一層次的開發人員你想再多也可能想不明白，還不如先做出來積累一定經驗後再慢慢學習，慢慢升級框架。
當然也不是說設計框架時不用考慮高內聚低耦合，而是要根據自己的能力與經驗來設計出自己能把控的框架出來。因爲框架不是開發出來後就不再變動，它也需要不停的進行升級，將你所學到的新知識新技術融合到框架中，使它的功能更加強大，更加健壯。而對於自己不能把控的框架，在團隊協作開發和上生產環境後，你就發現有一大堆的坑等着你去填埋，這種框架只能拿來先練練手，有空再慢慢完善。
框架通過小步快跑，不斷的迭代升級來慢慢擴展的，當項目上生產環境後，根據新的需求和所碰到的問題，去不停的調整，最終越來越強大。所有框架都是從1.0版本到2.0、3.0......發展而來，而不是直接跳過最初版本到最終成熟版本。
所以說我們在創建一個框架時，必須根據我們當前個人的技術能力、團隊成功技術水平、時間、投入成本、項目現狀（規模與需求複雜程度）、以後的發展前景來決定所要開發的框架的最終設計方案。當然也不是說不能一步到位，心有多大世界就有多大，只要個人能力和團隊能力配得上，老闆資金成本雄厚，時間充足，直接上大項目使用超級框架也完全沒有問題。
框架和設計模式
度娘上說：框架、設計模式這兩個概念總容易被混淆，其實它們之間還是有區別的。構件通常是代碼重用，而設計模式是設計重用，框架則介於兩者之間，部分代碼重用，部分設計重用，有時分析也可重用。在軟件生產中有三種級別的重用：內部重用，即在同一應用中能公共使用的抽象塊;代碼重用，即將通用模塊組合成庫或工具集，以便 在多個應用和領域都能使用；應用框架的重用，即爲專用領域提供通用的或現成的基礎結構，以獲得最高級別的重用性。
框架與設計模式雖然相似，但卻有着根本的不同。設計模式是對在某種環境中反覆出現的問題以及解決該問題的方案的描述，它比框架更抽象；框架可以用代碼表示，也能直接執行或複用，而對模式而言只有實例才能用代碼表示;設計模式是比框架更小的元素，一個框架中往往含有一個或多個設計模式，框架總是針對某一特定應 用領域，但同一模式卻可適用於各種應用。可以說，框架是軟件，而設計模式是軟件的知識。
框架的主要特點和要求
1、代碼模板化
框架一般都有統一的代碼風格，同一分層的不同類代碼，都是大同小異的模板化結構，方便使用模板工具統一生成，減少大量重複代碼的編寫。在學習時通常只要理解某一層有代表性的一個類，就等於瞭解了同一層的其他大部分類結構和功能，容易上手。團隊中不同的人員採用類同的調用風格進行編碼，很大程度提高了代碼的可讀性，方便維護與管理。
2、重用
開發框架一般層次清晰，不同開發人員開發時都會根據具體功能放到相同的位置，加上配合相應的開發文檔，代碼重用會非常高，想要調用什麼功能直接進對應的位置去查找相關函數，而不是每個開發人員各自編寫一套相同的方法。
3、高內聚（封裝）
框架中的功能會實現高內聚，開發人員將各種需要的功能封裝在不同的層中，給大家調用，而大家在調用時不需要清楚這些方法裏面是如果實現的，只需要關注輸出的結果是否是自己想要的就可以了。
4、規範
框架開發時，必須根據嚴格執行代碼開發規範要求，做好命名、註釋、架構分層、編碼、文檔編寫等規範要求。因爲你開發出來的框架並不一定只有你自己在用，要讓別人更加容易理解與掌握，這些內容是非常重要的。
5、可擴展
開發框架時必須要考慮可擴展性，當業務邏輯更加複雜、數量記錄量爆增、併發量增大時，能否通過一些小的調整就能適應？還是需要將整個框架推倒重新開發？當然對於中小型項目框架，也不必考慮太多這些內容，當個人能力和經驗足夠時水到渠成，自然就會注意到很多開發細節。
7、可維護
成熟的框架，對於二次開發或現有功能的維護來說，操作上應該都是非常方便的。比如項目要添加、修改或刪除一個字段或相關功能，只需要簡單的操作，十來分鐘或不用花太多的工夫就可以搞定。新增一個數據表和對應的功能，也可以快速的完成。功能的變動修改，不會對系統產生不利的影響。代碼不存在硬編碼等等，保證軟件開發的生產效率和質量。
8、協作開發
有了開發框架，我們才能組織大大小小的團隊更好的進行協作開發，成熟的框架將大大減輕項目開發的難度，加快開發速度，降低開發費用，減輕維護難度。
9、通用性
同一行業或領域的框架，功能都是大同小異的，不用做太大的改動就可以應用到類似的項目中。在框架中，我們一般都會實現一些同質化的基礎功能，比如權限管理、角色管理、菜單管理、日誌管理、異常處理......或該行業中所要使用到的通用功能，使框架能應用到某一行業或領域中，而不是隻針對某公司某業務而設定（當然也肯定存在那些特定功能的應用框架，這只是非常少的特殊情況，不在我們的考慮範圍）。