如何做一個100+模塊的前端項目開發設計管理？
一個有著100+個模塊的前端項目
前後端分離 前端來控制模板的渲染
5個前端工程師
在人員上如何安排
工程化的設計 模塊化組件化的設計又該怎樣操作
才能更高效的開發和維護呢？
瀉藥，幾個維度吧，我聊聊個人經驗：
1，版本和工作流。
1.1 svn或者git無所謂，這個不用多說，主要解決版本管理問題，推薦內部搭gitlab，方便code review和項目任務分工與查看大家代碼編碼進度等，也能方便分析匯總每個人的提交量和代碼量。1.2 設計好svn或者git的目錄規範，上線規範，開發和生產保證隔離性，每次版本更新或者提測時，做好近期備份和src與dist目錄的同步。1.3 自動化工作流。如precommit，commit after的format，自動繼承，甚至自動化的代碼部署發布上線等。1.4 工作流一定要根據以上幾點來指定，沒有萬金油，一旦你的項目工具，開發目錄結構，代碼隔離方式確定了，這一套走下來就是工作流，包括merge後的code review。所以不要祈禱有萬能的工作流，一定要根據自身業務特性來，但自動化的工具確實是可以積累復用的。打比方，我們團隊的工作流：上線分2個目錄，src和dist，開發在src目錄下開發模塊化代碼，包括css，腳本，測試環境全部採用src的資源載入，線上也可以根據url的標記自由切換快速定位問題，之後通過svn的一些cp，mv操作，把開發好的代碼做統一備份，再移植一份tag到上線目錄，做到隔離，這是一個代碼開發的工作流。
而根據以上特點又可以分解出，開發前，打好自己對應的功能分支，開發完成後，自動化的生成分支測試環境，測試完畢後再merge到主幹到預生產進行驗證，再最後通過一些腳本進行上線操作，並記錄每次上線操作的信息方便以後追查，再最後有快速回滾回退的機制。
2，多人協作。
2.1 版本控制工具天生就是做多人協作的，無論是cvs，svn還是git，trunk，master也好，各種fork，branches也好，tag，release也好，都要搞明白，記在腦子裡，明白為什麼要打主幹，為什麼要開分支，什麼時候合併，是分支合主幹還是主幹合分支，什麼時候要打tag或者release包，這些問題其實一點也不複雜，搞明白之後多人協作根本不是問題。2.2 針對前端簡單說一點，5人以上開發，如果不開分支，你的單個功能完成就會影響其他功能的獨立上線發布，而如果按照周或者半個月一次迭代來計算髮版本，一旦延期整個阻塞是串列的，所以我覺得最好的辦法就是分支主幹的開發方式，如果自己做不好，建議直接參考git flow。我們團隊業務線都是6-8人的小組一起開發多功能，妥妥的。3，架構設計和模塊劃分原則。
3.1 廢話一堆，說說核心的。100+的模塊如何做前端架構設計。首先無論你是單頁應用還是傳統的多頁應用。我的個人習慣是，按照幾個緯度來劃分代碼職能：（工具集【如js各類型輔助函數集合】，語言包，業務模塊，具體的ui模塊，抽象的UI類，原型連輔助方法，非業務的可抽象的模塊插件，第三方包框架，第三方包的插件，自動化工具腳本，測試相關集合，私有模塊倉庫【用作多項目復用】，版本操作的hook，項目代碼最佳實踐的文檔，錯誤或者統計上報，廣播機制且包含各種api的mock攔截，緩存控制等，如果單頁應用還要引入對應的mvc分層）以上每一塊都可以拆開細說，畢竟100+的模塊，你首先要按照不同緯度畫好，才能之後方便歸類整理，包括不同功能，開發前後的。
3.2 基本以上考慮的點是我平時能想到的一些關鍵架構點，針對常見的一些類和抽象庫，可以整理成npm包放私有倉庫，使用模塊化直接require拿package來維護誇項目的模塊或者第三方庫，最後根據業務規則指定對應的自動腳本，後期整理成腳手架，方便一套架構多處快速部署。
3.3 無論你是100+還是200+，哪怕你按照函數分文件，最後一定可以抽象出幾個層，一個頁面中必然有公共部分，業務部分，維護模塊關係部分（如載入器等），再最後對項目的打包規則做優化分層即可。
說了不少，但是又感覺什麼都沒說，因為每一點都可以再往細了去分，就算拋磚引玉了。。大型多人的js項目我就是這麼處理的。。
至於每個模塊怎麼寫，難點公關，這又是另外一個層面的問題了，但是總要要有一些統一的抽象方法來維護。
比如大量使用oop的項目，一定要做類管理，比如大量使用獨立模塊的項目，一定要做模塊自動生成，這些都是具體實施的問題了，就不展開討論了。。每個人都有每個人的做法或者工具或者積累。瀉藥，布吉島。
來說說經驗的吧。分為common模塊和業務模塊，如 home是首頁，article是詳情頁，依賴fisp。
可分為 tpl模塊，js模塊，css模塊等
tpl模塊包含 tpl，js，css，imgjs模塊包括js，css，img，tmplcss模塊包括 css，img你這肯定也需要拆分，分治，首先需要一套編碼規範，模塊規範，目錄規範等。
建議用webpack，fis等工程化工具。git版本控制amd cmd commonjs都行，我推薦用es6 module
大概就是這樣了。廣告：如果你想用fis，我推薦我寫的這個 GitHub - yanhaijing/fis3-base: 基於fis3的純前端解決方案，拿來即用的fis3腳手架首先要解決的問題是版本控制，首選git，git flow工作流以及必要的pull request Review機制。
目錄要分隔合理，包括必要的構建腳本，我們的經驗是將源文件統一到src目錄下，UI界面類的放置在interface目錄中，組件類的放置在components目錄下，當然還包括css文件放置一個單獨的stylesheet目錄，和images目錄。要協作開發，必然需要模塊化，老一點的AMD方式不建議現在使用，你可以考慮用webpack工具來構建這些。而且你的基礎框架也是必不可少的，這一點上最次的也建議你使用MVC（backbone），或者用react，angular，不過我推薦你用react。你的js源文件可以根據請求，模板，（如果你用了react可以不考慮模板目錄）的特點來放置。對於數據結構，可以放在entity目錄中也許這是一個模擬數據（請求）訪問的目錄，這樣每一個數據都可以在開發前期知曉結構如何，這非常的重要。
最後《編程規範》是你們協作最重要的積累，大家統一好原則性的東西，然後就沒問題了。每個人對項目的架構方式都不一樣，每家公司的環境也不盡相同，以及團隊的技術水平參差不齊，所以對項目的理解也不一樣。說我就說說團隊里正在使用的大型項目的css架構化思維吧。
正文從這開始～
CSS是依託於HTML的計算機表現設計語言。和HTML這樣的文本標記語言一樣，嚴格意義上講CSS並不算是擁有邏輯思維的編程語言，它的鍵值對已經告訴你這個屬性使用後達到的結果。因此相對於前端界熱翻天的JS來說，CSS的入門非常輕鬆，一個初學者可以很快使用CSS寫出一個靜態頁面以及一些比較酷炫的動畫效果。
然而一個體量大、頁面數量繁多的PC或移動端產品項目，自然會擁有代碼量龐大的CSS文件，這個時候如何高效地進行CSS開發與文件管理，如何提升CSS在頁面的表現性能，如何對提高CSS代碼的可維護性和可擴展性，便是架構者要考慮的事情。
0、CSS架構思維第一步：選用高效的開發和構建方式
既然談及大型項目的架構，必然在開發前需要進行技術選型。JS目前大熱的那些mvvm框架（vue、reactJs）不多說了，反觀CSS，除了bootstrap之外，覆蓋面廣的UI框架並不多見，究其原因我認為是1、CSS本身開發上手成本低，有時用框架的效率還不如不用來的快；2、UI設計層面不會去適應UI框架，UI框架存在不靈活的情況；3、bootstrap大而全，但有時確實會有項目用不到的代碼冗餘。
因此我在公司中架構整個前端工程的CSS時並沒有使用第三方UI框架。同時，在開發方式上使用SASS和Jade分別預編譯對應的CSS和HTML，並藉助gulp進行構建。
1、CSS架構思維第二步：CSS控制項化
我對CSS控制項的定義來自於UED的UI視覺設計規範，在一個大型項目中，優秀的UI規範總是能將頁面的設計元素提煉出一套標準（比如顏色、字體字型大小、柵格等）。CSS控制項化是從HTML頁面結構提煉出的不可分割的最小標籤單位。
例如一個icon圖標（使用em標籤表示）、一段文本（使用p標籤）、一個標題（h標籤）或者一個按鈕（a標籤），他們都是構成整個頁面的最小結構單位，這就是控制項；而控制項化還需要控制項是具備在整個項目中可復用性強的元素。因此在一個項目中我一般會提取如：btn.css、article.css、icon.css等這樣的項目通用控制項化模塊文件，當然這些控制項化模塊還可以被分類繼續拆分成更靈活的小模塊。
每一個控制項化模塊都用SASS編寫，使得屬性值均可以變數化，便於UI規範修改我們前端做相應的批量修改。
最終，我將這些通用CSS控制項化模塊存放在前端根目錄下一個叫gomeplusUI的父文件夾里。
2、CSS架構思維第三步：與項目樣式高度解耦
在儲備好通用性強的CSS控制項化模塊後，我們需要讓它們在真正的項目中得以使用，這樣才能發揮他們的價值。而在真正使用中發現，因為我的CSS控制項化模塊是按照pc端和移動端而非針對某個項目為公司儲備的，因此，一個pc或移動項目不可能用到對應端所有的控制項化模塊。那麼，讓這些針對設備平台而非某個項目的CSS通用控制項化模塊與項目本身CSS解耦是非常重要的。我採用為項目建立一個public.css的方式把這個項目需要的CSS通用控制項化模塊引進去，而將項目本身的私有樣式文件放在module文件夾里。
在public.css的引用上我在開發目錄（／src）下使用@import屬性，引用的是gomeplusUI裡面的控制項化模塊。這樣的好處是
我可以根據項目的需要引入CSS控制項化模塊，不需要的模塊不會引入；
使用@import路徑引入，可以讓gomeplusUI的模塊修改與項目本身的樣式解耦；
通過gulp的cssimport任務我們可以在上線前把開發目錄下public.css的@import代碼內容合併到線上目錄的public.css里，這樣gomeplusUI裡面的通用控制項化模塊代碼其實是不需要上線的，和項目上線解耦。
3、CSS架構思維第四步：規範你的控制項化
我將CSS控制項化模塊分成pc和移動兩端進行管理，控制項會隨著pc或移動端項目的增多而從UI設計規範中提煉出來的越多，這個時候我使用以下方式規範團隊的控制項使用：
根據w3c標準制定控制項使用的標籤語義化，我強制團隊用特定的標籤構建特定的控制項，比如a標籤來定製所有非表單類的按鈕，em標籤定製所有icon圖標控制項等，同時也禁止使用i、font、b、u等這樣的樣式標籤，進一步讓結構與樣式分離。
使用命名空間來防止控制項化通用樣式與項目私有樣式的污染：
首先在我們既定的樣式命名規範的基礎上，對於要引入的控制項樣式，都在對應頁面的&
使用Jade（現改名為pug）強制規範縮緊和嵌套：
我們開發選用了jade預編譯html靜態頁面，jade是強縮進、語法嚴格的預編譯語言。可以有效規範統一html編寫時的縮緊和標籤使用、嵌套規範。同時gulp下的watch與livereload方法搭配也可以讓jade調試更加便捷。
4、CSS架構思維第五步：自下而上－－從控制項化到組件化再到頁面
我們在項目開發的時候整體的頁面構建思維是自下而上，就是先通過審視設計稿，提取控制項化元素，再使用控制項拼合成小組件，小組間拼合成大組件，最後拼合成頁面的思維，這樣便於控制項和組件的開發復用。因此，jade又一次幫助了我們，我們使用jade的include、extend方法來拼合組件至頁面，同時保證每個jade模塊文件代碼量少，便於維護。
5、CSS架構思維第六步：巧用緩存與CSS文件數
CSS和頁面開發完成後我們通常會進行壓縮和打包等構建來提升性能，除了使用gulp壓縮合併你的代碼，以及上文中提到的cssimport來去掉@import合併代碼的方式，還有要考慮的就是css文件的數量。一般來說http請求越少對頁面性能越好，很多項目的頁面最終會把css合併成一個文件使用link引用，但是針對一個多頁的大型應用，我則更傾向於把上文中提到的public.css單獨引用，即該項目下的每個頁面都會引用public.css和一個自己頁面對應的module.css文件。這樣一來，public.css會被瀏覽器緩存住，反而提升了頁面性能。
最後總結下，項目中一份思路清晰的CSS開發規劃方案和JS架構其實同樣重要，都對整個項目的性能和體驗有極大的影響。只有充分考慮了CSS規劃的可擴展和可維護性，儘可能大地對頁面性能做優化，項目才能安全順利地上線，從而也能獲得更好的用戶體驗。
我寫的這篇全文發表在情大的早讀課了，傳送門：http://mp.weixin.qq.com/s?__biz=MjM5MTA1MjAxMQ==mid=2651221067idx=1sn=4164a85d37e9fabec4eb0c79f1f8c7bdscene=2srcid=0609DED3n75FjbwxuXJ4UQOnfrom=timelineisappinstalled=0
組件化吧，組件內自己玩自己的
有5個人啦 你先保證有人不會反水
美團的經驗：git進行版本控制，AMD進行JS模塊化開發，CSS有一個全局的可以個人選擇引用，頁面內的樣式根據需求有自定義標準的組件css,即命名約定，亦有新業務用的webpack css-in-js方式。對於多人開發，模塊化和git解決了版本衝突和js命名空間的問題，AMD模塊公共部分，或者大粒度的自定義組件，webpack組件都可以復用。對於上線，我們用gulp搭建的工程化上線流，合併http時用的線上combo＋本地LocalStorage緩存的方式（移動端項目，沒有IE）。把所有的css,js當作程序組件用一個前端框架控制，沒有304請求，灰度上線細到AMD文件級別。不採用老方式的線下combo一次請求一個合併好的大文件，造成緩存和帶寬的浪費。具體模塊化緩存管理的方案我們提了出來放到git上，介紹文章在我們美團的技術專欄，歡迎感興趣的同學來吐槽https://zhuanlan.zhihu.com/p/21357211
前端工程化這裡面涉及到的東西可能比較細，我只能從我個人維護100+模塊項目的經驗出發談一些想法，因為題主的主要目的：更高效的開發和維護，所以主要也圍繞這個目標來講，前面答案提到的點就不細說了。
人員安排
這點要根據團隊人員的技術特點來區分，貌似題主團隊前端不參與後台開發，因此可以按照業務模塊來給人員分工，同時，也要有所側重，例如技術骨幹，則重點維護業務無關基礎模塊或公共業務模塊；CSS好點的，則為大家搭建UI框架等。
團隊高效開發的核心其實是維護代碼的質量，如果大家寫的代碼風格都差不多，那麼人員請假或離職，其他人也能很快接手不影響進度。這裡其實注意的是兩個方面：一是避免新手的垃圾代碼，二是避免高手過於晦澀的代碼。《編碼規範》不能解決所有問題，它幾乎只會提供一些基礎的框，而且能夠在編碼階段通過工具靜態檢查，比較低成本且有效的方案是做 code review，在代碼提交之前由有經驗的工程師審查，可藉助一些工具，例如 reviewboard、gerrit 等。代碼審查可根據時間成本選擇性的做，例如只針對新員工、菜鳥或姿勢水平較低者，主要審查的是工具不能檢查的部分，例如注釋、代碼邏輯，框架的使用方式，可優化的代碼結構等。後面隨著大家習慣養成和技能提高，可逐漸放寬。
工程化設計
只說一點：重視構建，花多點時間優化構建流程。構建做的不好，後面做CI，以及開發維護都很麻煩。現在前端組件化、UI效果以及完成各類特定編程任務，市面上都會有許多成熟穩定的方案。開發時怎麼寫組件，怎麼放目錄，網上不同的框架都會有相應的最佳實踐，而複雜項目的打包策略幾乎都要自己仔細思考，因為它與你項目的業務和功能模塊劃分密切相關，而每個項目模塊和應用場景都不太一樣，例如SPA項目，通過 webpack（該問題分類在 webpack） 打包，你要考慮哪些組件應該打包到一起，哪些應為獨立 chunk，css需不需要單獨拎出來，模板（布局）怎麼管理，配置怎麼維護，路由和按需載入的粒度等。
模塊化組件化設計
組件化不是把模塊界面劃分好，組件裡面就可以各人隨便亂搞了。說三個可能需要注意的地方：
- 公共業務組件（不是基礎控制項）
這坨代碼是最難維護的，很多地方都有依賴，設計原則遵循最樸素的：高內聚低耦合強擴展。在這之前，建議在這個組件上至少做好三點：寫文檔、做單元測試、示例頁面，文檔應藉助工具自動生成，例如 jsdoc。高內聚表示這個組件自成一體，最好是引入後不需要額外的其他資源就可跑起來，這裡其實提倡與已有代碼適當重複（當然工具函數、慣用法、公共介面等就不要寫重複代碼了）；低耦合不是說不依賴，而是依賴的對象上下文無關，依賴數據而不是依賴業務對象，依賴消息而不是依賴組件等；強擴展指的是易於擴展，公共組件應該是相對抽象的，不要一新增需求，就去改這裡面的代碼，到時候業務依賴關係過多，if else 都會寫吐。應該把定製的邏輯移交到使用者這邊，不管你提供公共API，還是通過 overwrite、inherits、mixins、AOP 什麼的，給使用者一個通用的定製的方式，如果有新增業務是很多模塊都公用的，那麼考慮合併到你公共組件的核心代碼里來。
- 其他業務組件
可能需要注意的就是保持代碼風格的一致，盡量照顧到團隊人員的平均水平，不要別人維護時看不懂，例如用不用ES6、函數式編程風格等都需要權衡。另外寫一些複雜或高逼格的代碼，使用不常見的設計模式等都需要寫較為詳細的注釋。
- CSS管理
組件化之後，往往CSS碎片化比較嚴重，這裡面除了構建時打包，另外還需要注意需要對樣式有個總體的規劃和管理，如果用的框架沒有對CSS有很好的管理方案，那麼組件CSS至少從外層類名上進行限定，避免全局污染（scoped css這東西不堪大用）。其實，最好盡量不要讓寫業務組件的人寫太多獨立樣式，到時候設計沒到位，一堆「魔數」，以及重複代碼……。
另外，一定要定期預留時間重構和架構優化，小步持續改進，不然後面就是噩夢。
技術無關
一個項目高效的開發和維護最重要的核心是什麼呢？我覺得不是技術，而是需求。把需求給理解好，不要經常返工，讓需求扯你（或你扯需求）的後腿。
要麼設計一個強大靈活的架構，隨便需求艹，要麼鍛煉強大靈活的肉體，隨便艹需求。不瀉藥。技術棧的話，推薦React+Redux+ES6+SASS+webpack+git 。理由是天生組件化，分模塊比較清晰，webpack和git作為工具也非常成熟。這套技術棧好處還有日後維護方便。人員的話，先把項目大致分一下模塊，每個模塊一個webpack 打包entry吧，然後每個人負責一些模塊。
前年帶過類似的項目。不過不到100個模塊這麼多。個人經驗前期項目規劃無論多麼合理，到了項目後期，客戶需求一變。都是紙。因此，我當年就寫了一個根據函數名載入js文件的框架。盡量大家寫注釋＋函數＋數據。避免面向對象。js面向對象不夠直觀。反而對後期維護不友好。最終上百個js文件管理的還好。好代碼的標準就一條，好理解，好改。
大型項目的模塊劃分依據應該是業務或邏輯的內容，例如登錄的業務、呈現文章的邏輯、編輯文章的邏輯如此之類。不管前端項目涉及到多少技術，千萬不要按什麼js文件放一起，css文件放一起這樣的劃分方法。因為業務和需求變的永遠比技術快。
推薦閱讀：