軟體設計與交易<1>

軟體設計階段是否需考量實體系統環境的配置?個人認為是 “Yes”。因為設計並非「昧於事實」。

舉個例來說,Architect 檢視 Designer 所繪的循序圖,他需要瞭解到交易的源頭(Transaction Root)是起始於那個物件?
若是 Transaction 是自 Server Page(如 ASP.NET or JSP/Servlet)啟始,那可能是 “Bad design”;
若是 Transaction 是自 Control Object 啟始,但與 Desinger 溝通,發現到 Control Object 是被設計為 “Stateful” 物件,哪麼,這也可能是不佳的設計。

為什麼?因為交易根物件(Transaction Root Object)在符合 “ACID” 的四項原則下,盡可能交易一完成就立即釋放資源(Resource),這是實體 3-Tier 典型的特性。所以,Architect 此時就必須與 Designer 溝通:交易根物件設計為 “Stateless” 物件較為適宜。

軟體設計者若依循古典物件導向,沒有考量到分散式系統的設計,因而,都假設所有的物件為 “Stateful”,且對交易等的問題,認為是至實作面才去解決。哪麼,很有可能變成是 “紙上談兵”,往往 Designer 與 PG 之間就會溝通上的衝突了。

什麼是軟體設計(Software Design)?

為了包容複雜,軟體設計會投入大量心思精力,追求一致、和諧、平衡、穩定、永恆之美,直到開發出偉大軟體之後,大量複製,就會發揮規模報酬遞增的鉅大經濟效益。所以,軟體業的特性就是:設計、研發的成本很高,而利潤遞增的經濟效益極大。這也是知識經濟的特色。

當我們瞭解把軟體與人腦視為同等級時,就會知道軟體需要精心設計,而不是只有寫程式而已。

設計者不是只追尋一條工程化的步驟,而忽略設計所需的藝術美感素養。軟體開發如果太過於工程化、數學化,會把軟體設計(Software Design)視為程式設計(Progarmming),貶低了軟體設計的無形、重複、利潤遞增的高度價值。

軟體設計就像莎士比亞寫劇本,程式設計就像照劇本演戲,所以軟體產業的高度價值在於軟體設計,而不是寫程式。軟體設計的藝術成分較高,程式設計的工程成分較高;這與建築業很類似。

XP(Extreme Programming) 帶給我的啟發是什麼?

約半年至一年前,把 XP 系列的譯作全買回來。並且利用在廁所裡、開車等紅燈及等朋友時看完(其實,原文的我也有買,但必須承認,看得很吃力,況且,在廁所裡總不方便用翻譯電子辭典來查單字吧 ~_^)
** 感謝李潛瑞兄等諸位譯者,能翻譯出如此高品質的中文譯作。

