最近稍微有點累~

看到自己七月份寫的 Blog,啊… 88| 才寫了 14 篇!!
這對我半年多以來,每個月所寫 Blog 文章均超過 20 餘篇來相較,真得是少了多了。

有個不算是理由的理由(算是藉口),這兩個星期教課還真有點忙,講課都講到喉嚨痛痛了。

˙ 7/23(星期六):軟體設計應用課程(1), 6Hrs 。
˙ 7/24(星期日):6th_UML 講座, 3Hrs。
˙ 7/25(星期一)、7/27(星期三):某大軟體公司的高階軟體設計課程, 4Hrs + 8Hrs。
˙ 7/30(星期六):軟體設計應用課程(2), 6Hrs 。
˙ 8/1(星期一)~8/3(星期三):友情贊助教授 Sun SCJP 程式設計認證課程, 6×3=18 Hrs。

嘿,上星期三的課程,可是要連續教上 8 個鐘頭,沒有點體力與耐力,還真不容易呢。尤其是我講課,還算有點認真,絕大部分都是連續好幾個小時站著講課的。主要原因是我比較傾向是觀念的傳授,而比較少帶領學員實做練習。

不過,最近可能觀念有些改變,仍必須視學員的程度而教授一些 “how-to” 面的實做練習,讓學員有點 “手感”,這樣我也會比較輕鬆。 😉

雜談 星期六(6/25) 的 UML 講座

上星期六,我們(HSDc.)舉辦了第五次的免費 UML 系列講座。到場來聽講的學員約有八、九成滿,近 90 人左右。講座舉辦至今,每場報名人數均超過 100 多人,到場的學員們也約有 7 成滿,約有 1/3 的學員成為熟面孔,甚至有幾位成為不錯的朋友,不錯,蠻愉快,也有成就感。

當初我推動舉辦免費的 UML 講座的動機很單純,就只是藉由 UML 來分享我與團隊其他 partner 對軟體設計的心得。再則,給自己一些壓力,每個月要準備一個主題,鍛鍊思考與寫作,久而久之,自然就會變成一種習慣,同時也把這一系列的講座變成是國內在軟體專業設計研討的主要活動,這也蠻有趣的。

當然,也有私心,畢竟,我們團隊的定位在顧問與教育訓練的服務上,是需要”養分”的。藉由講座與研討會,有機會可以”推銷”我們自己,若有認同我們所著墨關於在軟體設計的觀念,也覺得我們可以協助學員個人的成長,甚至,也相信我們有這樣的能力可以協助 ISV 或 IT 部門關於軟體設計、製程規劃、技術移轉等等。我希望是一種 “互惠”,能確實因協助到他人或公司而有回饋,甚或,造成對軟體業界的一些些貢獻,我覺得,這樣才會能維持我對軟體的熱情與使命,

因緣際會,認識了在美國 JBoss 任職的 Ben Wang,他是領導 JBoss Clustering & JBossCache-Aop 的首席技術長,星期六告訴他我們有這樣的活動,也特別邀請他客串講演一場關於 JBoss Enterprise Middleware System (JEMS) 的架構介紹。

中午就與他見面,我們團隊所有成員與 Ben 一起在文大教育推廣部的餐廳用餐(真好吃),相互交換許多心得,真好,收穫甚多,我們均有共識,覺得又有一波的軟體革命,也就是 “Open-Source” 的力量,這是無遠弗屆的,顛覆了太多商業經濟的模式,逐漸地讓產品導向推往服務導向的商業交易模式。

安排 Ben 在第三場講演,非常精彩,Ben 本人很認真,還利用中午時間修飾他的簡報。短短的 40 分鐘,大致勾勒出 JBoss 的 Business Model 與核心產品。我個人印象最深刻的是,JBoss 的使命宣言(Mission Statement)是:
利用最佳的 J2EE Applicaiton Server 提供給企業最佳的服務。

非常地明確!! 也感受到 Ben 本人非常熱情於現在自己的工作,40% 研發(Research and Design),60% 跑世界各地負責 Education Trainning。

Ben 因有事先行離開。我是負責最後一場,這次我所準備的主題是「活用狀態圖」,我花了約三天的時間同時看了五、六本書,感受到狀態圖是奇妙無窮,非常地有意思。甚至,讓我想到,可能有機會創造是軟體為主角、硬體是配角(與現在的市場剛好相反)的 “以軟帶硬” 的模式。

我也打算再多作一些研究,尤其是更具體地將狀態圖、狀態表的設計,轉成實際的程式碼。我打算,就將我對狀態圖的研究,規劃個約一天的課程來教授如何學會、活用及具體化狀態圖。

有一位學員,特地是從屏東到高雄小港機場坐飛機趕過來聽講,聽講完後馬上再坐飛機回南部。真讓我驚訝,也真讓我好佩服。還有一位任職於紡織業的 IT 主管,是自己一個人坐電動輪椅過來的。有許多這麼有心、認真的學員們,真的可以感受到他們對軟體的熱情與吸收專業知識的渴望。所以,更讓我覺得,每一場的講座,不能因為免費而隨便,用心地講述我們的心得與體會,也能有學員的互動回饋,並且讓學員們感受不虛此行。

幾位比較熟識的學員們,有些問題也希望能與我互動討論。我們約在隔壁的咖啡廳 “續戰”,聊到晚上 9 點多,東南西北,各種話題,都可以有得聊,挺有趣的。

回到家,已是 10 點多,我發現到,我的喉嚨沙啞了,因為,話講最多的永遠都是我。 😉

教了第一堂軟體設計基礎課程

今日早上(星期六),過去文化大學教育推廣部教授一整天「軟體設計基礎課程」,同時也是第一次文化大學教育推廣部針對軟體設計系列的課程開課。

廣告、行銷、口碑等,效果還沒有打出去,報名上課的學員僅 10 餘位。

基礎課程,強調的就是最基本對軟體設計應有的正則思維,這是我常一直強調的。最起碼的一個思維就是不能只是重視系統的使用介面與需求,這是屬於系統的外觀範疇。
而我個人,更為重視的是,系統內部的結構分析與設計。

至於重視結構的分析與設計,目的只有一個:侷限(或為收斂)需求變化在某一局部上,不會因變動的因素而牽動到整個系統,造成全面的癱瘓。

而這也正是系統複雜的本源,也可以說是複雜度就是系統的本質,這是避開不掉的。

為了處理複雜度,運用物件導向思維帶入軟體設計領域內,我是覺得再自然與再恰當不過了。
因為,物件導向不是技術,也不是方法論,它就是我們人原本就是以這種本質性的思維來看待與處理世界與周遭的事物。所以,我們只是改掉不自然的程序性(Procedual-based)的開發方式,而回歸至最單純的本質性思維,應用生活的哲理與智慧來處理複雜性系統的開發。

關於物件導向的思維,其中最精要的幾個哲理,包括了:

  • 複雜度的根源與觀點
  • 物件(Object)與類別(Class)
  • 概念(Concept)與抽象(Absstration)
  • 封裝(Encapsulation)
  • 介面(Interface)與多型(Polymorphism)
  • 物件之間的關係:關聯(Association)、Whole-part、繼承(Inheritance)

說真的,坊間一般談論物件導向的書籍,對於上述這些哲理的解釋,我仍覺得不足以協助我來教授這些哲理,尤其,我更需要凸顯的是,不是先從軟體的角度來看待上述這些哲理,而是因為這些哲理本來就存在現實生活及其它成熟領域上。所以,要解釋這些術語(Terminology),非從程式語言、非從 UML、非從語法定義(Definition)來看待,而是藉由純生活化的實例來做說明與解釋,然後再映對至軟體的設計模型及程式語言上。我覺得,這樣才不致本末倒置。

讓學員瞭解這些再自然不過的哲理後,再去教導學員如何將軟體設計的想法利用 UML 來表達。此時,才會開始介紹相關 UML、開發流程(Development Porcess)的基本觀念,再後續的課程,又會逐漸地說明如何活用 UML 圖表達軟體設計的想法,並利用現實的實際案例來做研究探討。當然,同時會產出 .NET 與 Java 的程式碼,來藉此說明在高階系統設計中,是確實可以與系統平台分離的。

我非常強調基本功夫的鍛鍊,而基本功夫的鍛鍊最最重要的是引導學員們具備反思的能力,這也代表了要能懂得去觀察,觀察什麼?就是觀察生活周遭的事物,觀察、反思、體會、表達…透過這些反覆過程,就會越能去參透反映在軟體系統設計上蘊藏於內的 “哲理與本質”。

這種過程,不是去找答案,一般軟體人員,太習慣也太依賴於去找答案。這種方式,正是讓一般軟體人員頭腦僵化的主因。反過來,要找的是問題,找的問題越多、問的問題越多、思考的問題越多,也不怕犯錯、也不怕羞。
就像小孩子這樣,經常保持高度的好奇心與觀察力,自然就會有旺盛的學習力。從不會去想問的問題是否會幼稚。如此,才會更容易促進思維的活化,就會有自己內心的體會,而能講出自己的 “話”;不是只單單去背那些坊間技術書籍的 “標準答案” 了。

