如何快速開發小型系統

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

 

常常看我博客的人應該瞭解，我寫了好幾個「菜鳥」系列了。有不少人問我，你都是大牛了，怎麼寫博客還叫菜鳥？有人以爲太太低調了，也有人以爲這是在裝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」，或者給你輸出一堆亂碼，甚至直接死機藍屏了。這個事情三言兩語說不清，總之就是對待不一樣的人用不一樣的方法。對於踏實沉穩的人要時不時的鼓勵，換髮他的激情；對於活潑外向的人就要偶爾打擊一下，安撫一下他的浮躁。任務的安排也要根據每一個人的能力以及特長合理分配，當組員沒有很好的完成任務時也不要急於責備、質問，先耐心的傾聽，看看到底是哪些緣由所致使的，而後客觀分析，找出解決方案，共同克服困難。

 

回頭一看，發現本身居然寫了這麼多，說實話寫這篇博客着實花了我很多功夫，這應該是我寫的最長同時也是感覺最多的一篇博客了吧。總之可以順利的完成這個項目離不開你們的支持，離不開組員的努力，在此我就不一一感謝了。最後不得不單獨感謝一下巨同窗，若是不是他一次次的鼓勵，不可能完成的這麼順利，遇到困難時彼此的鼓勵很重要。加油！你行的！