2007年7月5日 星期四

敏捷開發的比喻

書摘:O'Reilly軟體預先架構之美學 (Prefactoring)

敏捷開發(Agile development)很像輕裝健行。輕裝健行者攜帶的裝備比平常健行者少很多。因此,他們可以走得比較快,花的精力也較少。

輕裝健行者也比平常健行者更有經驗。他們只帶必要配備,也就是完成旅程必要的東西。技巧、知識和經驗則完成了整個圖像。他們知道怎麼以最簡便的遮蓋物紮營取暖。他們知道上哪找水,所以他們只帶少量的水。

要當極致輕裝健行者,那可是需要不少技巧和經驗。某人必須能夠利用大自然的材料做出必要的東西。

另方面,重裝健行者會覺得他們必須帶上所有必要裝備,以應付他們可能碰上的任何情況。他們的裝備給了他們安全,然而,也會讓他們慢下來

Read More......

2007年7月1日 星期日

(2007.6月號-161期)_持續性整合開發導論(下)

持續性整合的實踐:選用合適的CI伺服器

持續性整合開發可不是有了專案建置工具與貫徹測試優先原則就沒事了。要記住現在不是單打獨鬥的時代,講求團隊合作,因此不論是公司內參與的開發人員或者外部協同合作的廠商,都會對開發的成果產生重大的影響,因此如何即時掌握專案整體的開發狀況就是另一項挑戰。


Continuous Integration Server又稱CI伺服器,就是用來管理協同開發的持續性整合工具,目前常見的有:

  • CruiseControlJava社群中老字號的CI工具,擁有完整的CI所需功能。

  • Continuum:為Maven的子專案,算是後起之秀,設定方便為其優點。


CruiseControl它於2001年發佈已經有五年多的歷史,在許多方面,CruiseControl 伺服器 已經成爲持續整合的同義詞,完善的對大多數版本控制伺服器的支援並方便進行擴充,安裝容易也是其優點,如果硬要說個缺點的話就是CruiseControl對於專案持續性整合是基於XML的設定,非常靈活而且彈性,但對不熟悉的人來說,有點困難,包含的Web的管理介面,對於專案的掌控來說非常方便。


Continuum2005年發佈是最新的CI 伺服器之一,支援AntMaven1Maven2Shell進行專案的建置,也支援了大多數的版本控制伺服器,同CruiseControl一樣也擁有Web管理介面,並且可直接在Web介面上進行CI伺服器的設定,相對於CruiseControl來說比較方便,但以靈活度與擴展性來說,就比較差了,且因為推出時間較短,某些功能還不齊全。


到此我們可知完整的持續性整合開發環境至少必須架設版本控制伺服器與持續性整合伺服器,參考圖 1所示,開發人員與協力廠商開發平台持續對版本控制伺服器提交修改完成的程式碼,而通常在提交前會先取得目前最新的原始碼進行測試,當確認不影響版本控制伺服器上的原始碼後才進行提交。持續性整合伺服器可設定特定時間,當發現原始碼已經發生變化時,執行取得原始碼動作,並進行編譯與測試,此時將可完整的知道目前開發專案的穩定狀態,可設定持續性整合伺服器當專案建置成功或失敗時通知相關人員即時進行問題排除。


通常在CI伺服器發生建置失敗的原因,除了一般的程式碼錯誤外,開發人員未提交所有程式碼檔案或未解決程式碼衝突就提交也是原因之一,前者是開發人員針對多個原始碼檔案進行了修改,但因經過了一段時間,已經不確定到底有那些檔案需要提交而造成的問題。後者是當程式碼在版本控制伺服器上同一個時間有多個開發人員進行了修改,後者提交時會提示發生了檔案衝突,而開發人員未解決重覆提交產生的問題。這些問題的發生事實上都是開發人員對版本控制觀念的認知不足所致。無論取得或提交原始碼時需對整個專案進行,才不會遺漏掉必須提交的檔案。版本衝突時相對於版本控制系統都會有一套解決衝突的流程,只要小心都能避免。



1 持續性整合開發環境


持續性整合的分析:產生可供評估的報表

開發過程中文件的產生是很重要的事,開發前期的系統分析、系統設計文件,開發中的原始碼進度與狀況追蹤報表,開發後期的元件使用手冊、系統操作手冊,無論是任何一份文件都是目前專案開發所需要的重要參考。但傳統軟體專案的開發多數文件的產生都是由人手工去撰寫的,若要在開發人員在開發過程中還必須挪出時間進行文件的撰寫,對於開發人員來說是非常痛苦的事。