整個系列看完後,該忘得全都忘光了 🙂
不過,一輩子都不可能忘掉的是:

  • Kent Beck 真得是了不得的大師!他能融會生活哲理平實的一面帶入到軟體技術與專案實務管理上。而不是死板板的講一些意義不太大的專業技術用語。難得!!
  • Kent Beck 的媽媽教他開車時不是把方向盤固定不變在同一個位置,而是隨時修正,以保持在正確的路線上。
  • XP 的四大核心:Simple(簡單)、Communication(溝通)、回饋(Feedback)、勇氣(Courage)。
  • 感謝 Kent Beck、感謝 XP,能讓我學到以上三點,終生永難忘懷,實在是受用無窮!!

    至於,XP 所提的「十二項實務」,我好像幾乎忘光了 ~_^
    大概只對於 “Test First”,特別情有獨鍾...

    倒是,為了能更多體會 XP 的四項核心,個人花了非常多的心思研究:

    為了瞭解 “Simple”,我買了一本「簡單就是力量」,研究為何簡單可以產生力量?如何從複雜的事物中一眼就可以看透它單純的本質。
    也研究收納櫃的整理術,為何它可以把雜亂的東西都收納起來,使得從表面看起來可以變得是「序中有亂(不是亂中有序)」。
    另外也仔細研讀 Grady Booch 的 “Object-Oriented Analysis and Design” 一書的第一章:Complexity。開宗明義即提到:軟體的複雜度是屬於本質性的,是無可避免的。並藉由其它領域包括自然生態界及PC硬體產業來說明複雜系統的結構。藉此以瞭解如何觀察及分析複雜系統、如何組織及瓦解(或稱為分隔)複雜系統...

    為了能體會 “Communication” 及 “Courage”,我研究了非常多的成功潛能書籍,包括拿破崙‧希爾、卡內基、Brian Tracy、易發久的著作。甚至,還參加了在日月潭辦的成功潛能開發學習營(主題是溝通,不過,整個過程感覺比較像是鬧劇)。
    溝通難不難?對我真的是很難,畢竟,人總是有”性格上的缺陷”,經常,我還是會把所謂學習得來的 “知識” 據為已有,而以此與他人辯論,甚至有點高傲、不屑的態度。
    感謝好朋友的提醒及從成功潛能開發的書籍上所體會而來的,逐漸地在修正我個人的劣根性 🙂
    推薦「卡內基溝通與人際關係」一書,寫得真的很棒!

    不過,對於 “Courage”,這倒是我的專長 ^_^
    我認同「打造自己的成功」一書提到:人有選擇的自由與權利;但是,相對地,也要能為自己的選擇所付出的代價承擔。所以,當你作了選擇之後,也就沒有什麼所謂的後悔與不後悔的。
    我更贊同拿破崙‧希爾「思考致富」一書的 “PMA(Positive Mental Attitude)” 黃金定律,同樣一件事,往正面積極思考時,結局會是與悲觀主義者大大地不同。

    最後,對於 “Feedback”,更讓我更用心去體會 “Iteration” 的意涵。”四星上將” 及許多 O-O 書籍是以 “Spiral” 這個字來替代。
    “Feedback” 與 “Iteration” 絕對是息息相關的,因為,快速回饋,可以儘早地瞭解問題及風險所在,進而 “修正” 執行的步驟。
    極強烈推薦 Brian Tracy 的「吃了那隻青蛙」,讓我瞭解到何謂 “Backward Planning”,又如何與目前的行動來結合,並從行動中逐步修正及 Iterate 你的 “Plan”。
    另外「富爸爸‧窮爸爸-有錢有理」一書中也教你:對於夢想,盡可能地遠大及雄心抱負;但對於目標的設定,他建議作一個 “不太成功的人”,而不是 “過度成功的人”,也就是說,採取初級步驟,一次只走一小步,而不要試圖邁向一大步。

    為了更能體會 “XP” 的本質,我發了很多時間在以上主題的研究上。
    值不值得?我只能說,研究這些書籍及其作者們的觀點,真得是太有趣了!經常會有意想不到的收穫。

軟體系統是收集使用者需求建構而成的嗎?

軟體公司的 PM(Project Manager)一向重視的是如何在不合理的開發時程下完成專案的開發。許多 PM 也認為他們認同物件導向及如 RUP/XP 的開發流程模式,認為如此他們可以縮短開發的時程。

個人最常與 PM 們討論的一個話題是:軟體應用系統是否係由使用者的需求收集而來所建構而成的?
絕大部分的 PM 的回答是:Yes!

為何問這個問題?個人發現到 PM 一定會先請 SA 訪談客戶的需求,並記錄在 Use Case 敘述內。再由 SD 針對 Use Case 敘述來找出領域物件(Domain Objects)。

在這樣的開發流程下,顯然使用者需求(Use Requirements)是重於軟體結構(Classes)的。所以,Use Case 是目的;Classes 是手段。

有沒有道理?在某種觀點及假設下,可能有道理!

只是,讓我們回想 RUP 所建議的最佳實務作法:”Use Case Driven;Architecture Centric”。

