物件導向繼承與程式碼的再用

在〈石頭閒語:類別繼承、介面宣告與模組混成(mix-in)〉,石頭成提到他的學習經驗:

當年在學 Java 時,我便感覺到介面宣告規避了鑽石繼承問題,卻無助於提高程式碼再用性。 Java 的介面宣告,只是規避而非解決鑽石繼承問題。……在動態語言中,雖然多數都採用單一繼承機制,卻又毫不死板,憑藉著動態性提供繼承機制以外的程式碼再用方式。 Ruby 的混成(mix-in)機制就是一個聰明的例子。這個概念也開始被程序員應用於其他語言之中,例如我嘗試於 JavaScript 和 PHP 中實踐混成概念 (PHP 實踐 mix-in 概念之可行性)。

我對所謂的 mix-in 並不熟悉,於是循線看了〈PHP 實踐 mix-in 概念之可行性〉,我發現石頭成所用的實作方式,類似 GOF Design pattern 的 State pattern,利用多型介面與自委託(self-delegate)技巧,可以讓物件同時具有多種型別的行為能力,甚至還可以動態改變物件的型別。

如此看來,石頭成對 Java 介面的負面觀感其實是出自於對 Java 介面使用的誤解。提高程式碼的再用以 Java 技術而言,不是只能靠繼承而已,繼承的誤用只會造成程式碼的僵化與脆弱而已,而實作介面來面對多重繼承的問題,那並沒有比誤用繼承高明到那裡!Java 或其它採用靜態型別的物件導向程式語言,解決一個實體有多種型別的問題,不是靠繼承樹或重覆實作介面,而是利用組合(Composite)角色子型別(Role subtype),即所謂的角色塑模(Dealing with roles),介面的使用是用來除耦-讓設計與實作分開而不是用來當成類別多重繼承的替代方案。
閱讀全文 →

分類: 設計原則, 軟體開發 | 5 則留言

善用工具為軟體品質加分

在軟體開發過程中,工具雖然不足以取代人力,但有效地使用適用的開發工具,卻可以讓我們軟體開發得到加分的效果。

不過,在企求開發工具為我們加分之前,我們必須要思考如何才能先拿到基本分數。 閱讀全文 →

分類: 專案管理, 易經思維, 軟體審查, 軟體開發, 開發工具 | 1 則留言

黃道吉日與良辰吉時

最近 William 君公布了他即將在四月份告別單身生活的喜訊。這真是一個好消息,一直以來,看他的文章令人受益良多,在此恭喜他,希望 William 夫婦賢伉儷琴瑟和鳴。

William 君結婚的日子,可是相當漂亮的黃道吉日耶。 閱讀全文 →

分類: 占星, 易經思維 | 1 則留言

評論「專案假設」的相關討論

哈米尼斯對我在〈對專案假設的看法〉回應說:

我文中所提的這一個假設「專案執行的過程中,兩方所簽屬的任何文件,皆屬有效文件」,這樣的說法並不是說客戶不能改變Scope(事實上我做過的案子很少有驗收時的規格會和合約完全一樣的),而是為改變提供一個正式的法源,至少不要在驗收時落人口實說變更Scope的程序是有問題而被卡來卡去。

其實我並不反對用合約或其它經雙方簽署相關文件來提供變更的正式法源,但合約或其它經雙方簽署的相關文件並不能算是專案假設,它們是一種會對專案成果發生影響的約束。所以用專案管理的專業術語來說,應該稱它們為專案限制而非專案假設。雖然合約條款或經雙方簽署的文件內容,這些限制其背後都會有相對的假設,但真正要有效地解決專案問題,應該是去識別問題背後的假設,並進一步地去管理它們;而非一味地運用根據假設所發展出來的限制來約束專案成果。因為後者的做法會讓人看不見問題背後的問題,以致於對失去問題焦點。

哈米尼斯隨後在他的網誌發表了〈專案管理:再論「專案假設」〉來闡述他對專案假設的看法,他認為:

如果把做專案當做是我們寫證明題,而證明的過程就好像是專案執行和驗證,在被驗證之前,其實我們甚至都可以說這一個題目(專案)都不是真的。當用這樣的角度在看時,把專案假設當做是一種專案的限制,我是認為並無不可。

