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

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

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

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

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),都挺好用，然而使用過程中就遇到過以上那麼多的問題。

建議：

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

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

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

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