菜鳥要作架構師（一）——怎樣高速開發中小型系統

俗話說：不想當項目經理的程序猿不是好的架構師。

相信每個有上進心的程序猿，都有一個架構師的夢。

近期完畢了一箇中小型的項目，讓我有了一些感覺和想法，因而決定新開一個系列——《菜鳥要作架構師》。

常常看我博客的人應該瞭解，我寫了好幾個「菜鳥」系列了。有很是多人問我，你都是大牛了，怎麼寫博客還叫菜鳥？有人認爲太太低調了。也有人認爲這是在裝B。事實上呢。我是認爲本身真的還僅僅是個菜鳥。

就光拿計算機行業來講吧。就有太多太多的知識我不懂，甚至連聽都沒聽過。

記得高中有位老師說的話讓我印象特別深入，大概意思是：越是隻知其一;不知其二的人，每每越是喜歡高談闊論；越是知識淵博的人。每每越認爲本身欠缺很是多（哎呀，現在說這句話。有點裝B的嫌疑，罪過罪過....）。因此我認爲要保持一顆謙卑的心，才幹夠不斷的學習並提升本身，因此用「菜鳥」二字來自勉。好了，好像扯的有點遠。如下我們進入正題。

項目背景：

這個項目是給廊坊市政府作的，原本這個項目是別的公司作的。後來因爲種種緣由，不作了，留下一個半成品。我接手的時候。他們給了源代碼和數據庫，另外一些簡單說明。

差點兒沒有不論什麼需求和設計文檔。通過多方聯繫和溝通。他們給出的答覆是：沒有文檔！最後通過你們討論認爲在他們的基礎上繼續開發，成本較高（需要弄清楚他們的代碼以及數據庫，他們給的庫總共同擁有四百多張表）。因此最後決定又一次開發。

重構：

儘管文檔一無所有，好在利用他們給的源代碼和數據庫。他們的項目仍是搭起來的。可以簡單的看看頁面，也對一些需求有了大體的瞭解。也發現了一些他們前端框架存在的問題，最嚴重的問題就是瀏覽器的兼容性。

經測試發現，頁面顯示僅僅有在IE7和部分國產瀏覽器下正常顯示。在其它IE版本號或者其它內核瀏覽器，甚至是很是多雙核瀏覽器下都是那種根本無法用的程度。

技術選型：

前端框架

前面已經提到了，以前的項目在瀏覽器兼容性上存在着嚴重的問題，因此咱們在選擇的時候要考慮到這個因素。結合手底下開發者的技術水平以及用戶的需求，咱們終於肯定用dwz做爲咱們的前端框架。

可能會有人認爲dwz很差，Ext更好如何如何，仍是那句話合適就是最好的，殺雞焉用牛刀。我的認爲dwz在應對中小型的項目時。仍是很是不錯的。首先。瀏覽器兼容性不錯，通過個人不全然統計，dwz無論是在IE、Chrome仍是FireFox的各個主流版本號。都可以正常工做，各大國產瀏覽器也都完美兼容。還有，就是它上手比較easy，對於高速開發小型項目很是合適；固然。選擇它另外一個很是重要的緣由，項目組的人對於dwz相對熟悉，可以高速投入戰鬥。

核心框架

眼下最常用的也就是如下幾位了：Spring、Struts/SpringMVC、Hibernate/Mybatis。

通常說來Spring的入選沒有什麼爭議，主要就是MVC框架用Struts仍是SpringMVC。ORM框架用Hibernate仍是Mybatis。

這四個都是很是優秀的開源框架，技術上都很是成熟，無論怎麼組合都可以很是好的完畢咱們需要的功能。

詳細怎麼選擇，仍是的迴歸實際。

結合開發者的技術特長，以及相關資料的豐富程度，和遇到問題解決的成原本看，Struts和Hibernate更加適合。首先，組員對於Struts和Hibernate更加熟悉；Struts和Hibernate相比SpringMVC和Mybatis也有着不少其它的用戶，相關社區也更加的活躍。有什麼問題固然解決起來也就更easy一些。

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

其它

