2009年12月31日星期四

[X] 網誌的最近變更

導引投影片下載頁面 [ 請按此 ]

功能真的是隨便用直覺式作法都可以完成
但是為了系統的彈性與品質,就需要額外投入時間來作設計
"做得快"與"做得好",這兩個條件通常是互斥的
我相信--
唯有適當的佈置與對應的工具,才有機會讓系統開發又快又好

[投影片進度]
已經製作單元 - 12 (完)
文章關聯建立 - N/A


[最近修改]
2009/01/07 - 測試用Workspace下載處 [ 請按此 ]
2009/04/06 - 清除所有文章的標籤只用預設分類,留作未來作快速瀏覽用。
2009/06/01 - 有人說內容又多又雜,看不出重點;開始著手準備簡介投影片。
2009/06/10 - 新增導引投影片的專用頁面。
2009/07/14 - 導引投影片的內容製作完成。
2009/07/18 - IBM網站這篇MDD的文章 [ 原始網頁 ] 表達了程式碼與模型的相輔相成;RUP課程的講師的教授內容也很棒。
2009/10/24 - 推薦一篇文章:[ 別把專家當笨蛋 ] (吳俊瑩)

2009年12月11日星期五

X09 精確地拆解、完全地對應(1)

公司前陣子陸續驗收了幾個專案,主管利用可喘息的空檔重新思考如何確保程式碼的品質。品質,無法直接以數據衡量其好壞,因而參考Java Power Tools這本書中的工具與作法,同時決定沿用同事已經先行研究一陣子的產出再擴展下去。

同事的作法是使用虛擬機器安裝Ubuntu作業系統後加上需要的應用程式,雖然他同樣參考過那本書,但僅是在虛擬機器上裝好書上提到的軟體。我們拿到虛擬機器映像檔時真的是有點愣住,因為根本不知道軟體安裝的順序、方法與設定(他的說法是使用者只要有能用的東西就好,不用管怎麼安裝的),也不知道Programmer日常工作要在什麼時機、用什麼樣的方式來運用各個軟體(他有說了大概,但是沒有確實的工作流程)。

那時我還在別的專案忙著,主管先找了其他同事來幫忙弄清楚虛擬機器上的每個環節,同時希望他們能定義每個工具使用時的規範(例如Subversion在commit時說明的範本),當時也言明在完成後會由我根據產出的文件從頭到尾重做一次來檢驗結果。但是這幾天自己下去重頭做時才發現記錄的內容感覺很不齊全,很多地方不知道從哪裡開始、不確定要做些什麼、不知道做了之後改變了什麼。

工程師(指我遇到過的以及我自己)撰寫使用手冊與教學文件的產出普遍不理想,主要原因是對於撰寫這些文件的態度為“把自己完全清楚的東西全部寫一遍,只是浪費做其他事情的時間而已”,於是就以自己的角度思考寫出能回憶到的部分。在很多時候就因撰寫者與使用者的程度與觀念落差造成無效的文件。

2009年11月19日星期四

Y09 關於共用核心元件(Core Component Library)

在因緣際會之下參加了經濟部標準檢驗局舉辦的Core Component Library(簡稱UN/CCL)座談會,才知道聯合國UNCEFACT已經提供一套方法,針對企業間電子商務行為關係將彼此的交易流程以共同同意之方式、順序及訊息格式進行整合。其範圍涵蓋了各行各業非常多的商業資訊物件,在最近的09A版本已經定義了五千多種。

UN/CCL主要的目的在於各國、各系統間的資料交換,翻閱過08A的中譯資料發現已經定義了許多曾經使用過的資料。席間有人發問說資訊物件內的欄位並沒有定義長度,學者回答資料若定義長度在語系轉換時會發生長度計算的問題,不過我認為資料在使用的意義上並沒有長度的規範,而是系統設計時因應儲存限制才加以規定的。

然而UN/CCL只是該組織計畫一部分,資料的定義用ebXML來描述,Business Process與Information Model會有UMM方法論,相對地這也是範圍更大、更難定義的部分。根據簡報的陳述,倘使各國的菁英最後能夠定義出絕大部分的商業流程與其對應使用的商業資訊物件,未來的電子商務相關系統開發模式很可能是:

●定義使用系統的所有Actor
●定義每個Actor所使用的Business Use Case(從清單中勾選)
●定義每個Business Use Case裡所需要的Business Process(從清單中勾選)
●定義Business Use Case裡的Business Process執行順序
●定義Business Process對應的CCL資料物件中的使用資料欄位(從清單中勾選)
●底層的架構會根據勾選的資料物件欄位產出ebXML傳送到另一端的系統

