俗話說：不想當專案經理的程式設計師不是好的架構師。相信每一個有上進心的程式設計師，都有一個架構師的夢。最近完成了一箇中小型的專案，讓我有了一些感受和想法，於是決定新開一個系列——《菜鳥要做架構師》。
經常看我部落格的人應該瞭解，我寫了好幾個“菜鳥”系列了。有很多人問我，你都是大牛了，怎麼寫部落格還叫菜鳥？有人覺得太過低調了，也有人覺得這是在裝B。其實呢，我是覺得自己真的還只是個菜鳥。就光拿計算機行業來說吧，就有太多太多的知識我不懂，甚至連聽都沒聽過。記得高中有位老師說的話讓我印象特別深刻，大概意思是：越是一知半解的人，往往越是喜歡高談闊論；越是知識淵博的人，往往越覺得自己欠缺很多（哎呀，現在說這句話，有點裝B的嫌疑，罪過罪過....）。所以我覺得要保持一顆謙卑的心，才能夠不斷的學習並提高自己，所以用“菜鳥”二字來自勉。好了，好像扯的有點遠，下面我們們進入正題。
專案背景：
這個專案是給廊坊市政府做的，本來這個專案是別的公司做的，後來由於種種原因，不做了，留下一個半成品。我接手的時候，他們給了原始碼和資料庫，還有一些簡單說明。幾乎沒有任何需求和設計文件，經過多方聯絡和溝通，他們給出的答覆是：沒有文件！最後經過大家討論覺得在他們的基礎上繼續開發，成本較高（需要弄清楚他們的程式碼以及資料庫，他們給的庫總共有四百多張表），所以最後決定重新開發。
重構：
雖然文件一無所有，好在利用他們給的原始碼和資料庫，他們的專案還是搭起來的。可以簡單的看看頁面，也對一些需求有了大致的瞭解。也發現了一些他們前端框架存在的問題，最嚴重的問題就是瀏覽器的相容性。經測試發現，頁面顯示只有在IE7和部分國產瀏覽器下正常顯示。在其他IE版本或者其他核心瀏覽器，甚至是很多雙核瀏覽器下都是那種根本沒法用的程度。
技術選型：
前端框架
前面已經提到了，之前的專案在瀏覽器相容性上存在著嚴重的問題，所以我們在選擇的時候要考慮到這個因素。結合手底下開發人員的技術水平以及使用者的需求，我們最終確定用dwz作為我們的前端框架。可能會有人覺得dwz不好，Ext更好怎樣怎樣，還是那句話合適就是最好的，殺雞焉用牛刀。個人覺得dwz在應對中小型的專案時，還是非常不錯的。首先，瀏覽器相容性不錯，經過我的不完全統計，dwz無論是在IE、Chrome還是FireFox的各個主流版本，都可以正常工作，各大國產瀏覽器也都完美相容；還有，就是它上手比較容易，對於快速開發小型專案非常合適；當然，選擇它還有一個很重要的原因，專案組的人對於dwz相對熟悉，可以快速投入戰鬥。
核心框架
目前最常用的也就是下面幾位了：Spring、Struts/SpringMVC、Hibernate/Mybatis。一般說來Spring的入選沒有什麼爭議，主要就是MVC框架用Struts還是SpringMVC，ORM框架用Hibernate還是Mybatis。這四個都是非常優秀的開源框架，技術上都很成熟，無論怎麼組合都可以很好的完成我們需要的功能。具體怎麼選擇，還是的迴歸實際。結合開發人員的技術特長，以及相關資料的豐富程度，和遇到問題解決的成本來看，Struts和Hibernate更加適合。首先，組員對於Struts和Hibernate更加熟悉；Struts和Hibernate相比SpringMVC和Mybatis也有著更多的使用者，相關社群也更加的活躍，有什麼問題當然解決起來也就更容易一些。
綜上所述，基礎框架為：Spring + Struts+ Hibernate 。
其他
資料庫方面很簡單，對於中小型的專案MySQL足以，Oracle太笨重了。IDE方面，Eclipse沒什麼好說的。構建工具，Maven管理專案很好用，跟Ant相比，Maven也是好處多多，關於它們兩個的比較就不細說了，百度一大堆。版本控制，SVN功能完善、簡單易用，在區域網內做版本控制，要比Git更有優勢。Web容器選擇Tomcat+Jetty，Jetty主要是用於開發的時候，最終部署到伺服器用的是Tomcat。部署用Tomcat一是因為他更加成熟，二是因為市政府那邊的伺服器環境就是Tomcat，沒必要再換。而用Jetty呢，是因為它以外掛的形式跟Maven配合起來，可以很大程度的提高開發的效率。在pom.xml檔案裡配好，直接“Run As”執行，修改程式碼也能動態載入，很方便。
基礎架構的設計：
基礎的結構就是Action+Service+Dao+Entity。整體的結構圖如下：
上圖是最基本的骨架，當然還會用到一些工具類什麼的，那些可以統一放到tool裡面。大家都知道物件導向有幾個很重要的特性——抽象、封裝、繼承、多型。我們設計的時候當然也要遵循物件導向的思想，下面先來看一下每一層內部的聯絡吧！
Action：Action這一層，抽象出一個BaseAction，由它統一繼承ActionSupport，然後把一些公共的東西封裝到裡面。例如分頁資訊、result的返回值常量等等；
Service：Service這一層，抽象出一個BaseService，有它處理最基本的增刪改查業務，其他具體的Service來繼承它，比如UserService，繼承BaseService以後，預設就具有了基本的增刪改查，因此，它不需要再自己實現一遍。它的任務就是關注自己特有的業務，比如登入、退出，這些是UserService自己獨有的業務。這樣不必管共有業務，只關注自己特有業務的方式提高了程式碼複用，提高了開發效率。
Dao：Dao這一層，抽象出一個BaseDao，它跟上面BaseService的作用很相似，負責處理對實體基本增刪改查的工作，就不多說啦。
Entity：Entity這一層，其實也是可以抽象出一個BaseEntity的，可以讓它來實現序列化，這樣就不用每個實體類都實現一遍了。還可以把Id等公共屬性拿出來。總之，原則就是把大家都需要的統一放到一個地方，自己只管自己特有的。
開發管理：
我們的開發團隊開始是四個人，後來一個開發人員轉到其他專案組，我們有轉過兩個人來。所以我們組屬於四五個人的規模，管理模式採用的是敏捷開發的模式。每天上午來了，九點開立會，每個人說一下昨天任務的完成情況，有沒有遇到什麼困難之類的。如果沒有什麼特殊情況，就給每個人分配一下接下來的任務，如果有人遇到什麼難題，就找人幫他解決一下，或者我幫他解決一下。然後把進度跟情況彙報給專案經理。
OK，上面說了那麼多專案的情況，下面該呼應一下本文的標題了，談談做完這個專案我的一些感受。好了，那麼問題來了：挖掘機技術... 咳咳... 不好意思，說順口了。今天要說的是快速開發中小型系統我們應該怎麼做。
快速確定需求
中小型系統通常業務不是很複雜，因此要確定需求並不難，快速畫出原型，積極和客戶溝通，以便快速的確定需求。需求不定後面的事情都是白扯。
合理的技術選型
需求定了，那麼接下來就要考慮怎麼做了。首先要確定用什麼技術，選擇什麼框架等等。技術選型首先要看這種技術適不適合專案，即能不能滿足我們的需求，通常這一點比較容易確定；第二就要考慮這種技術適不適合我們的團隊，什麼意思呢？就是說要看開發人員對於這項技術的熟悉程度，是不是能馬上上手，或者需要一段時間的學習，再或者需要投入比較高的學習成本。如果需要比較高的學習成本，那麼或許你該考慮一下是不是有其他的技術可以代替它。當然，如果你們專案不急或者你們公司是土豪那就另當別論了；再有不要一味追求最新的技術，因為新的版本往往伴隨著新的bug，出了問題也不好解決，同樣也不要選擇太老的版本，推薦選擇比最新版本低一到兩個版本的正式穩定版。
優秀的基礎架構
什麼是優秀的程式碼？很多人都知道：易擴充套件、易維護、複用性強.... 那麼如何做到這些呢？說實話，小弟水平一般說不太好，大抵可以概括如下：層之間加入介面，來降低耦合度、增加靈活性，方法與類的職責單一，提高內聚性，從而達到易擴充套件的目的；制定完善的程式碼規範，模組與關鍵程式碼語句要有較詳細的註釋，完善的文件，從而提高易維護性；抽象封裝公共模組，提煉與業務無關的部分，如：分頁、樹形選單、上傳、下載、基本的資料維護等。從而提高程式碼的複用性。
專案管理
專案管理可以分為專案進度的掌控以及人員的管理安排。這兩者是密不可分的，只有把人管好，才能讓專案平穩的向前推進。人與人之間的交往，遠比跟電腦打交道要複雜的多。這次輸入個“A”，他給你輸出個“B”，下次你同樣輸入個“A”，沒準他就給你輸出個“C”，或者給你輸出一堆亂碼，甚至直接當機藍屏了。這個事情三言兩語說不清，總之就是對待不同的人用不同的方法。對於踏實沉穩的人要時不時的鼓勵，換髮他的激情；對於活潑外向的人就要偶爾打擊一下，安撫一下他的浮躁。任務的安排也要根據每個人的能力以及特長合理分配，當組員沒有很好的完成任務時也不要急於責備、質問，先耐心的傾聽，看看究竟是哪些原因所導致的，然後客觀分析，找出解決方案，共同克服困難。
回頭一看，發現自己竟然寫了這麼多，說實話寫這篇部落格著實花了我不少功夫，這應該是我寫的最長同時也是感受最多的一篇部落格了吧。總之能夠順利的完成這個專案離不開大家的支援，離不開組員的努力，在此我就不一一感謝了。最後不得不單獨感謝一下巨同學，如果不是他一次次的鼓勵，不可能完成的這麼順利，遇到困難時彼此的鼓勵很重要。加油！你行的！