俗話說：不想當項目經(jīng)理的程序員不是好的架構師。相信每一個有上進心的程序員，都有一個架構師的夢。最近完成了一個中小型的項目，讓我有了一些感受和想法，于是決定新開一個系列——《菜鳥要做架構師》。

經(jīng)常看我博客的人應該了解，我寫了好幾個“菜鳥”系列了。有很多人問我，你都是大牛了，怎么寫博客還叫菜鳥？有人覺得太過低調(diào)了，也有人覺得這是在裝B。其實呢，我是覺得自己真的還只是個菜鳥。就光拿計算機行業(yè)來說吧，就有太多太多的知識我不懂，甚至連聽都沒聽過。記得高中有位老師說的話讓我印象特別深刻，大概意思是：越是一知半解的人，往往越是喜歡高談闊論；越是知識淵博的人，往往越覺得自己欠缺很多（哎呀，現(xiàn)在說這句話，有點裝B的嫌疑，罪過罪過....）。所以我覺得要保持一顆謙卑的心，才能夠不斷的學習并提高自己，所以用“菜鳥”二字來自勉。好了，好像扯的有點遠，下面咱們進入正題。

項目背景：

這個項目是給廊坊市政府做的，本來這個項目是別的公司做的，后來由于種種原因，不做了，留下一個半成品。我接手的時候，他們給了源碼和數(shù)據(jù)庫，還有一些簡單說明。幾乎沒有任何需求和設計文檔，經(jīng)過多方聯(lián)系和溝通，他們給出的答復是：沒有文檔！最后經(jīng)過大家討論覺得在他們的基礎上繼續(xù)開發(fā)，成本較高（需要弄清楚他們的代碼以及數(shù)據(jù)庫，他們給的庫總共有四百多張表），所以最后決定重新開發(fā)。

重構：

雖然文檔一無所有，好在利用他們給的源碼和數(shù)據(jù)庫，他們的項目還是搭起來的。可以簡單的看看頁面，也對一些需求有了大致的了解。也發(fā)現(xiàn)了一些他們前端框架存在的問題，最嚴重的問題就是瀏覽器的兼容性。經(jīng)測試發(fā)現(xiàn)，頁面顯示只有在IE7和部分國產(chǎn)瀏覽器下正常顯示。在其他IE版本或者其他內(nèi)核瀏覽器，甚至是很多雙核瀏覽器下都是那種根本沒法用的程度。

技術選型：

前端框架

前面已經(jīng)提到了，之前的項目在瀏覽器兼容性上存在著嚴重的問題，所以我們在選擇的時候要考慮到這個因素。結合手底下開發(fā)人員的技術水平以及用戶的需求，我們最終確定用dwz作為我們的前端框架。可能會有人覺得dwz不好，Ext更好怎樣怎樣，還是那句話合適就是最好的，殺雞焉用牛刀。個人覺得dwz在應對中小型的項目時，還是非常不錯的。首先，瀏覽器兼容性不錯，經(jīng)過我的不完全統(tǒng)計，dwz無論是在IE、Chrome還是FireFox的各個主流版本，都可以正常工作，各大國產(chǎn)瀏覽器也都完美兼容；還有，就是它上手比較容易，對于快速開發(fā)小型項目非常合適；當然，選擇它還有一個很重要的原因，項目組的人對于dwz相對熟悉，可以快速投入戰(zhàn)斗。

核心框架

目前最常用的也就是下面幾位了：Spring、Struts/SpringMVC、Hibernate/Mybatis。一般說來Spring的入選沒有什么爭議，主要就是MVC框架用Struts還是SpringMVC，ORM框架用Hibernate還是Mybatis。這四個都是非常優(yōu)秀的開源框架，技術上都很成熟，無論怎么組合都可以很好的完成我們需要的功能。具體怎么選擇，還是的回歸實際。結合開發(fā)人員的技術特長，以及相關資料的豐富程度，和遇到問題解決的成本來看，Struts和Hibernate更加適合。首先，組員對于Struts和Hibernate更加熟悉；Struts和Hibernate相比SpringMVC和Mybatis也有著更多的用戶，相關社區(qū)也更加的活躍，有什么問題當然解決起來也就更容易一些。

綜上所述，基礎框架為：Spring + Struts+ Hibernate 。

其他

數(shù)據(jù)庫方面很簡單，對于中小型的項目MySQL足以，Oracle太笨重了。IDE方面，Eclipse沒什么好說的。構建工具，Maven管理項目很好用，跟Ant相比，Maven也是好處多多，關于它們兩個的比較就不細說了，百度一大堆。版本控制，SVN功能完善、簡單易用，在局域網(wǎng)內(nèi)做版本控制，要比Git更有優(yōu)勢。Web容器選擇Tomcat+Jetty，Jetty主要是用于開發(fā)的時候，最終部署到服務器用的是Tomcat。部署用Tomcat一是因為他更加成熟，二是因為市政府那邊的服務器環(huán)境就是Tomcat，沒必要再換。而用Jetty呢，是因為它以插件的形式跟Maven配合起來，可以很大程度的提高開發(fā)的效率。在pom.xml文件里配好，直接“Run?As”運行，修改代碼也能動態(tài)加載，很方便。

基礎架構的設計：

基礎的結構就是Action+Service+Dao+Entity。整體的結構圖如下：

上圖是最基本的骨架，當然還會用到一些工具類什么的，那些可以統(tǒng)一放到tool里面。大家都知道面向?qū)ο笥袔讉€很重要的特性——抽象、封裝、繼承、多態(tài)。我們設計的時候當然也要遵循面向?qū)ο蟮乃枷?#xff0c;下面先來看一下每一層內(nèi)部的聯(lián)系吧！

