Benx Blog

三月 23, 2007

Diigo Diary 03/22/2007

Filed under: Diigo Diary — benxshen @ 8:30 上午

java.net: Developing Applications Using Reverse Ajax

Download details: IE6 App Compat Test Image Annotated

Internet Explorer 6 Application Compatibility VPC Image

Brief Description

VPC Hard Disk Image for testing websites on IE6 SP2

Neal Gafter’s blog: A Definition of Closures

矇矇的秘密基地 – Post details: {程序員邀稿} 從軟體架構師(Architect)的觀點來看軟體開發流程 Annotated

軟體的開發,最終目標雖然是 “完成高品質" 的軟體系統,但在進行階段過程中,所衍生出的兩大議題—專案管理(Project Management)與開發流程(Development Process),卻是首要需克服的階段目標。

專案管理講究的是 “領導統御"、"人和";開發流程重視的是 “調和 (凝聚團隊成員的觀點、角度,保持產出的一致性)"

不應該視善變為畏途,反而是把變動看成是理所當然,更是多添了許多的好機會。我們所要作的事情只是,如何將變動抑制或收斂在某一程度可以被控管的範圍內,同時,學會如何在某一問題領域(Problem Domain),重覆性、同質性高的軟體系統,來找出不容易變動的部分,成為系統的框架(framework),或稱之為主結構(Main-Structure)。而容易變動的部分,又是如何從主結構中抽離出來,爾後只花少許的 “工作量(effort)",就可以輕而易舉的滿足客戶的需求。

正是由於 “變動無常" 的軟體開發專案,有些人的想法是想要 “凍結" 住需求,然後依照固定不變的製程,一個階段接續下一個階段以循序式 (Sequential)的開發產出 (artifacts),例如預估一年開發期的專案,三個月的系統分析(SA, System Analysis)、三個月的系統設計(SD, System Design),六個月的實做與測試(Implement and Test),這樣的開發方式稱之為 “瀑布式(Waterfall)" 的開發流程,參考如圖1。

[More:]

圖1、循序式的開發流程
圖1、循序式的開發流程

瀑布式另一個重大的危機是當你在需求、分析設計階段所產出的藍圖及文件,當施工時卻發現窒礙難行,此時才發現設計有嚴重瑕疵,而造成整個系統的崩潰。 Phillippe Kruchten 在 “The Rational Unified Process An Introduction" 一書講得好:軟體工程目前還無法與其它的工程領域並駕齊驅,因為基礎理論很薄弱而且缺凡瞭解,此外探索的方法也非常粗糙。他認為:"軟體工程" 這個字可能取錯了,在不同時候,它多半是心理學、哲學或藝術的分支,而不是工程學。

個人一直視 Martin Fowler 的一句話為聖經: “Keeping Software Soft !"。筆者是把該句話解讀為: “把軟體作軟!",但重點是,如果軟體人員的頭腦僵化不夠柔軟,又如何能把軟體給作軟呢?

I&I (Iteration and Incremental) 的開發模式

現代主流的軟體開發流程(包括 RUP/XP),均是提出了 “I&I (Iteration and Incremental)" 反覆漸增的開發模式,來解決 “瀑布式" 諸多的問題。 Iteration 其實就只是,把整個大型專案的生命週期,分成好幾個有某些程度關連的迷你專案,每一個迷你專案有自己的開發循環,包括分析、設計、實做與測試等。到底有多迷你? 筆者在輔導開發時,是以 “使用案例 (Use Case)" 或是 “功能點(Functional Point)" 為功能單位,作完上述的開發循環,大約是一個星期,而最晚不得超過兩個星期! 請注意,是包含分析設計與實際可執行的程式碼(包括測試程式碼)喔。而一個功能單位,會視複雜度切為 2~5 個 Iteration,從第一個Iteration 對框架目標的建立、然後逐漸加入細節,從低精確度往高精確度、到最終來完成定案的產出。反覆式的開發方式參考如圖2。

圖2、反覆式(Iteration)及漸增性(Incremental)的開發方式
圖2、反覆式(Iteration)及漸增性(Incremental)的開發方式

以架構為中心,就是希望擔任各個角色的軟體開發成員,都能對開發中的系統有一致性(consistence)的全貌見解。專案中有架構師最好 (若沒有,也最好組成架構團隊),他必須具備關照系統整體觀的能力,也需要時時刻刻來 “調和" 各個角色的觀點與產出。擔任架構師者,可不是只偏往實做面的平台技術(這其實是技術長的執掌),還包括與領域專家(Domain Expert)的溝通,如何萃取其智慧,並得以抽像化(abstract),分離出善變的功能部分,與比較穩定、重用價值高的主結構部分;他同時也知道該如何與 IT 平台的專家合作,將源自於領域知識的需求  軟體設計模型,具體實現在企業層級的平台(包括 .NET, J2EE 等)

以架構為中心,那麼具體的呈現會是什麼呢?參考下圖3,RUP 是提出 “4+1″ 的架構觀點,筆者是把它再精簡一下,只用了三個觀點來代表架構的呈現,而每一個觀點,會有其開發產出 (artifacts),並可能成為另一個觀點的參考來源。這裡筆者直接舉小小的例子,來說明下圖的意涵。

圖3、以架構為�心、動態調和軟體開發的三大構面
圖3、以架構為中心、動態調和軟體開發的三大構面

從需求分析、結構設計到系統的實做(同時就會涵蓋到上述三個觀點),是要快速循環、走過一遍的。再次強調,每個 Iteration 的開發週期是以 “週" 為單位,最晚不得超過 2 週。如果將每一個功能單位(使用案例或功能點)規劃為三個Iteration,每一個循環要作的事可能是:

Iteration #1:確認使用案例所要完成的目標(Goal),建立結構與程式碼框架,找出從分析至實作的風險因子,建立溝通的管道。
Iteration #2:將實現使用案例的細節部分補足,包括規則、流程、欄位明細與資料型態等。
Iteration #3:作例外處理(Exception Handling)的考量與實現。

以架構為中心,必然會是學習型的開發團隊,相當重視對整體的關照與大量的溝通。

Home – Lambda Probe Annotated

Welcome to the home of Lambda Probe (formerly known as Tomcat Probe) – the ultimate tool for monitoring and
management of
Apache Tomcat instance in real time.

Gmail Air Skin – Userscripts.org Annotated

  • 如果你也安裝了 greasemonkey 並且也是 gmail 的愛用者,那麼,絕對不能錯過這個 userscript 喔!
    試用玩玩看吧! – post by benxshen

Not available now

1 則迴響 »

  1. It’s great to read all this fascinating info. I’ve bookmarked your site.

    迴響 由 med assistant school — 四月 10, 2011 @ 5:15 上午 | 回覆


RSS feed for comments on this post. TrackBack URI

發表迴響

在下方填入你的資料或按右方圖示以社群網站登入:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / 變更 )

Twitter picture

You are commenting using your Twitter account. Log Out / 變更 )

Facebook照片

You are commenting using your Facebook account. Log Out / 變更 )

Google+ photo

You are commenting using your Google+ account. Log Out / 變更 )

連結到 %s

在WordPress.com寫網誌.

%d 位部落客按了讚: