過度依賴框架有什麼不好？

01-11

用好了框架後，有些知識沒必要知道都能做

職業發展。

面試的時候，以編程基本功和程序設計為主的，往往是有發展空間的好公司；而以框架細節為主的，往往是項目里有人跳了，一堆活沒人干，缺個搬磚的。

如果過於依賴框架，往往只能在後一類公司中輾轉。

使用第三方框架和庫遇到坑是必然的，但是可以有解決方案的。如果你說我不使用第三方框架和庫，就能避免這些坑嗎？不是，就算你不使用框架，坑還是要遇到，而且比不用第三方框架和庫可能更加麻煩。在我看來，你不是用第三方框架和庫，就是在使用自己開發的框架和庫。第三方框架和庫有問題，有代碼，有文檔，有在線幫助；自己框架和庫有問題，只有代碼，沒有文檔和在線幫助，如果原開發人員走了，可能都不知道問題出在哪裡。所以基於這些原因，我現在編程比較傾向於使用框架和第三方庫。

然而單獨某一個框架是個時代性很強，競爭激烈，過度依賴的框架話問題會很大。下面談談框架問題和解決方案

1. 大版本升級問題

每個單獨框架都是由進化時間線的，當大版本變動時候，升級底層的框架將會變得異常麻煩。第一，你的代碼很多是針對現在這個版本代碼優化或者是妥協變通的代碼，升級後，很大程度的可能性就是這些代碼將成為歷史遺留問題。第二，如果你項目是大量修改框架內部，那麼這樣的升級可能會變成你的噩夢。

大版本升級一定會發生，尤其在語言升級或者是技術升級後，框架升級不可避免。有些框架升級甚至可以說是個新框架了。

最近最簡單的例子是laravel4-5和angular.js版本1-2的升級，改動地方很多。而bootstrap基本上要你重新把所有html代碼全部重新寫過

2.相似框架的移植

現在用的框架不再更新了，有更好的框架出現了，那麼你的代碼就需要移動到新的框架下面了，這個時候，噩夢來了，你針對先用的框架代碼，基本上和新的框架代碼不兼容，那麼等於要重新寫一次代碼。

我做過把code igniter的代碼用laravel重寫一遍的事情，那是就是因為框架代碼完全不兼容的原因

3.框架的淘汰

框架淘汰太快，今天火熱，1年後就可能沒人再提了。比如說jQuery,如今少有人提了，當然還算是很重要，但是當年的yahoo的YUI，如今是無人問津了。又比如php的code igniter原公司停止更新後，也沒有人在提了。而如今的框架火熱，讓人實在是選擇困難，生怕使用後，過段時間就不更新了。

4.不同公司，不同項目的框架

每個公司可能都有自己的技術架構，這家用這個框架，那家用別的框架；甚至不同項目用不同框架。所以太過於依賴某一個框架，那麼你的跳槽範圍就窄了很多。

我用過的框架有yui，angular,vue,backbone(js),code igniter, laravel(php), bootstrap(css),都挺好用，然而使用過程中就遇到過以上那麼多的問題。

建議：

項目開始前，要對使用的第三方庫和框架做好調查，甚至要有他們開發停止的心理準備和技術準備
不要面向框架編程，面向通用組件編程：把你的代碼寫成通用組件，可以在不同項目，不同框架下中直接調用
面向介面編程，而不是面向細節編程：做一個有開放介面的中間件，封裝第三方庫api。在項目代碼中，使用中間件介面，千萬不要直接使用第三方庫的api。這樣第三方庫過期了，可以馬上換庫而保證項目正常使用。
學習通用的編程技術，不要學某個技術的細節：細節靠搜索即可，把框架的通用技術和知識學好，這樣不同框架都可以快速上手，快速開發了。
短期項目，可以不考慮框架升級；長期項目要好好考慮框架升級的情況。
寫unit test：在框架升級和換框架時候，進行單元測試，保證其在不同環境下可以正常工作

再說說開發一個長期項目過程中，選擇第三方框架的一些原則：

有LTS版本（長期維護版本）
開發組織是可以保證長期的：社區型開發，超級公司主導的開發（google，facebook）
有代碼覆蓋100%的單元測試
有良好的技術支持，包括：良好文檔，在線技術問答，有好的官方網站，bug的快速報告和快速修復
社區大小，生態良好：使用人員多，插件開發人員多的
github上星星多的，下載量大的（可以作為參考，卻不是決定因素）

做好以上幾項，你就可以很好的避免大部分所謂過度依賴框架的問題了。

沒什麼不好。

框架的目的之一就是增加抽象，隱藏細節，提高生產效率。當然了，隱藏了細節也等於隱藏了知識，但現在的編程語言和平台眾多，什麼都了解做不到也無必要。實用主義的學習方法就是learn as needed，什麼地方出問題了，什麼地方就進行深入補習和研究。如果一定要吹毛求疵，可能就是剛入門的程序員會被框架寵壞，遇到問題不願意靜下心來深入研究。但這是態度問題，和框架沒什麼關係。