那麼,PM 既然認同 RUP 的開發模式,但是是否有仔細分辨倒底系統開發的方式是 “Use Case Driven” 或者是 “Use Case First” 呢?

有趣的問題,留待各位一起討論!

軟體設計思維應跳脫思考的桎梏

上上星期透過朋友介紹,至某知名教育訓練機構,討論軟體設計課程的合作方案。

在與一位老師閒聊閒聊當中,,談及他正在某資工所上課,他們老師正教授軟體開發製程,介紹到 “XP(Extreme Programming)” 的方法論。

一聽到 “XP”,我馬上精神抖擻起來~ 半年前我把 XP 的譯作約五本全在廁所看完,對於 XP 的哲理及其實務作法,非常地激賞。

哪位老師對 “XP” 的實務作法,一直很懷疑有可能可以在台灣的業界實施嗎?例如,他認為 “pair-programming”、”客戶駐點”,根本是脫離現實的。

聽到這...我的感觸很深,哪位老師直覺是認為 XP 的實務不容易也不一定適用在國內的軟體業界。
但,我認為 Kent Beck(XP 教祖) 的本意不是要你去模仿及學習那 “十二項” 的實務吧?
XP 的 “十二項實務” 只是 “How-to”,”How-to” 會因為現實的環境而修正的。況且,為什麼我們不懂得再找出第 13、14 ...的實務呢?哪應該才是 Kent Beck 的本意吧?

“XP” 是因為 Kent Beck 看到軟體開發流程中,有太多 “昧於現實面” 的現象,尤其是 “人” 的因素往往是影響整個專案成敗的主因。

Kent Beck 從 “本質” 去思考,發現到 “簡單”、”溝通”、”回饋”、”勇氣” 這四項要素是軟體專案開發的核心,從這四項基本元素,才去找出 “十二項實務” 的 “How-To” 來解決現實面專案開發的問題。

我想表示什麼呢?軟體設計人員不能只看到 “XP” 所提供的 “How-To”,就去模仿使用,然後應用在實務不成功時,就怪東怪西的、或心情沮喪、或覺得根本無法與現實結合...

能不能跳脫那所謂的 “十二項實務” 呢?那重不重要?當然重要!
但,更重要的是,是否你能真正用心去思考那四項基本要素呢?

什麼是簡單?為何要簡單?為何簡單是力量? —> 如何達成簡單呢?
為什麼溝通是重要的? —> 如何達成順暢、和諧地溝通?
什麼是回饋?為何回饋可以降低風險? —> 如何達成快速回饋呢?
為什麼要有勇氣? —> 如何提升自我及團隊的自信心呢?

What?-> Why?-> How-to
軟體設計人員可不能再只把焦點擺在 “How-to” 而已,哪未,整個思考就僅會落在 “How-to” 的框架桎梏之內~
跳出 “How-to”,勇於思考本質、勇於創新、勇於找出自己的 “How-to”、勇於嘗試、勇於被批判、勇於修正...

如此,軟體設計者才會有無限地想像與創新,並可以有屬於自己的 “XP” 了!!

解讀『XP軟體製程』的字面意涵

XP 的全名:Extreme Programming。
中譯本其中有三本翻譯為”極致軟體製程”;一本翻譯為”極端軟體製程”。

哪一個比較符合 XP 的原意?
個人到認為,這兩個解釋都很合理!

翻譯為 “極致“,代表如何把軟體製程做到 “最善”;
翻譯為 “極端“,則表示基於現實面的考量,可能會顛覆傳統的軟體製程觀念,如 “Pair Programming”、”客戶駐廠”...等,是一般傳統的軟體開發人員所無法想像的!

軟體思維顧問

專職軟體輔導與教育訓練的獨立顧問。輔導企業資訊單位如何有效組織系統開發與維護;輔導開發人員達成有效的專業分工。傳授如何把軟體作軟 (Keeping Software Soft)的技能,得以提昇系統的彈性/延展,並進而創造系統的再利用價值。

Personal