這個組織已經運作好幾年,但是以“Core Component Library”搜尋中文網頁時所得的資訊並不多。從另一個方面來看,自己定義的“人-事-物”關係能夠接近許多專家定義的“Actor-Business Process-Core Bomponent Library”精神時,總是對自我更多了幾分認同。

官方公佈UN/CCL版本的網址是 http://www.unece.org/cefact/codesfortrade/unccl/CCL_index.htm

2009年11月10日星期二

X08 批評學生不敬業的事件

原始網頁:http://parenting.cw.com.tw/web/docDetail.do?docId=1844
學生回應:http://udn.com/NEWS/OPINION/X1/5242253.shtml

聯合新聞網上刊登了這個事件,洪蘭小姐在訪視台大醫學院時對學生們上課表現出來的態度不以為然,在天下雜誌發表「不想讀,就讓給別人吧」一文,對此事件,台大醫學系系學會會長在新聞網的專題裡回應了一篇文章說明。我當然不懂學醫的人求學時會發生什麼事,不過我對每個人在不同情境下的思考邏輯很有興趣,所以順便探索一下。

洪蘭小姐的立場很簡單,她認為在求學時期應該對所有學校相關的事(包括與求學無關的)都應抱持負責的態度,更何況那是上課時間;學生的回應也很簡單,表面上承認態度的確有所不當,不過那些都是因為有更正當的理由才會造成那些現象的發生,如果在專業方面能有所表現的話應能體諒其他不拘小節的行為。

在許多人的觀念裡資訊人員是不拘小節的族群,以往的我就是落在這個集合裡,認為只要我能夠完成公司交付的所有任務就算是達成工作目標,平時上班穿著牛仔褲、涼鞋也不以為意。十年前應徵現在的工作被錄取時,詢問上班應該如何穿著,那時的J主管說:“你希望別人怎麼看你就怎麼穿”。從那天起,我每天都穿著長袖襯衫、西裝褲與皮鞋,因為我認同穿著可以反應出一個人的內心。我們在開會因為都帶著電腦,有時總會分心做些與當時會議無關的事,J主管有次生氣地說:“我放下手邊的工作專心地與各位開會,如果大家沒法付出與我相等的專心,我現在就離開“,自此之後我也不曾在會議上別其他事情。

我沒法認同學生的辯詞,因為我體認到在不同的情境下人都應該做該情境下應做的事,每個情境都是獨立存在的,不該拿其他情境的影響來解釋現在的錯誤。上課是學生與老師的互動,老師全心講課時,下面的學生付出了多少?相對地學生想來認真聽課時,敷衍的老師同樣對不起學生。上課會打瞌睡只是證明睡眠真的不夠,如果睡得夠的話看到看過的電影會拿起別的書來看;上課會吃便當只是證明不想犧牲吃的享受,如果時間真的不夠會寧願買個飯糰在休息時間隨便吃吃也不會想在課堂上分心。

在上課的態度不佳是事實,沒去承諾去努力改善這個現象,卻試圖用所有學生的“全”讓那些學生成為“偏”、用專業課程為重的“全”讓通識課程成為不重要的“偏”。一個小故事裡的壽司師傅在捏了上千個壽司後已經累了,仍同樣專心地製作壽司給關門前最後一位不重要的客人吃,旁邊的師傅說你已經很累了不如隨便應付一下,他正色道:“這個壽司只是我今天所做的千分之一,但對這位客人來說卻是他的全部。如果隨便做做,客人就會認為我做的壽司就是這麼爛!”

在想要合理解釋自己有問題的行為前,是否思考過洪蘭小姐所訪視的那一堂課就是她所看到的全部呢?

2009年11月3日星期二

S15 簡單的幽默(6)──切換為不同的視角

除了針對事物本身的特性作文章之外,還可以經由切換不同的角度來突顯既定事實被變調後的幽默。

有位業務在Facebook的塗鴉牆上留言:近年來收入越來越少,算命又說沒有偏財運,該怎麼辦才好?我建議說:如果沒有偏財運的話,不如將現在的工作當作兼差而把買彩券作為正職,應該就能改善。另一位單身同事也留言:最近手頭很緊卻有好朋友結婚,應該如何處理?我回答道:趕快在好朋友結婚前百日之內先結婚,這樣不僅可以省掉紅包錢還可以存下一小筆積蓄。

原先的事實都指定在一個限定的範圍裡,我們可以試著在它的上面或是平等的地方(通常是上面)找出能夠將之硬拗為截然不同意義的視角;前提當然是原來的事實不變而且完全合乎後來從另一視角所設計的劇本裡。第一個例子裡錢賺得少就用命運裡的財運來涵括,使之成為財運的子集合;第二個例子就設計讓主角先結婚,就可以順理成章地以習俗避開沒錢還要包紅包的事件。

