怎樣搭建輕量級架構-代碼組織篇
非常多程序猿看到標題，預計心裏一楞：一個組織代碼，有什麽可講的，無非是公司網址倒著寫，外加命名規範，最多分模塊管理而已！怎麽這都能忽悠一篇文章來？
代碼組織確實是一件簡單的事情。可是假設我說的“代碼組織”不只限於這些內容呢...
大家都知道Web項目的架構，文件非常瑣碎。一個模塊前臺包括JS,CSS,HTML文件，後臺還有模塊的邏輯處理類，實體的數據庫訪問類。以及實體本身。
假設這個模塊須要打印，還要有打印的模板文件！
假設這個模塊另一些關聯數據，比方學員的學分數據等等。
算下來。一個最簡單的模塊都要有10個左右的文件。
因為Java Web的架構。非常多開發者都知道，js,css等文件是和Java代碼分離的。
文件的分離本身就添加了復雜性。假設文件數量上再有所添加，復雜度更是呈幾何倍數增長。
可能絕大多數開發者並沒有質疑如此做的問題，覺得既然大家都如此做。這麽做肯定沒有問題。
可是你可能沒有註意到，這給你添加了多少麻煩。又浪費了多少時間。
1. 你常常改動完後臺代碼，再去改動前臺代碼，卻要點幾下鼠標才幹找到文件！
2. 項目越來越大。文件也越來越多。常常找錯文件？
3. 常常發現出現了一些不知所謂的文件，不知道所屬哪個模塊。又所屬哪個人....處女座看到都要哭了。
4. 每一個月總有那麽幾天。處女座在流血！
別想多，他僅僅是看不下去，要重構項目中全部的文件......
這些情況想必非常多人遇到過，或者正在經歷.....那麽怎樣才幹避免這樣的情況呢？
模塊全部文件一起放，千萬別分開
假設你的文件結構是這種，是不是攻克了非常多問題？模塊中包括了模塊的全部文件！
這就是我們眼下的結構，在Java中，有非常多Lib支持從JAR中讀取資源文件。有點經驗的不難搞定。
這樣做之後，程序猿就全然專註於邏輯，而不用頻繁的找文件
並且，開發任務能夠細粒度的按模塊劃分，而不是按前臺後臺劃分
自己主動生成模塊框架
假設你的結構定了，就能夠使用Freemarker直接生成代碼框架。
非常多程序猿對這個不屑一顧。就幾個文件。Copy來改改即可了。
當你Copy一個。倒沒什麽，當你每天的工作都在Copy。還不想著改進，那你就太悲哀了！
自己主動生成代碼。不僅保持了系統的高度一致性，還為我們帶來另外一個優點！
非常多程序猿每天都在為文件名稱糾結上幾個小時，我就是如此！
當你為他自己主動生成，不管多醜，他都不會糾結！
有選擇是一個非常可怕的事情。是吧？
聊完了代碼組織，來聊聊單元測試。
單元測試就是對模塊代碼的測試，基於單元測試。眼神出了大名鼎鼎的TDD！
TDD全稱：測試驅動開發。
說簡單點，就是：做功能之前，先把單元測試寫好。然後一步步補全功能，直到測試通過。
TDD應該適合專業化的團隊！
！
不適合一般的屌絲團隊.....屌絲團隊玩玩單元測試就好了。
你可能和我之前一樣。看不起單元測試。都忙成狗了，哪有時間寫單元測試？？
假設你的時間寶貴，那我更要給你推薦單元測試。當你在web中要測試一個功能，步驟大致分為例如以下：
1. 編譯代碼
2. 公布到server
3.清空瀏覽器緩存
4.登陸構造測試數據
5.測試不通過。再來一次!
反復2次，預計你就要日了狗了吧。
而你僅僅要搭建好Mock測試。以上步驟夠能夠節省了。你要做的就是Debug代碼。！
本章就到此結束，當你完畢了項目管理，設計原則以及開發方法的輕量級。剩下的就是更新部署了。
下一章我們就來解說更新部署的智能化，讓你的平臺完畢從頭到尾的“輕量級”。
敬請期待。
假設您對我的文章感興趣，請關註我的微信公眾號，謝謝。
怎樣搭建輕量級架構-代碼組織篇