標(biāo)題 懶惰化、標(biāo)準(zhǔn)化、自動(dòng)化——>工具化 選擇自
liuruhong 的 Blog
關(guān)鍵字 懶惰化、標(biāo)準(zhǔn)化、自動(dòng)化——>工具化
出處
原文發(fā)表在《MSDN開發(fā)精選》，如有商業(yè)站點(diǎn)轉(zhuǎn)載請(qǐng)聯(lián)系雜志社或者我本人，可以從
這里 下載，如果有興趣的讀者，可以去購(gòu)買這個(gè)雜志閱讀，下面提到的一些軟件如果涉及到版權(quán)問題，均和本文無關(guān)。同時(shí)感謝雜志社的霍泰穩(wěn)先生，正是他對(duì)于我的窮追不舍才讓我憋完此文。對(duì)于小型軟件開發(fā)團(tuán)隊(duì)的探討，也希望能夠和各位交流，我的Email: liuruhong at gmail.com
懶惰化、標(biāo)準(zhǔn)化、自動(dòng)化——工具化
——利用合適的工具構(gòu)建流水線軟件過程
Eric Liu at 2005年5月
Eric是一家小公司的開發(fā)部經(jīng)理，同樣也是一名普通的開發(fā)人員。這是一家提供網(wǎng)站服務(wù)的公司，理所當(dāng)然的，Eric這個(gè)部分的主要工作是基于網(wǎng)站應(yīng)用的開發(fā)，就如目前主流應(yīng)用的推介的做法，所有的應(yīng)用是分層設(shè)計(jì)的，理所當(dāng)然的有數(shù)據(jù)訪問層、業(yè)務(wù)邏輯層和表現(xiàn)層。Eric所帶的幾個(gè)開發(fā)人員也沒有任何與眾不同之處：A君比較熟悉數(shù)據(jù)庫(kù)和業(yè)務(wù)邏輯層的編寫，但是對(duì)于Web表現(xiàn)層的了解太太有限；B君對(duì)于JavaScript、HTML、CSS等等有比較多的了解，但是對(duì)于組件層的開發(fā)還略顯生疏；C君非常熟悉業(yè)務(wù)，但是對(duì)于具體實(shí)現(xiàn)技術(shù)的了解有限；D君。。。。
這個(gè)一個(gè)普通得不能夠再普通的團(tuán)隊(duì)，不論在技術(shù)還是在協(xié)作上都沒有太多的出彩之處。而就是這樣一個(gè)組建不久的團(tuán)隊(duì)，Eric的任務(wù)是帶領(lǐng)他們?cè)谌齻€(gè)月之內(nèi)完整整個(gè)應(yīng)用網(wǎng)站的開發(fā)，并且保證完工的東西能夠適應(yīng)未來發(fā)展的變化。
我想在大多數(shù)人看來，如果保證軟件架構(gòu)的向前擴(kuò)展性和兼容性，這是一個(gè)軟件架構(gòu)師應(yīng)用考慮的問題，而不應(yīng)該把他降解到普通開發(fā)人員的身上，道理是正確的，可是可行性是不高的，在國(guó)內(nèi)的軟件開發(fā)中，誰都明白很多時(shí)候軟件過程的各個(gè)角色重疊和沖突的可能性是很大的，很少有團(tuán)隊(duì)能夠不打折扣的分離出這些崗位。比方來說，應(yīng)該將系統(tǒng)架構(gòu)師和系統(tǒng)分析員這兩個(gè)角色分離，讓架構(gòu)師專注于技術(shù)和業(yè)務(wù)的可實(shí)現(xiàn)性規(guī)劃，而系統(tǒng)分析員在架構(gòu)師工作的基礎(chǔ)上，將技術(shù)和業(yè)務(wù)轉(zhuǎn)化成面面俱全的應(yīng)用?，F(xiàn)實(shí)的說，沒有多少公司可以在一個(gè)項(xiàng)目中同時(shí)建立這兩個(gè)角色。
對(duì)于Eric而言，一切困撓無法幸免，在小型開發(fā)團(tuán)隊(duì)中，角色的相對(duì)模糊和對(duì)于結(jié)對(duì)協(xié)作的高要求是同時(shí)出現(xiàn)的，這個(gè)也就是矛盾本身。如果說RUP或者其他軟件過程最大的貢獻(xiàn)是分離和定義角色，并且指明了各個(gè)角色的職責(zé)和如何互動(dòng)，這個(gè)一切的基礎(chǔ)是在于相對(duì)穩(wěn)定的目標(biāo)上的角色清晰化。那么XP編程恰恰相反，他強(qiáng)調(diào)變化，并且擁抱變化，業(yè)務(wù)導(dǎo)向(Business Oriented)的開發(fā)方式同樣決定了無法嚴(yán)格界定崗位。
正是因?yàn)槿绱耍珽ric的團(tuán)隊(duì)必須解決幾個(gè)問題：
n 如何高效的編寫出應(yīng)用需要的代碼？
n 如何保證不同開發(fā)人員的代碼具有統(tǒng)一的規(guī)范性和可閱讀性？
n 如何在業(yè)務(wù)變動(dòng)的情況下快速適應(yīng)變化
n 如何保證代碼質(zhì)量？
n 是否需要版本控制？
n 如何進(jìn)行錯(cuò)誤跟蹤和回饋
n 。。。。
一切正如本文題目所言的：懶惰化、標(biāo)準(zhǔn)化、自動(dòng)化，方才可能構(gòu)建出流水線的軟件過程，這就是Eric這個(gè)團(tuán)隊(duì)所要解決的問題，答案是簡(jiǎn)約有效的——工具化，讓工具替你完成一切可以完成的工作。
因?yàn)镋ric的開發(fā)團(tuán)隊(duì)采用了ASP.NET作為網(wǎng)站應(yīng)用的構(gòu)建技術(shù)，因此下面提到的一些工具有些來自開源社區(qū)，有些是共享軟件，當(dāng)然也有一些商業(yè)軟件。這里不是要求你使用所有的工具，也不是說必須使用那個(gè)工具，只是一一展示利用各種工具能夠讓你省卻你曾經(jīng)以為不可能縮減的工作。我不想去熬述軟件開發(fā)過程的各個(gè)環(huán)節(jié)，畢竟那樣的課題不是這點(diǎn)文字可以解決的，我想討論的是一個(gè)標(biāo)準(zhǔn)的網(wǎng)站應(yīng)用開發(fā)的各個(gè)環(huán)節(jié)你可能使用的工具。而一個(gè)網(wǎng)站開發(fā)過程不外乎需求——數(shù)據(jù)庫(kù)設(shè)計(jì)——建?！獙?shí)現(xiàn)——測(cè)試——部署這樣粗線條的東西。
Visio(for Enterprise Architect 2003)
有很多種理由去推薦這個(gè)工具，如果你從事VS.NET開發(fā)，這是最好的數(shù)據(jù)庫(kù)工具，也是最容易使用的數(shù)據(jù)庫(kù)建模工具，或許你已經(jīng)習(xí)慣了Power Designer或者ERWin這樣的數(shù)據(jù)庫(kù)建模工具，會(huì)覺得Visio太多簡(jiǎn)單?？捎行r(shí)候反過來想“simpleness is beautiful”，如果你是一個(gè)數(shù)據(jù)庫(kù)建模的初學(xué)者，那么請(qǐng)相信我的建議，如果你是一個(gè)資深的建模人員，也請(qǐng)認(rèn)真考慮你們手頭的工具是否太過復(fù)雜，特別是應(yīng)用在團(tuán)隊(duì)中的溝通時(shí)。除了支持主流的數(shù)據(jù)庫(kù)如Oracle、SQL Server、Access，你完全可以通過安裝自己的數(shù)據(jù)庫(kù)驅(qū)動(dòng)來實(shí)現(xiàn)Visio對(duì)于其的支持，當(dāng)然了，作為Office家族的一員，Visio的另外一大優(yōu)勢(shì)就是你可以通過宏或者VBA自動(dòng)化你的IDE。
我這里推薦的是Vs.NET自帶的Visio版本，相對(duì)于Office系列，總體有一個(gè)版本號(hào)的延遲，如VS.NET 2003自帶的是Office XP版本的Visio，Office 2003的Visio版本集成在了Visual Studio 2005 Beta版中，相對(duì)于專業(yè)版，企業(yè)版提供了強(qiáng)大的腳本生成功能。
CodeSmith
在.NET之下，如果說CodeSmith是最好的代碼生成工具一點(diǎn)也不為過，而在Eric的團(tuán)隊(duì)中，也對(duì)CodeSmith的威力推崇到極致。如果你做過基于數(shù)據(jù)庫(kù)應(yīng)用的開發(fā)，相信會(huì)對(duì)那些重復(fù)的數(shù)據(jù)庫(kù)操作語句頭疼不已，太多的屬性字段，太多的更新、太多的插入，太多太多。。。。
我相信你不會(huì)陌生下面這樣的代碼
這是一個(gè)最普通的數(shù)據(jù)庫(kù)操作封裝，如果你在應(yīng)對(duì)頻繁的數(shù)據(jù)庫(kù)操作，類似這樣的代碼將是無比瑣碎。其實(shí)如果仔細(xì)想想，這樣的代碼是否在不同的類中都會(huì)出現(xiàn)，固定化的屬性訪問，一成不變的數(shù)據(jù)庫(kù)操作，相信你寫過這樣的代碼，更加相信你不愿意寫這樣的代碼。這個(gè)工具理所當(dāng)然的成為了懶惰人的工具?；谀０搴虯SP.NET語法的特性一定會(huì)讓大多.NET開發(fā)人員喜歡。在Eric的團(tuán)隊(duì)里頭，大多的數(shù)據(jù)庫(kù)訪問類（也就是設(shè)計(jì)領(lǐng)域熟知的數(shù)據(jù)訪問層（DAL），也有人簡(jiǎn)單的稱之為Business Object）都是利用這個(gè)工具生成的，其中帶來的好處是極大程度的減少不必要的開發(fā)工作量，同時(shí)因?yàn)槟０迳傻拇a是統(tǒng)一規(guī)范的，能夠維持代碼風(fēng)格的一致性。這個(gè)工具可以從
http://www.codesmithtools.com 下載，有三十天的免費(fèi)使用，樣例文件中包含了大量的模板，包括集合、數(shù)據(jù)庫(kù)和XML等等各個(gè)方面，也包含了CSLA.NET的完整模板。
Rational XDE Plus for VS.NET
其實(shí)在這里介紹一個(gè)這樣的重量級(jí)軟件不是那么合適，但是如果你用過Rose，用過Together，你絕對(duì)無法忍受沒有他們的建模方式，雖然VS.NET已經(jīng)足夠好用，但是我還是強(qiáng)烈推薦他作為你建模過程的首選工具（前提是你們的公司有能力去支付價(jià)格不菲的軟件授權(quán)費(fèi)），通過CodeSmith生成的代碼并無法盡善盡美，在數(shù)據(jù)依賴的基礎(chǔ)之上你還要去定義對(duì)象動(dòng)作，定義關(guān)系，定義依賴，定義他們的活動(dòng)時(shí)序圖?；蛘吣銜?huì)告訴我沒有必要將UML搞得如此晦澀難懂，在小型團(tuán)隊(duì)的開發(fā)過程中沒有必要使用這樣的大家伙，XP極限編程對(duì)于幾個(gè)人的團(tuán)隊(duì)再適合不過，但是你依舊需要一個(gè)概括性的抽象視圖：或者類圖，或者部署圖，或者你期望的其他視圖，不管如何，這個(gè)時(shí)候你需要一個(gè)工具能夠來做這些事情，Visio可以導(dǎo)出UML圖，但是XDE做的更好，最重要的是對(duì)于代碼和模型，XDE提供了無縫的雙向工程。這個(gè)意味著你可以利用CodeSmith生成的代碼轉(zhuǎn)換成UML圖，然后根據(jù)你的業(yè)務(wù)需要修改UML，然后再次生成代碼，等到交付到開發(fā)人員手中需要實(shí)現(xiàn)的代碼時(shí)，需要做的工作已經(jīng)很少很少，要做的事情已經(jīng)很好。“卓越的本質(zhì)就是每件事情做得都比其他人好一點(diǎn)點(diǎn)”，XDE就是一個(gè)這樣的工具。對(duì)于此如果有興趣的讀者可以在IBM Rational的網(wǎng)站上找到相關(guān)的下載，當(dāng)然了，這是一個(gè)比較昂貴的軟件。
NDoc
Eric的團(tuán)隊(duì)依舊很懶惰，很不愿意編寫程序文檔，很許多人堅(jiān)持的觀點(diǎn)一樣“代碼就是文檔”，但是從幾千幾萬行的代碼中去閱讀確實(shí)不是一件容易的事情。如果你熟悉C#，應(yīng)該知道VS.NET IDE對(duì)于其提供了XML注釋的支持，對(duì)于使用VB.NET的朋友，在SourceForge也可以找到相關(guān)的輔助工具。一個(gè)良好的設(shè)計(jì)一定會(huì)有良好的代碼注釋，那么怎樣提取這些代碼注釋，然后用統(tǒng)一的文檔來展現(xiàn)呢？
也許你熟悉了CHM格式的文檔，也許熟悉Java Doc風(fēng)格，也許熟悉MSDN風(fēng)格，如果專門花費(fèi)時(shí)間來制作這些程序文檔是耗時(shí)耗力的事情。NDoc，從Java Doc借鑒過來的一個(gè)工具就是來解決這個(gè)問題的，它可以從C#生成的XML注釋文檔和程序集提取相關(guān)信息，然后根據(jù)你的需要生成指定格式的文檔。如此一來，你還需要專門的文檔人員來幫你寫程序文檔嗎？
NUnit
如果不知道如何測(cè)試自己的代碼，那么你絕對(duì)不是合格的程序員，如果你不了解測(cè)試驅(qū)動(dòng)開發(fā)，那么你也不是合格的程序員。這話或者太絕對(duì)和偏激，但是TDD已經(jīng)成為一種推薦的開發(fā)方式，“測(cè)試先行”也得到越來越多開發(fā)人員的接受。如果你以前對(duì)于一些業(yè)務(wù)代碼的測(cè)試是利用控制臺(tái)或者測(cè)試網(wǎng)頁來完成的話，那么我建議你一定要先去看看這個(gè)工具——NUnit，創(chuàng)意依舊來自于軟件過程更加成熟的Java社區(qū)，相信你看看所有的綠燈亮起的時(shí)候，你會(huì)有一種無比的成就感。可以從
http://www.nunit.org 得到相關(guān)的軟件。
SourceGear Vault or VSS
別告訴我你沒有用過版本控制工具，假若如此，那么將給軟件開發(fā)過程引入無盡的風(fēng)險(xiǎn)，沒有版本比較，沒有代碼追朔，沒有項(xiàng)目分支，團(tuán)隊(duì)的開發(fā)人員將陷入?yún)f(xié)作的災(zāi)難之中。作為老牌的版本控制工具Visual Source Safe沒有作為我的首選推薦，原因在于除了版本相對(duì)老化（6.0以后沒有大的更新），最主要的因素在Internet時(shí)代居然只能夠通過局域網(wǎng)共享訪問的方式來實(shí)現(xiàn)代碼庫(kù)的訪問?；蛘咔∏∫?yàn)槿绱?，也造就了版本控制工具的百花齊放，除了大名鼎鼎的CVS，但是這個(gè)在Java世界如日中天的家伙卻不是那么適合.NET開發(fā)，或者是因?yàn)楹蚔S.NET IDE集成不夠的原因，或者是因?yàn)閮蓚€(gè)社區(qū)不同的問題。幸運(yùn)的是，在.NET下面除了VSS 6,我們還有很多選擇，如VSS Remoting或者SourceGear的Offsite，他們都在VSS的基礎(chǔ)上提供了Internet遠(yuǎn)程訪問的能力。
在這里推薦Vault的理由很多，因?yàn)樗赟QL Server，因?yàn)樗褂?NET編寫，因?yàn)樗捎肵ML Web Services作為通信協(xié)議，當(dāng)然還有一點(diǎn)別忘記了，SourceGear Vault提供了免費(fèi)一個(gè)月10用戶的試用授權(quán)，如果不怕麻煩的話，您也可以每個(gè)月更新License。在使用習(xí)慣方面和傳統(tǒng)的VSS區(qū)別不大，沒有太多的學(xué)習(xí)代價(jià)，另外還提供了Web訪問代碼庫(kù)的功能。可以從
http://www.sourcegear.com/vault 的到相關(guān)的下載
SourceGear Dragnet
這是最后一個(gè)工具，一個(gè)大多人忽視的環(huán)節(jié)。你是否在最后的測(cè)試階段和需求還有測(cè)試人員牽扯不清，也沒有一個(gè)定量的指標(biāo)去衡量軟件開發(fā)質(zhì)量，這個(gè)時(shí)候缺陷管理也就是我們通常意義的BugTrack就顯得至關(guān)重要，作為和Vault同一個(gè)公司的產(chǎn)品，除了Dragnet正是針對(duì)如此問題而提出的解決方案。除了基于Web和.NET之外，Dragnet做到了和Vault的無縫集成，開發(fā)人員可以在VS.NET的環(huán)境中直接更新各個(gè)錯(cuò)誤。
工具為本？人為本？
不要期待工具可以解決你所有的問題，問題因人產(chǎn)生，工具因?yàn)閱栴}創(chuàng)造，但是在開發(fā)過程中如果能夠有效的利用一些工具減少不必要的重復(fù)或者提高團(tuán)隊(duì)協(xié)作，何樂而不為呢？隨著Visual Studio 2005的臨近，我們看到了另外一種選擇——Visual Studio Team System，這個(gè)VS.NET的第三個(gè)版本將前所未有的強(qiáng)調(diào)軟件工具化和開發(fā)協(xié)作化，或者，再過幾年，Eric的團(tuán)隊(duì)不用那些組合工具，但是想法依舊沒有變。
做你自己的軟件，懶惰一點(diǎn)，規(guī)范一點(diǎn)，自動(dòng)一點(diǎn)，只有你意識(shí)到使用工具多一點(diǎn)，才可能構(gòu)建出流水線的軟件過程。
作者Blog：
http://blog.csdn.net/liuruhong/