工作忙時有些同事會感到頭痛,聊天時會談要怎麼樣可以有效地讓頭不會痛?總有人開玩笑地說:那就讓我用力跺你的腳吧,只要你的腳比頭還痛自然就會因注意腳痛而忘卻頭痛。男生積極邀約女生下班後搭他的便車回家,女生婉拒時可以試著說:搭我的便車回到巷口下車時,如果有鄰居看就會感覺妳時常被不同的男生送回家會很有成就感喔。

在開玩笑的同時還要留意一個原則:“好的說法要用在對方身上,壞的譬喻得拿自己打比方”。儘量找好的說法來作範例當然可以避免無謂的不好觀感,倘使笑點一定要用不雅的方式才能呈現的話,就儘量用“如果是我的話……”作為開頭來陳述。適當地犧牲自己才會更有機會帶給別人歡樂,這是我所得到的經驗。

2009年10月30日星期五

Z03 振聾發聵的文章──別把專家當笨蛋(3)

小朋友有天說出他被學校的同學在部落格上攻擊,我們發現對方的文章裡盡是刻薄的字眼。把小朋友叫來詳細詢問事情經過,他起初描述是因為小事有誤會造成的,但是根據小朋友的習性抽絲剝繭後才發現他的行為也不恰當。與老師溝通時,我們傾向於說小朋友目前還是學習階段都難免有錯,請老師教導他們對錯觀念再修正即可;不過老師透露當初看到那些文章時,倒很擔心雙方的家長會在學校鬧出風波。

有些人完全不想學UML,但是在認定UML無用的同時卻無法做出大多數人看得懂的文件;很明顯地這是因為心裡沒將製作文件視為自己該做的事,因而不想要任何對應的處理工具。各類的文件在系統開發階段中一直要求得具備,倘使心裡認定撰寫文件是浪費自己的時間,自然不會在意文件對於其他人與日後自己的影響。要讓一個人願意學UML必須要先讓他認定撰寫文件是必須做的,要能接受撰寫文件是必要的得瞭解文件在各個開發階段的應用,要是心裡打一開始就認定開發方法論無效,就跟之前的我一樣什麼都不用再談了。

“主觀”是個殺傷力很強的念頭,可以將小朋友間的爭執鬧到上法院,可以讓自己變成別人眼中的老頑固,也可以將旁人的心血說得一文不值。同樣是一個人,為什麼從小到大的立場會如此轉變?為什麼會從天真瀾漫變為結黨營私?為什麼在互動頻繁的人類社會裡能夠變得自我中心?不是心理專長的我當然沒有答案,不過我至少發現了一把可以改變自己想法的鑰匙。

人們總是習慣從自己的角度看待事物,唯有學習從不同人的角度重新審視原先熟稔的事物,才有機會突破自己預先設下的侷限,重新顯現出不同的格局。將自己放低後,其他人的經驗與知識自然開始源源不絕地流入,收集眾多的資源後就比較容易分析比較各項優劣。我已經相信這個道理並且開始實行,至於你相不相信?都是你個人的選擇。

2009年10月29日星期四

Z02 振聾發聵的文章──別把專家當笨蛋(2)

小時候遇到各種新的或不同的事物,總會很有興趣地去學、去瞭解,甚至還會提出一些新奇的想法來嘗試;沒想到這樣的熱忱於長大後卻大多演變為“我不需要”或“看起來沒用”的回應。小朋友前幾天對我說:“為什麼要學勾股定理?根本用不到嘛!”當時我心頭一震,彷彿看到在學校與工作時抵抗著其他知識的自己。我回答說:“學一些知識是讓自己擁有這個能力,未來要從事更高深的科學研究時就有機會用到;當然也有可能用不到,但是需要的時候沒有就是你自己的痛苦。”

同樣地,專家提供根據他們領域知識的精華,根據專家整理過的資訊能夠快速地提升自己的水平;要從一份整理資料裡去蕪存菁地擷取有用的經驗,還是要因為一些蕪而廢棄菁地整個丟棄都是自己的選擇。以往對一件事物習慣去看旁人對它的評論就吸收為自己的看法,藉此來決定是要接受還是抵抗,如今學會反問自己:“我完全瞭解它的意義嗎?能明確說出它的全部優缺點嗎?”,想要有明確而完整的答案,就非得親自去體會不可。

之前與年紀較大的同仁打交道時,總感覺他們的想法非常固執、極難溝通,現在的自己慢慢地朝高齡化發展,卻漸漸發現排斥其他想法與知識的行為與他們類似。似乎具有一種心態,認為某些事自己已經擁有很多的經驗值,如果別人隨隨便便提出幾句話就改變自己,會是很沒有面子的事,所以面對可能的改變時不是消極地掩耳盜鈴當作不知道,就是想出許多藉口來說服自己新的想法並沒有現在心裡面的好。