更重要的是,開發過程中程式碼會變,所產出的文件當程式碼一改變可能沒多久就過時了。因此在業界有多數狀況都是專案開發前期非常認真的撰寫相關文件,開發中期發現文件內容跟不上程式碼的變化索性就暫時放一邊,打算等之後再統一寫,到了開發後期要不就是因為專案的Delay或失敗而成為一個沒有文件的專案,就是根本忘了到底新增了那些功能而成為一份殘缺不全的文件。


因此在多數的敏捷開發原則中就提出了,最好的文件就是原始碼,首先為了讓原始碼在日後維護容易,必須在撰寫程式碼時保持程式碼的可讀性,並且必須統一程式碼的風格,訂定統一的開發規範,在一定程度上降低對文件的依賴,另外透過在程式碼中順手加上的文件資訊也就是所謂的Java Doclet的註解型式,配合相關的Doclet工具,就可隨時產生符合當時狀況的Java Doc說明文件。


為了追蹤專案開發進度與協助程式碼進行分析與重構,在此列出常用的持續性整合開發程式碼分析工具:

  • CheckStyle:檢查程式碼撰寫風格是否符合規範。

  • PMD:靜態程式碼分析工具,可用於找出潛在錯誤程式。

  • JavaNCSS:協助在開發過程中檢查出程式碼的複雜度。

  • Cobertura:於執行期檢查執行與未執行程式的測試覆蓋率檢測工具。


CheckStyle是自動化程式碼風格檢查工具,在傳統的多人協同開發中,可以發現每位開發人員都有相異的程式碼風格,少數有經驗的開發人員在風格上都有一定程度的好習慣,但在程度參差不齊的參與者中,很難保證有一致的Code StyleCheckStyle工具設定了一份規則文件,於建置時期對程式碼進行檢查,將不符合規範的資訊列出,因此開發人員可透過這份資訊了解本身所撰寫的風格是否合乎需求,並進行改進。如此一來維護程式碼就變成一件容易的事,畢竟誰都不想維護一份有怪異風格的程式碼。參考圖 2所示的CheckStyle報表,提供了InfoWarning、與Error的訊息,並緊接著列出錯誤原因與行數。


PMD是一個Java原始碼分析工具,透過一系列的規則比較可以協助找出潛在的Bug,包含 16 個規則集合,涵蓋了所有 Java經常發生的問題,如不良的命名規則、無用而未移除的程式碼、藕合度分析、不良的異常使用…等。在此我們參考圖 3可看出,該PMD報告說明了有40個檔案找到了65個錯誤,並且列出了錯誤原因為import了未使用的類別,還有包含了一個空的Exception區塊。由此一來開發人員可移除無用的import而不會造成日後不使用相關jar檔後造成的編譯錯誤,處理Exception區塊以避免日後發生問題後無法得知究竟異常原因為何。當然除了PMD所內建的檢查機制都可以因專案的需求進行修改,並可自行撰寫新的規則。



JavaNCSS用於進行原始碼的複雜度分析,NCSSNon Commenting Source Statements也就是分析非註解的原始碼資訊,聽起來似乎沒什麼但實際上JavaNCSS首先幫我們列出了前30名程式碼行數最多的類別,其次列出了前30Method最多的類別,供開發人員分析是否包含了過多無用的程式碼或者該類別給予了太多的責任,由此進行重構的考量。另外最重要的部分列出了前30MethodNCSS資訊,通常當Method中的程式碼行數過長,相對的也代表了有較高的NCCNCC所指的是Cyclomatic Complexity Number意指為程式的複雜度,在MethodNCC愈高,事實上就愈不利於日後的維護,因此NCC的數值將是重構的重要依據。參考圖 4


Cobertura是西班牙語覆蓋的意思,這個工具可以協助在進行單元測試的過程中統計已測試過的類別與未測試過類別的資訊,參考圖 5中明顯可知,當測試覆蓋率到達100%時也就代表了該類別中所有功能都至少被完整執行過1次以上,而覆蓋率分為Line CoverageBranch Coverage代表著一般程式碼與有分支判斷的程式碼(例如:if elseswitch或迴圈等),當然分支愈多代表著該類別的複雜度愈高,撰寫高覆蓋率的測試程式碼就愈困難。在進行程式碼開發的過程中如何撰寫功能強大、程式複雜度低而高測試覆蓋率的系統是每位開發人員的理想,而透過工具的分析,可讓開發人員的理想更趨近於真實。


2 CheckStyle報表。

3 PMD報表。

