1. 程式人生 > >菜鳥要做架構師——如何快速開發中小型系統

菜鳥要做架構師——如何快速開發中小型系統

俗話說:不想當專案經理的程式設計師不是好的架構師。相信每一個有上進心的程式設計師,都有一個架構師的夢。最近完成了一箇中小型的專案,讓我有了一些感受和想法,於是決定新開一個系列——《菜鳥要做架構師》。

 

經常看我部落格的人應該瞭解,我寫了好幾個“菜鳥”系列了。有很多人問我,你都是大牛了,怎麼寫部落格還叫菜鳥?有人覺得太過低調了,也有人覺得這是在裝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相比SpringMVCMybatis也有著更多的使用者,相關社群也更加的活躍,有什麼問題當然解決起來也就更容易一些。

綜上所述,基礎框架為: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”,或者給你輸出一堆亂碼,甚至直接宕機藍屏了。這個事情三言兩語說不清,總之就是對待不同的人用不同的方法。對於踏實沉穩的人要時不時的鼓勵,換髮他的激情;對於活潑外向的人就要偶爾打擊一下,安撫一下他的浮躁。任務的安排也要根據每個人的能力以及特長合理分配,當組員沒有很好的完成任務時也不要急於責備、質問,先耐心的傾聽,看看究竟是哪些原因所導致的,然後客觀分析,找出解決方案,共同克服困難。

 

回頭一看,發現自己竟然寫了這麼多,說實話寫這篇部落格著實花了我不少功夫,這應該是我寫的最長同時也是感受最多的一篇部落格了吧。總之能夠順利的完成這個專案離不開大家的支援,離不開組員的努力,在此我就不一一感謝了。最後不得不單獨感謝一下巨同學,如果不是他一次次的鼓勵,不可能完成的這麼順利,遇到困難時彼此的鼓勵很重要。加油!你行的!