數據庫方面很是easy。對於中小型的項目MySQL足以，Oracle太笨重了。IDE方面。Eclipse沒什麼好說的。構建工具，Maven管理項目很是好用，跟Ant相比。Maven也是優勢多多，關於它們兩個的比較就不細說了，百度一大堆。版本號控制。SVN功能無缺、簡單易用。在局域網內作版本號控制。要比Git更有優點。Web容器選擇Tomcat+Jetty，Jetty主要是用於開發的時候。終於部署到server用的是Tomcat。部署用Tomcat一是因爲他更加成熟。二是因爲市政府那邊的server環境就是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，上面說了那麼多項目的狀況。如下該呼應一下本文的標題了。談談作完這個項目個人一些感覺。

好了。那麼問題來了：挖掘機技術... 咳咳... 很差意思，說順口了。

今天要說的是高速開發中小型系統咱們應該怎麼作。

高速肯定需求

中小型系統一般業務不是很是複雜。所以要肯定需求並不難。高速畫出原型，積極和客戶溝通。以便高速的肯定需求。

需求不定後面的事情都是白扯。

合理的技術選型

需求定了。那麼接下來就要考慮怎麼作了。首先要肯定用什麼技術，選擇什麼框架等等。技術選型首先要看這樣的技術適不適合項目，即能不能知足咱們的需求。一般這一點比較easy肯定；第二就要考慮這樣的技術適不適合咱們的團隊，什麼意思呢？就是說要看開發者對於這項技術的熟悉程度，是否是能當即上手。或者需要一段時間的學習，再或者需要投入比較高的學習成本。假設需要比較高的學習成本。那麼也許你該考慮一下是否是有其它的技術可以取代它。固然，假設大家項目不急或者大家公司是土豪那就另當別論了；再有不要一味追求最新的技術，因爲新的版本號每每伴隨着新的bug，出了問題也很差解決，相同也不要選擇太老的版本號。推薦選擇比最新版本號低一到兩個版本號的正式穩定版。

優秀的基礎架構

什麼是優秀的代碼？很是多人都知道：易擴展、易維護、複用性強.... 那麼如何作到這些呢？說實話，小弟水平通常說不太好，大抵可以歸納例如如下：層之間添加接口，來減小耦合度、添加靈活性。方法與類的職責單一。提升內聚性，從而達到易擴展的目的；制定無缺的代碼規範，模塊與關鍵代碼語句要有較詳細的凝視，無缺的文檔。從而提升易維護性；抽象封裝公共模塊，提煉與業務無關的部分。如：分頁、樹形菜單、上傳、下載、主要的數據維護等。

從而提升代碼的複用性。

項目管理

項目管理可以分爲項目進度的掌控以及人員的管理安排。這二者是密不可分的，僅僅有把人管好。才幹讓項目平穩的向前推動。人與人之間的交往。遠比跟電腦打交道要複雜的多。此次輸入個「A」，他給你輸出個「B」，下次你相同輸入個「A」，沒準他就給你輸出個「C」，或者給你輸出一堆亂碼，甚至直接死機藍屏了。這個事情三言兩語說不清，總之就是對待不一樣的人用不一樣的方法。對於踏實沉穩的人要時不時的鼓舞。換髮他的激情；對於活潑外向的人就要偶爾打擊一下，安撫一下他的浮躁。

任務的安排也要依據每個人的能力以及特長合理分配，當組員沒有很是好的完畢任務時也不要急於責怪、質問，先耐心的傾聽。看看究竟是哪些緣由所致使的，而後客觀分析，找出解決方式，共同克服困難。

回頭一看，發現本身竟然寫了這麼多，說實話寫這篇博客着實花了我很多功夫，這應該是我寫的最長同一時候也是感覺最多的一篇博客了吧。

總之可以順利的完畢這個項目離不開你們的支持，離不開組員的努力，在此我就不一一感謝了。最後不得不單獨感謝一下巨同窗，假設不是他一次次的鼓舞，不可能完畢的這麼順利，遇到困難時彼此的鼓舞很是重要。加油！

你行的！