4 JavaNCSS報表。

5 Cobertura報表


結論

持續性整合開發為專案帶來了高效率、可控管、靈活有彈性的開發方式,透過專案管理與建置工具的協助,能夠很輕鬆在專案編譯過程中產生所需的專案開發資訊與分析報表,這一切的一切都是自動化的。透過報表資訊的產出可以減少開發人員手工檢查的時間,帶來了更高的效率與生產力,透過持續性整合伺服器的快速回饋,可以即時掌握目前專案原始碼開發狀況,徹底解決了企業及大型專案協同開發的管理問題。記住所有專案的開發都會發生問題,但持續性整合開發能在專案進行過程中持續發現並盡速解決問題,在開發的每一步降低風險,要知道愈晚發生問題所衍生的維護成本會是早期發現的十倍甚至百倍。



作者介紹

盧建州 <jazz.lu0827@gmail.com>

有多年軟體開發經驗,注重軟體工程並善用Design Patterns。專研於JavaOpen Source解決方案、跨平台技術與其異質資訊系統整合。目前為自由工作者。

Read More......

上帝的安排

上帝給每個人都有了絕佳的安排。
了解並且利用的人認為…上帝是眷顧我的!
誤解而且自怨自艾的人認為…上帝遺棄我了!

要知道
出現難題就代表了要換個方式思考…
情況不如預期也許才是最好的安排…

反而一切若順利到不可思議的地步時…
也許你只要再往前踏一步,就會掉入無可回天的深淵。

Read More......

接下來的兩個月

兩個星期了吧!端午節過後我就讓自己處於放鬆的狀態,因為我知道剩下兩個月的時間必須要開始精實了, 雖然這些日子多多少少都在接觸一些工作,但我認為還沒真正做出個自己要的東西。

不過並非代表又要進入一個從頭開始的階段,所意謂的是之前的我已經做好了準備工作,接下來該是將這些觀念、架構、邏輯與元件進行總整理,將其轉化為武器、防具與兵法守則來裝備在身,而在未來的日子裏將協助我攻城略地,所到之處將攻無不克、戰無不勝。

Read More......

收心操:不看會後悔的「Transformers(變形金剛)」


明天要收心認真了,但總覺得還沒休息夠,大概是玩心一起就很難收了吧!
昨晚一想,給自己再放縱一次就收心。
嗯!那就去看之前一直想看的那部片吧!今早約莫11點左右到了西門町,想都沒想就往國賓戲院走了去,
前幾天在網上看「變形金剛」場場客滿,總覺得不太相信,記得前陣子跟力特的朋友來看「史瑞客3」時,一樣也是
假日,人就沒有很多,也沒什麼人在排隊。不過今天一看,哇塞!人超多…要排到什麼時候呀?前次來沒看到,今天到是滿多人在賣黃牛票的。
用目光稍微掃了一下之後就給他放棄了,因為我不太想跟一大堆人擠。

轉向朝捐血車的地方前進(前幾天捐血中心發通知可以再捐了),第二個狀況出現,哇咧…下午一點後才開放捐血。
正當覺得今天西門町是白來的正準備打道回府的時候,耶!我發現對面的今日影城也有上映「Transformers」。
問了賣票美眉後,當下決定就在這看這部片吧,利用了點開場前的時間到附近的誠品逛了一下,預先挑了幾本書,
預計等電影看完、捐完血後再過來買。

電影開場了,老實說…遠遠超過我的想像…,網路上看過的人提出的感想並不誇張…,有人說特效超讚、劇情緊湊沒有冷場。
有人說這部片非常搞笑,女生也非常適合來看,聽說劇場中女生笑的比男生大聲。而多數人都說,有機會會再看一次,
更有人身體力行已經看過二次以上了。

當時看到"搞笑"二字,怪!這不是科幻片嗎?好像從沒看到科幻片有搞笑的劇情,今天一看…呵呵!的確…一定程度上應該算喜劇哦!
超喜歡大黃蜂那部跑車假裝拋錨時,使用收音機刻意製造出浪漫的氣氛,當女孩打算自已走路回家時,跑車迅速發動,收音機傳出
"Baby come Back..."這首歌,呵呵!真希望能有一部這麼懂主人心意的車呀!

沒想到今天換個方向走,就會有不同的巧妙安排「看電影」Check、「捐血」Check、「買書」Check…今天做了三件事了呢!
不過我想唯一美中不足的就是,沒進到「國賓」感受那音響的震撼力…說真的,我也希望再看一次「Transformers」但下次一定得在國賓看。

Read More......