但我認為,可不可以「用做專案來比擬解證明題」,其實是取決於專案所要處理的問題而定。如果專案的決策是屬於結構化(structured decision)的,亦即對問題有良好的定義、變動性很小、不確定性很低、過去有處理過類似問題的經驗及問題困難度不高,那麼做專案就相當於解證明題一樣:一切可以照著預先所規畫的來做,專案的假設就像證明題的已知不會改變,當然可以把做專案來比擬解證明題一樣;但往往軟體專案的決策多半都屬於半結構化(semi-structured decision)甚至是非結構化(unstructured decision)的,它們沒辦法像解證明題一樣那麼簡單,在過程中我們會發現原先建立的專案假設會隨著專案的變動而變得不再成立,將會對專案的成果造成某些影響。因此,在整個專案生命週期中,我們必須要注意假設所衍生出來的不確定因素,以防止或減輕它們對專案所造成的衝擊,否則對於專案要解決的問題就很有可能會發生此題無解的窘境。

閱讀全文 →

分類: 專案風險, 軟體開發 | 3 則留言

Software review 與軟體品質文化

關於 software review,在看了喲哪桑學長對我的文章所寫的回應後,發現學長對我想要表達的意思有些誤解。學長提到:

我個人不是很同意依照形式的多寡來分類review, technical review, peer review, etc. 雖然我對那種分類法的感覺不好, 我也建議少這樣說, 但的確有些人是這樣用的.

而我的原文是這麼說的:

對於一個開發流程未慣例化的組織而言(即未達 CMMI ML2),推行 review 可能會遭受極大的反彈;而對於一個開發流程未針對現況做回饋控制的組織而言(即未達 CMMI ML3),review 的推行可能比較徧向形式審查而較少的技術審查或 peer review。

其實我要討論的重點並不在於 software review 形式的多寡,事實上,我文中提到的形式和學長所說的形式並不是同一件事。徧向形式審查的意思是審查的要點在於看工作產出有沒有遵照開發組織規章或專案計劃所規定的文件規範及慣例,對於工作的內容卻無法做到實質上的審查;而所謂的技術審查或 peer review 則是除了工作產出的形式是否符合規定外,審查的重點更會擺在工作產出的實質內容,我常稱這種審查叫做實質審查,用來和形式審查區隔開來。
閱讀全文 →

分類: 品質文化, 專案管理, 軟體審查, 軟體開發 | 3 則留言

評論喲哪桑對〈創造 software review 的需求〉的回應

喲哪桑學長在〈Review vs. Inspection — 亂談軟體工程的正名運動〉中對〈創造 software review 的需求〉有所回應,他提道:

沒有壞就不要修,本是西洋古老的諺語。只不過,我還是會擔心,等到壞了,修也來不及囉!

我可以理解學長的 concern,但以 problem-solving 的角度來看問題,第一步一定要先弄清楚問題是什麼。再來問這是誰的問題,在問題擁有者並不想解決問題時,貿然要對方改變只會招致埋怨而對問題沒有任何的助益。
閱讀全文 →

分類: 問題解決, 專案管理, 易經思維, 生活感觸, 軟體審查 | 發佈留言

衝突與 software inspection

哈米尼思對〈工具在 software inspection 所扮演的角色〉提出看法,他提道:

曾經在書上看過這樣的例子 software inspection 演變成 另外一種型式的專案批鬥大會

由於專案的壓力使然,會使得PM也許會對某些工程師的工作產出提出意見,進而產生批鬥

當然,我並不是反對 software inspection ,而是在做這件事的同時,需要明確的規劃和目標設定

如同文中提到的「反思」,是正向看待問題並思考,進而產生好的循環

回過頭來,還是在於公司或組織是不是有建立適當的文化和訓練,並且這項投資要能夠被管理階層所認同,講來講去~ 還是管理上的問題啊

批鬥大會其實是專案衝突的一種形式,當專案團隊成員有感受到彼此意見分歧、對方干擾的行為及產生負面情緒時,就會展開團隊的衝突過程 H. Barki and J. Hartwick(2004), Conceptualizing the construct of interpersonal conflict. The International Journal of Conflict Management,Vol. 15, No.3, pp. 216-244。雖然衝突太多會對團隊的決策共識及接受度有負面的影響,但如果團隊完全沒有衝突,大家想法相同,團隊內呈現一言堂的現象,會導致決策品質的低落。適度的衝突,可混合不同的意見或建設性的批評,藉由不同觀點的了解,和有創造力的選擇自由,而增加決策品質 蘇麗玉(2005),系統開發人員與使用者在資訊系統發展過程中之衝突與系統績效之探討-以銀行業為例,銘傳大學資訊管理學系碩士論文。。