回憶自己的過去,故步自封的確是因為自己太有自信去控制一切,也就是過於輕視眼前的領域,不想接受其他不同的思維所造成。學歷可以無用,像在大學時我根本蹺課到等於沒去上課,現在的工作目標照樣可以用自己的方式達成;但是要能有良好的做事方法與產出內容,如今相信真的需要先參考專家們的經驗,再調校為適合自己實行的模式才會有機會更上一層樓。

2009年10月28日星期三

Z01 振聾發聵的文章──別把專家當笨蛋(1)

原始網頁:http://www.ithome.com.tw/itadm/article.php?c=57685

是否曾經有過這樣的經驗?有一個東西在身邊已經存在很久卻一直沒有什麼感覺,等到某天的一個場合再看到它或是某件與它相關的東西,心裡頭各式各樣的想法就不自禁地流動起來,翻騰到最後定型下來卻是另外一個層次的感動。我提到的那個東西並不是女友或妻子(雖然很像是),而是E主管堆在我桌上的一疊書,這篇文章就是引發我不同觀念的催化劑。

Sun的OO-226課程是我接觸OOAD的最初,開始時隱隱覺得這是很不錯的設計作法,但是實際應用在開發時卻有很多無法串連起來的缺漏;累積幾年的經驗後試著以其為藍本,再自行定義一些捷徑作法將所有的點連成線再到面而形成現在的想法。雖然有自信可以合理地做出一些不同的東西來,但是那畢竟只是“用自己的經驗湊出符合既定目標”的產物。

RUP一直是有名的開發方法論,不過很多人的評價都說它過於笨重並不適合實用。在與E主管討論方法論(他傾向用RUP)時我常搬出這類的評價來抵抗,他總會說:“你瞭解RUP的全部作法與其精神嗎?你說得出哪裡有問題?哪些作法適用?哪些作法不適用嗎?”當時我認為這僅是強辯時的說詞而堅持己見,每次的討論也常不了了之。然而我現在已經在閱讀RUP的全部正式文件,因為現在終於明白應該從一個穩固的基礎為起點再用自己的經驗來調校它,並不是自己創建一個全新的作法。

完整的開發方法論是一大群人耗費心血所完成的,定義出所有階段、所有角色、所有行為與所有的產出,相信那都是每個人的多年經驗與思索研究的精華,是一個人在一、二十年的經驗所無法相比的。專家的產出是將其自身經驗輸出為系統化、組織化的作法,進而建構起環環相扣的關聯,在某些細節上或許的作法或許不盡理想,卻也不應因噎廢食而全盤否定。

2009年10月26日星期一

X07 規畫書撰寫實務課程的收獲

公司打算開一門規畫書撰寫實務的課程,對象主要是業務與市場規劃的同仁。原本不在上課名單內,但是想起上回撰寫規畫書的慘痛教訓後著實希望自己具有這方面的基本能力,因此商請主管在上課的當天硬是向人事部門報名。

課程為十二小時,在授課的中途看著講師整理的投影片對應到之前的問題點時,才發現計畫書的編排除了把內容寫出來之外,是有目標、有架構、有不同角度與不同寫法的,同樣的內容必須根據不同的因素組合來調校。看得出講師在投影片的整理上花費了相當大的心血。休息時間與其他同事閒聊時,他們說雖然教材內容經過整理,但是提出的一些目標與原則感覺根本做不到,譬如說計畫書的內容要寫到能感動人心就太過理想。

認真觀察投影片的結構,慢慢領悟到:對一個難以直接達成的目標,可以拆解為數個可以分開完成的項目,每個項目有自己的作法、輸入與產出。概念就像是下面的圖所表示:


自行推想的思考原則如下:
●每個目標拆解出來的項目必須互斥。(項目拆解子項目時亦同)
●每個目標拆解出來的項目組合起來必須剛好等於目標。(項目拆解子項目時亦同)
●每個作法的輸出必須剛好符合項目的要求。
●每個作法內要有規定的執行步驟
●每個作法使用規定的輸入後,能夠產生規定的產出。

用簡單的一句話表示,會是“精確地拆解,完全地對應”,將目標分割為可以獨立完成的項目,每個項目全部完成後代表目標達成,輔以輸出項目的檢驗標準用以度量目標與項目的進度與品質。觀察自己身邊的許多事若能用這樣的原則處理,相信就會習慣用文件來記錄想法的拆解內容。

註:講師在投影片中根據經驗定義了評審審查的數個重點,根據每個重點建議一些適合的作法。如果定義的審查重點在邏輯上等同於那個目標,那麼針對各個重點的加強就能提升其效果,更有機會達到“打到人心”的目標。