我想表達的這些觀念,有留在我的腦袋,但還沒有以文字把它更條理分明的記錄下來。又,我所建議採用的書籍,包括參考書籍等,無法協助我去表達上述這些觀念。

所以,今天是採用口說的方式,佐以白版的來畫圖與文字說明,也沒有用到電腦,也沒有用到教材。就這樣,講了約五個鐘頭,授課教材的頁數是 “0” 。呵,這好像也創了我的紀錄。

當然,短期內我就會把這些想法與觀念寫下來,訴諸於文字要花很多的時間去仔細推敲用詞與合理性,這會比較吃力。但,這也是必然要做的事。

{草稿} 幾個點子的備忘錄

  1. 關於軟體設計的課程教育,我希望能推銷到 .NET 的族群。不過,我發現,國內應該算是首屈一指的 .NET 指標網站藍色小舖,其內「軟體工程」的討論版,實在冷的可以,相較於 JavaWorld,似乎 Java 這邊的族群對所謂「軟體工程」方面的討論還來得興致高昂。

    不過,對於 .NET 程式的實做討論,該小舖倒是人氣鼎盛。所以,我想到,應該要把文章是丟到如 VB.NET or C# 程式語言討論版才是。

    不過,若只丟如 UML 塑模之類的文章,好像也說不過去,畢竟,那是主要討論程式語言的專區。所以,我想到,來寫一個留言版 for .NET ,以 VB.NET and C# 來實做。

    當然,最重要的是推銷留言版的 “設計”。從 “需求分析”、結構設計,包括 Class 圖、Sequence 圖、E-R Model 等。再加上與平台面(.NET)相關的細部設計(Detailed Design),例如,如何反應設計至 ADO.NET 實做上,然後至 Coding 實做,以及撰寫測試碼...等。一氣呵成,很順暢地結合用 UML 表達設計、.NET 程式實做。 除了 .NET 版本,當然也可以實做 Java 版本,並同時可以展現高階的設計是確實可以與平台面分離的,只有到了細部的系統設計,才會加上與平台面相關的元件。

    然後,舉辦個課程說明會,參加者免費贈送留言版的設計文件及原始程式碼,並且在課堂中說明每一個階段的設計思維及如何承轉到 Coding 的實做階段。

    看看這樣是否能吸引到小舖的成員們對「軟體設計」產生興趣,進而想要學相關的課程。

  2. 有時候有些異想天開的情節,可能在夢中,也可能是寶貝女兒們的生活趣事。這些都可以觸發寫作童話故事的來源及靈感。

    所以,我想到,無論如何的無俚頭,就先以文字寫下來,同時也可以鍛鍊怪怪的想像力。今天晚上我就把我的想法與我的大女兒蓁妮討論過,我寫作,然後她畫插畫。

    嘿,她高興得很。我們約定好了,版權一人一半。 😉

做一個不太成功的專案

許多軟體工程師,他們經常有滿腔熱血,希望能將他們對於在軟體開發上所學的技術與心得發揮應用在工作的專案上。

也有許多開發團隊,僅接受幾天的 UML 與 OO 的教育訓練,就想 “應用” 在專案開發上。

有很好的抱負及理想當然是很好。不過,將新技術、新的開發流程應用在傳統的專案上,其風險很大。還不是普通的大,是真的很大的風險!

幾個關鍵的問題思考:

  • 團隊成員們的接受度如何?
  • 團隊其他成員的技術及技能夠不夠?
  • 該專案的開發時程及預算等資源,夠你 “實驗” 一些新的技術與製程嗎?
  • 最危險的是,導入新技術及製程的當事人或團隊,真的足夠具備該有的觀念與知識嗎?

例如,專案導入 “Use Case” 及 所謂 “物件導向” 技術。若對 “封裝(Encapsulation)” 沒有足夠的認知,根本不瞭解 “廣度” 與 “深度” 的表達,是很難寫好 “Use Case” 的;對 “Control”、”Entity”、”Boundary” Object 的責任(Responsibility)及本質都不清楚的話,該如何設計物件結構及表達物件之間的互動合作?;對於 “Stateless” 與 “Stateful” 物件都不知如何設計與搭配,又該如何開發 N-Tier 的應用系統呢?

單一個問題,是容易在專案開發的過程中,逐漸的克服及解決。但,一旦許多的問題一併發生時,那麼,難以發現的複雜度就呈現出來了。而且,無論如何,就是無法解決這些問題,而且,專案又面臨時程的壓力,結果,為了趕工,粗製濫造,一開始所懷抱的理想,早就拋諸腦後了。