所以說,批鬥大會不見得是壞事,當問題發生,早期發現早期治療才是最根本的問題解決之道,避免批鬥並沒有解決問題,卻代表了我們只是讓問題延後發生的駝鳥心態。在解決問題的過程中,就算是相互對立,但只要清楚對立的目的是為了解決問題而非相互攻訐,在態度上可以相互尊重,在言詞上避免用言語攻擊或迴避問題面對重要且困難的溝通與解決令人失望的問題可參考《關鍵對話》與《關鍵對立》兩本書,這樣的溝通與對立的目的是要剌激團體正向思考,以促進問題有效解決的良性循環。

閱讀全文 →

分類: 專案團隊, 知識管理, 組織, 衝突, 軟體審查 | 2 則留言

工具在 software inspection 所扮演的角色

在Chui-Wen Chiu’s Note: 〈程式碼檢驗〉看到:

基本上我蠻認同程式碼檢驗這個步驟,不過這個步驟不應該是由人來作,更不應該全部交由一個人來作,而是交由一套工具來處理,如此可以省去不必要的人力支出,而且也可以將 Knowledge 分享給 Team 的每一個人。

站在節省人力支出的立場,用工具幫我們檢驗程式碼的想法看起來好像不錯,如果這樣做可以維持程式碼品質而降低人力的花費,當然是最好的選擇,但程式開發的價值首重創意性思考,但工具卻只能預先設好檢驗的規則,在已設定的規則範圍之外,還是有很多 defect 是會被工具忽略掉,但這些 defect 是不應該被忽略的,因為等到讓它們擴散就麻煩大了。因此把程式碼檢驗的工作,交由一套工具來處理,對於改善軟體品質而言,其實是不夠的。

亦即在檢驗程式碼的工作,工具並不能取代人力的,工具最多只能站在輔助的地位,因為審查程式碼並不是 routine job,這個工作需要的是程式實作的專業知識與技巧,要用人的肉眼直接來逐行檢驗,不能由工具代勞。

閱讀全文 →

分類: 品質文化, 專案團隊, 專案監控, 知識管理, 軟體審查, 開發工具 | 6 則留言

讀書心得分享-是你選擇了憂鬱

更多有關 是你選擇了憂鬱 的事情觀察現今的社會現象,自殺與憂慮症讓許多人憂心仲仲,尤其憂鬱症是二十一世紀的文明病。曾經看了一本好書-《是你選擇了憂鬱》,剛好可為憂鬱及不快樂的現代人提供一帖良藥,在此與大家分享。

接觸這本書的機緣,是由從事學校輔導工作多年,內人的介紹。她在工作上經常運用現實治療理論來助人,有時會與我分享現實治療的觀念。現實治療是在選擇理論架構下的實際應用工具,於是她推蔫我看這本書。其實現實治療不僅是專業的諮商理論與技巧,同時也適合一般人使用。

面對關係的緊張與衝突,我們總是認為「如果對方能夠改變就好了」。但是本書告訴我們,問題往往就出在這裡;當我們習慣以我們認為對的事情要對方照著做,這種以操控方式強迫別人做他不願意做的事情對雙方的關係的增進沒有幫助,反而會造成雙方關係的緊張,彼此的距離反而會愈拉愈遠,最後你就會感到無比地憤怒及憂鬱。除非你了解到你所能控制的只有自己,並放棄操控對方的意圖,你們的關係才有可能獲得改善。 閱讀全文 →

分類: 學習, 心理, 溝通, 生活感觸, 閱讀 | 9 則留言

資訊系統設計的盲目

近日在電視看到一則新聞,台大研究所考題有一題是「為高鐵設計一個不會重覆訂位的訂票系統」,許多考生都認為這個考題很簡單,甚至有人認為這是所有考題中最簡單的一題。

我看到電視的訪問,大部分的考生都對他們自己的解決方案很有信心,有考生說他設計了一個演算法可以解決這個問題,然而卻沒有看到有人對問題做深入的探討,大概以為問題非常明確-不能重覆訂位,然而造成重覆訂位的因素是很複雜的,這些才是真正的問題所在,如果不了解問題,如何能設計出符合需求及適用的系統呢?沒有問題卻可以有解答,這正是NPS(No-Problem Syndrome)-沒有問題症候群(Gerald M. Weinberg,1986)的心態在作祟,因此,看到這則新聞,讓我不禁搖頭嘆息。
閱讀全文 →

分類: 問題解決, 專案管理, 軟體開發 | 3 則留言