我感覺用框架很好，我對安卓比較熟悉，就拿安卓做例子吧。

比如最基本的圖片載入，新手自己直接寫的話，可能會寫的亂七八糟，比如網路請求與圖片顯示過度耦合，不知道要使用懶載入啊，更不知道如何把一個圖片載入模塊從一個項目中抽離開。

但是如果我們用了框架，看了別人的api,就會知道一個框架的外部介面應該是什麼樣的，通過什麼樣的包裝來與app進行松耦合，根據介面我們還可以看到對圖片載入來說，應該主要控制哪些變數。

比如事件匯流排框架EventBus,如果你沒用過的話，可能一輩子會用startActivityForResult來在activity間傳遞數據，通過setArguments在fragment間做通信，而不會知道activity,fragment甚至網路載入模塊之間可以解耦合到這種地步。

比如TabLayout框架，如果你沒用過的話，可能一輩子只會在Activity裡面開一個ViewPager，外加一堆亂糟糟的狀態變數和UI, 但是通過學習tablayout框架，我們可以知道 viewpager如何與tablayout進行雙向監聽，並且吧對ui的控制封裝進控制項裡面。

最後，少年，我問你一句，如果沒有這些前人的框架給你使用，開放源代碼給你研究，你要多久能領悟到這些?

用框架是必須的，而且一定要用熟，最後將框架的思想（源碼）融會貫通甚至拓展現有或者新的框架，才不辜負框架作者的一片無私奉獻。

其實題主自己都知道了問題在哪裡，所以加了「過度」和「依賴」兩個形容詞。

用框架沒有什麼不好。

但是遇事兒總是使用框架API，不去學習和了解框架內部的實現和框架想要達到的目的。那麼技術會停止不前。

舉個java的例子，如果只會使用hibernate，但不會寫SQL。這就是使用框架帶來的問題。

舉個Android的例子，如果只會使用EventBus，而不會使用startActivityForResult之類的方法，那麼註定對於Android的生命周期和內部機制缺乏了解。

這就是危害

會被自己造輪子而自我感覺良好的大神鄙視。

沒有什麼不好，框架是工具，過度依賴工具有什麼不好？燒火過度依賴火柴依賴打火機，比鑽木取火強上百倍!依賴框架和了解框架源碼，讀懂框架思想，學習框架範式一點都不衝突。反倒是一些人，什麼框架都學得半桶水，不知道那些場景用框架代碼怎麼實現，用的時候自己覺得很煩躁，於是用自己僅知道的微薄知識，寫一堆醜陋的難以維護的東西，各種濫用拼湊山寨還自以為是，不如靜下心來學好一門框架。

想起了那個古老的笑話：真正的高手，一晚上用磁性筆在硬碟上直接刻出了一個windows

知乎上多了，總讓我有一種幻覺是不是最牛的工程師用的鍵盤只有0和1。。。

對於純技術相關的，比如圖片、網路請求等，使用成熟的第三方庫沒有問題，自己造輪子代價會大很多；

而對於業務相關的部分，可以基於第三庫自己改造等等。

沒什麼不妥的，關鍵是要理解它，學習它從而提高自己。

對於一些大家都用的庫，那是必須的，對於一些不常用的，盡量別用，像event bus，dagger之類的，國內哪個大公司會用這些的？不是說它不好，而是不容易維護，不容易維護的原因是，遇到問題你得對源碼十分了解才能解決，而且互聯網一兩年一個團隊的人都換了一遍很正常，新來的人又要熟悉這個相對不普及的框架，最後導致大家效率極其低下

所謂框架這種東西，其實也就是一個個的輪子，層層的封裝。我認為廣義上說，各類工具，技術，協議都可以理解為是框架。舉個不恰當的比喻，編程語言本身就是一種框架。機床也是一種框架。工業機器人也是一種框架。

框架的使用，目的是提高開發效率和質量。

過度依賴框架，看從誰的角度來看：

項目經理：好啊，省得你們天天給我造輪子，用了框架，開發時間可以比從頭做高多了吧？通過框架配置實現的功能，我可以省掉測試了吧。成本降低了，真好。招人讓他學了XX框架就好了，要求低點就好，自然工資也低點吧。

混日子的程序員：好啊，這樣我不用學底層，不用知道原理就能實現那麼炫酷叼炸天的功能。PM還說我乾的不錯，真好。

不混日子的程序員：好啊，這框架真不錯，我要看看它怎麼實現的，哇，真牛逼，這個部分似乎不太適合我們的業務邏輯，我也要寫一個，還能改進一下這個功能。

所以，關鍵還是使用者吧。比如那些3，5年的SSE來面試，開口閉口MVC，但連http協議的各種概念，連伺服器端session的實現原理也全然不知，說起來都是「我沒研究的那麼深」。這就是混日子程序員的典型例子。但這類人，如果沒有如今的那麼多的框架，早就被迫改行了吧。過度依賴框架至少讓這類人繼續從事軟體開發工作。