Action：Action這一層，抽象出一個BaseAction，由它統(tǒng)一繼承ActionSupport，然后把一些公共的東西封裝到里面。例如分頁信息、result的返回值常量等等；

Service：Service這一層，抽象出一個BaseService，有它處理最基本的增刪改查業(yè)務，其他具體的Service來繼承它，比如UserService，繼承BaseService以后，默認就具有了基本的增刪改查，因此，它不需要再自己實現(xiàn)一遍。它的任務就是關注自己特有的業(yè)務，比如登錄、退出，這些是UserService自己獨有的業(yè)務。這樣不必管共有業(yè)務，只關注自己特有業(yè)務的方式提高了代碼復用，提高了開發(fā)效率。

Dao：Dao這一層，抽象出一個BaseDao，它跟上面BaseService的作用很相似，負責處理對實體基本增刪改查的工作，就不多說啦。

Entity：Entity這一層，其實也是可以抽象出一個BaseEntity的，可以讓它來實現(xiàn)序列化，這樣就不用每個實體類都實現(xiàn)一遍了。還可以把Id等公共屬性拿出來。總之，原則就是把大家都需要的統(tǒng)一放到一個地方，自己只管自己特有的。

開發(fā)管理：

我們的開發(fā)團隊開始是四個人，后來一個開發(fā)人員轉(zhuǎn)到其他項目組，我們有轉(zhuǎn)過兩個人來。所以我們組屬于四五個人的規(guī)模，管理模式采用的是敏捷開發(fā)的模式。每天上午來了，九點開立會，每個人說一下昨天任務的完成情況，有沒有遇到什么困難之類的。如果沒有什么特殊情況，就給每個人分配一下接下來的任務，如果有人遇到什么難題，就找人幫他解決一下，或者我?guī)退鉀Q一下。然后把進度跟情況匯報給項目經(jīng)理。

OK，上面說了那么多項目的情況，下面該呼應一下本文的標題了，談談做完這個項目我的一些感受。好了，那么問題來了：挖掘機技術...?咳咳...?不好意思，說順口了。今天要說的是快速開發(fā)中小型系統(tǒng)我們應該怎么做。

快速確定需求

中小型系統(tǒng)通常業(yè)務不是很復雜，因此要確定需求并不難，快速畫出原型，積極和客戶溝通，以便快速的確定需求。需求不定后面的事情都是白扯。

合理的技術選型

需求定了，那么接下來就要考慮怎么做了。首先要確定用什么技術，選擇什么框架等等。技術選型首先要看這種技術適不適合項目，即能不能滿足我們的需求，通常這一點比較容易確定；第二就要考慮這種技術適不適合我們的團隊，什么意思呢？就是說要看開發(fā)人員對于這項技術的熟悉程度，是不是能馬上上手，或者需要一段時間的學習，再或者需要投入比較高的學習成本。如果需要比較高的學習成本，那么或許你該考慮一下是不是有其他的技術可以代替它。當然，如果你們項目不急或者你們公司是土豪那就另當別論了；再有不要一味追求最新的技術，因為新的版本往往伴隨著新的bug，出了問題也不好解決，同樣也不要選擇太老的版本，推薦選擇比最新版本低一到兩個版本的正式穩(wěn)定版。

優(yōu)秀的基礎架構

什么是優(yōu)秀的代碼？很多人都知道：易擴展、易維護、復用性強....?那么如何做到這些呢？說實話，小弟水平一般說不太好，大抵可以概括如下：層之間加入接口，來降低耦合度、增加靈活性，方法與類的職責單一，提高內(nèi)聚性，從而達到易擴展的目的；制定完善的代碼規(guī)范，模塊與關鍵代碼語句要有較詳細的注釋，完善的文檔，從而提高易維護性；抽象封裝公共模塊，提煉與業(yè)務無關的部分，如：分頁、樹形菜單、上傳、下載、基本的數(shù)據(jù)維護等。從而提高代碼的復用性。

項目管理

項目管理可以分為項目進度的掌控以及人員的管理安排。這兩者是密不可分的，只有把人管好，才能讓項目平穩(wěn)的向前推進。人與人之間的交往，遠比跟電腦打交道要復雜的多。這次輸入個“A”，他給你輸出個“B”，下次你同樣輸入個“A”，沒準他就給你輸出個“C”，或者給你輸出一堆亂碼，甚至直接死機藍屏了。這個事情三言兩語說不清，總之就是對待不同的人用不同的方法。對于踏實沉穩(wěn)的人要時不時的鼓勵，換發(fā)他的激情；對于活潑外向的人就要偶爾打擊一下，安撫一下他的浮躁。任務的安排也要根據(jù)每個人的能力以及特長合理分配，當組員沒有很好的完成任務時也不要急于責備、質(zhì)問，先耐心的傾聽，看看究竟是哪些原因所導致的，然后客觀分析，找出解決方案，共同克服困難。

回頭一看，發(fā)現(xiàn)自己竟然寫了這么多，說實話寫這篇博客著實花了我不少功夫，這應該是我寫的最長同時也是感受最多的一篇博客了吧。總之能夠順利的完成這個項目離不開大家的支持，離不開組員的努力，在此我就不一一感謝了。最后不得不單獨感謝一下巨同學，如果不是他一次次的鼓勵，不可能完成的這么順利，遇到困難時彼此的鼓勵很重要。加油！你行的！

from:?http://www.cnblogs.com/liushuijinger/p/4086371.html

總結

以上是生活随笔為你收集整理的菜鸟要做架构师（一）——如何快速开发中小型系统的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。