個人一向不主張 “現學現賣”,風險實在太高了。
若真要應用在 “專案開發” 上,那麼,最好是不要好高騖遠,往前走一小步,做一個不太成功的專案

什麼意思呢?
只將一項新的技術或觀念應用在一個小型的專案上。

例如,我常主張,要讓一個專案 “看來很成功”,最重要的一件事,就是要能與客戶達成相互之間的 “平衡(或者稱之為妥協)”。
要如何平衡? 測試先行(Test First)是最佳的利器!

開發團隊撰寫功能測試的測試程式碼;客戶負責提供寫測試的 “劇本(Scenario)”。越簡單越好,可不要搞什麼 “Test Case” 之類的,也就是測試不要以文件、測試列表等這些 “Paper” 來表達,太容易發生糾紛了。
自動化,就是自動化!!所有的功能均能以測試程式碼來執行自動化的測試,若其中之一的功能沒有通過,自然就反應在測試的結果。而功能一改,自然,測試碼也必須跟著更改。功能為什麼更改?也就相對反應客戶需要對其更改的功能 “負責任”,因為,測試劇本是由客戶所提供的。

“測試先行” 簡不簡單? 技術上是蠻簡單的,但,實際執行起來可不簡單,因為,牽涉到開發人員心理層面及與客戶溝通(必須說服其撰寫測試劇本)等諸多問題。

若能成功導入單一一個新的技術與觀念,提升團隊的經驗、技能與信心。那麼,再漸增地加上一些 “新技術”,如 “Use Case” 表達需求、”Class Model” 表達領域物件的結構...等。

人們往往希望做事能面面俱到,但最後卻往往都面面不俱到。
做一個不是太成功的專案,往前一小步;勝過什麼都想做,到最後卻反而一團遭而無法收拾的專案。

不能為自己找藉口

最近與許多軟體開發人員相互交換心得與討論。發現,絕大部分的朋友們並不是很快樂。
問他們原因,因為覺得「軟體產業」這個環境不太成熟,所做的工作很無奈又沒有成就感。

所以,只要會發出 “唉” 叫聲的朋友,我都會建議買最最有幫助的一本書:「吃了那隻青蛙」。吃多了青蛙,就可以治好你的 “唉唉” 聲了。 😉

一位朋友,他想當專業顧問,倒推回來,他也知道該提升管理能力與技術能力。但,要如何做、如何進行,他就說了:
“因為產業的不成熟,專業顧問不容易生存;因為要顧到生活,不敢下定決心踏出第一步;因為…所以…等等等。”

說真的,到哪一個單位,幾乎都有上述提及的情形,要嘛就怨大環境不佳,要嘛就覺得待的單位不理想,要嘛就嫌豬頭老闆 …等等。

我是覺得,幹嘛那麼不快樂?
這些所提及的都是事實,但是,怨東怨西對個人有什麼幫助?
說難聽點,這些理由都是為自己在找藉口。

自己的命運決定在自己手裡!
與我現在所待的環境有何關係?這些都只是一種必經的過程而已。

產業環境的不成熟? 那不是更好? 更有個人所發揮的空間。
公司待的不愉快? So What? 一皮天下無難事,會有比在軍中還更無奈嗎?屆時拍拍屁股走人,又是一條好漢。

唉聲嘆氣、為自己找太多的理由與藉口,這才是最可怕的,因為會怠惰心智、會妥協於現實。慢慢地,意志消沈後,就像籠中鳥關久了以後,再也不敢展翅高飛了。

No Execuse!! 不要再為自己找藉口了,那只會傷害到自己。
快樂一點,想到軟體業界處於混沌的亂世,我就更開心,因為,更有機會嶄露頭角了;想到軟體設計是那麼好玩,就如同看漫畫那樣地愉快,然後,又能靠這賺錢。哇哈哈,真是開心~

至於現實的經濟生活? 當然要兼顧囉~
從 “你想要什麼” 倒推回來思考及規劃,大概可以找到 8萬四千種方法來賺 “安家費” 。所以,看來,我覺得也不是大問題。

做有趣的事、又能幫助到別人、還能賺錢。我是一直朝這個 “三贏” 的方向在走的。
至於現實工作的不愉快或經濟生活尚未達到足夠的水平,那都只是一種過程。不要以為這是磨練或吃苦,我反而覺得這些過程是一種享受、是一種樂趣。
堅信自己會到達所設定的目標,往那個方向走,多跌到幾次。生活就是充滿了這麼多的刺激與樂趣。

軟體思維顧問

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

Personal