既然是「過度」當然就不好了，你先給「過度」下個定義吧。

用框架很好，但是用框架不深入研究就不太好了。有框架當然用框架，但是框架不直接支持時候，你怎麼處理，怎麼選擇，這裡就有區別了。

過度依賴的前提是，你應該把它的原理搞明白。

尤其應該知道他的劣勢。其次應該看他的社區等等！

現在面試很多人，vue angularjs 用的一溜一溜的。讓他們畫出mvp mvvm原型圖卻各種蒙蔽

不知道樓主說的「過度使用框架」是怎麼一個情況。在我看來，有一種情況是有害的，這種情況叫削足就履。在某些人眼中，由於有宇宙無敵框架的加持，對每個功能實現的思考，都是考慮怎麼組合框架提供的功能來逼近需求本身，從而產生出很多很奇葩的實現方法，順手埋下了很多詭異的坑。

在團隊引入框架的時候，確實需要團隊成員、特別是核心成員，對這個框架非常熟悉，能正確引導大家合理的使用框架。這也是很多團隊堅持用自研框架的原因

依賴框架沒什麼不好，因為每個項目最終都會積累出許多框架，並依賴它們，框架也就是這麼來的。

但是知其然，不知其所以然，就非常危險了。

題主所說「用好了框架後，有些知識沒必要知道都能做」，我暫且理解為會用框架，而不懂原理。這種情況下，如果：

1.項目產生了預期誤差，最後發現是框架給出的結果不是自己想要的。這時候，如果不懂原理，不理解框架採用的模式，那麼debug是很痛苦的一件事情。

2.框架本身有bug，你又不知道問題在哪，要麼換一個框架，要麼等他發布新的版本修復這麼bug。

3.框架已經不能滿足項目的需求，這時候要麼改源碼，要麼換框架。

4.框架功能重疊率高，利用率低。項目里大部分框架都有功能重疊的地方，而且很多框架只是為了其中一個功能就引入了。Android里65535問題，其中很多方法都是功能重疊的，且沒用到的。

5.等等

想要解決以上的問題，最終還得研究框架。

但是初期開發者，我還是建議依賴框架。程序員大環境是工期短，又要求發布出來的東西穩定，如果在初期自建框架的話，會面臨太多問題，就像甘明的回答，維護成本太高又不穩定。

對於使用框架的建議是，既然用了，就得懂原理。在項目穩定的時候，把裡面依賴的框架一一拿出來學習研究是程序員必要的工作，也是為了自建框架打好基礎，因為每個項目最終都會積累出適合自己的框架。

這裡推薦一個流行框架原理解析的開源項目供大家學習：

GitHub - aosp-exchange-group/android-open-project-analysis: Android 源碼解析開發版，網站:

4月26日18:22更新:

還有一種危害，不合理的使用框架會侵佔你的架構。使用框架代表你已經把自己嫁給它了，繼承它，調用它。繼承是一種強烈的依賴關係。蜜月期你會發現很爽。相反，框架沒有對你做任何承諾，如果框架改版，更新，甚至不維護的時候。離婚是一件非常痛苦的事情，因為你的架構已經被侵佔了。。

依賴框架幾乎沒有任何好處。我從來不用不是自己寫的框架。但是「純被動」的工具庫倒是狂用，因為可以隨時換

總有框架解決不了的問題然後你為了解決這個問題就去自己寫了個框架。。。。

嗯。。我就是因為mvc的attribute不夠用自己又去整了一堆attribute出來。。

寫了好多，突然發現不是在說眼鏡，於是默默的刪除了。。。

這個問題本身是錯誤的：任何「過度」的事情都是不好的！

所以探討的問題應該是：依賴框架有什麼不好？

首先，很明顯的好處，可以少寫很多代碼，並且產出相當穩定的產品。當然這裡是有前提的，就是你選擇的框架質量很好。

所以其次的不好也就來了：怎麼保證挑選的框架是好的？

很多人會說使用一個框架，要「知其所以然」，這也是看情況，並不是所有的碼農都能成為牛叉的工程師，牛叉的工程師是應該探究更多，知其所以然，這樣出問題了才hold得住bug。

如果你是一個碼農，並且對自己成為牛叉的工程師沒有什麼信心，那麼多用框架是很好的，只是要懂得大致評估框架的好壞。並且在遇到問題時，儘可能的讓你遇到的問題成為你了解框架的突破口，別因為不是牛叉的工程師，就放棄接近牛叉。不能遇到問題，調了幾次發現調不出來就想著換輪子，這便是我認為依賴框架的壞處了。

人在職場，最重要的還是把領導交代的事給落地了！

落的踏實最重要，至於落地的姿勢有多美如畫，領導是不關心的。

You are not paid to write code, you are paid to deliver a product!

提升自己的能力絕無壞處，他能讓你把更難的事情踏實落地。