jim yeh on 一月 31st, 2007

在〈物件 (Object) 的媽媽是 類別 (Class)?〉一文中,Kenming 兄提到「物件是有機的生命體,但類別卻不是,事實上,世界上根本就沒有『類別』這種有機體;而若是類別不是有機的生命體,那麼,物件就絕對不可能是由其誕生的!」。然而,對於 Kenming 兄的這個觀點似乎很難有定論,誠如 William 君所回應的「 說實在的,這不管是在生命科學層次、哲學層次還是在電腦實踐層次,都未必有標準答案。」。為什麼 Kenming 兄會認為類別不是有機體呢?我想這一段話可以看出個端倪: 我相信在實做面的技術,為了穩定與效能等考量,會把 Class 當成 Object 來用,那麼,Class 在該應用平台是否也是 "Instance" ? Kenming 兄大概是認為類別並不具有任何的實體,沒有生命期,至少在象徵軟性議題的問題領域結構設計與需求方面的範疇是如此,所以類別在軟體設計上並不屬於有機體。 不過,我倒認為這樣的論點雖然可以簡化設計思維,但對於進階設計者而言,卻會發現設計中,用這樣的觀點來看事情,對設計卻會造成一些困擾,因為真實世界的問題常常不如我們想像地那麼簡單,當我們發現問題領域需要同中求異或異中求同的過程中,就會出現類別這個有機體。

Continue reading about 類別到底是不是有機體?

     
jim yeh on 一月 30th, 2007

這個月我們家增加了一個家庭新成員了,女兒於 2007/1/12 晚上出生,2800g 的可愛寶寶。 女兒的降臨是讓人期待已久的,然而生產的過程卻是令人緊張的。寶寶過了預產期兩天還沒有產兆出現,到醫院看胎兒監視器後卻發現寶寶的心跳並不是很穩定,而原來的婦產科醫生卻臨時有事,結果臨時換醫生。醫生研判有胎兒窘迫的現象,只好剖腹生產,所幸手術過程順利,母女平安。 不過不管過程如何,寶寶順利生下來總是令人快樂的,雖然新手爸媽,生活步調變得不一樣了,常會被小傢伙弄得手忙腳亂,雖然辛苦,但看到可愛的女兒,那些疲累也就會自然而然消失了,真是奇妙。

Continue reading about 喜添嬌女

     
jim yeh on 一月 26th, 2007

在回應了鳥毅對軟體專案管理的看法後,鳥毅在他的網誌中提出一些後續觀點。然而我發現有些觀念還是不夠清晰,可能是因為我前文沒有說清楚,因此,另闢新主題來表達我的看法。 首先,鳥毅提到: 因為手上的PMBOK資料是舊版,後來在下去找PMBOK第三版,果然看到同人所提到PMBOK對軟體工程管理的部份 我並不了解鳥毅提到的第三版的軟體工程管理的部分是什麼,其實專案管理流程的基本精神在於PDCA,不論新版或舊版都是依循這種精神,只是新版更強調監控要貫穿整個專案階段,軟體工程管理的部分應該還是屬於軟體產業的應用領域,軟體專案管理者必須去了解專案管理如何與軟體工程相互整合,任何應用領域的專案都會和應用領域的工程面做整合,軟體只是其中一種應用領域而已,PMBOK 所規範的是專案管理的通用原理及原則,工程上的實務還是要靠各種不同工程領域的專家相互整合,這點與 CMMI 只規範 what to do,而不會告訴你 how to do 的道理是一樣的。

Continue reading about 有關「軟體專案管理」的後續討論

     
jim yeh on 一月 25th, 2007

在〈軟體設計需面對現實〉一文中,我曾針對 Gameboy 提出「用 real world 的直觀來認知 model ,這有點危險」提出個人的看法。對此 Gameboy 為其觀點 defend,然而在討論過程中卻因為對文字感受不同而造成一些爭論。因此,我認為有必要再進一步地探討「用 real world 的直觀來認知 model 」這個主題,以避免不必要的誤會。 基本上我和 Gameboy 對「real world」的定義不同,Gameboy 提到: 因為我看到太多 beginner 的抽象化是 僅僅源自於他們的直觀認知 而非從 Requirement 下手 但 Real World 中直觀的名詞 不見得適合作為 Domain Model 中的 Entity 但卻往往被他們誤植於 Domain Model 中 由上可知 Gameboy 所言之 real world 其實指的是系統開發人員對系統的初步直覺認知,但在未經需求分析之前,容易落入以技術來主導需求,而使領域模型變成與現實問題領域脫節。Gameboy 的看法並沒有錯,但 Gameboy 說的「real world」與我所認知的「real world」並不一樣,我擔心如果沒有界定清楚,言者無心,聽者有意,很讓初學者落入「言語的流沙河」的陷阱-對軟體設計錯誤認知的來源。 我所認知的「real world」是指對領域專家對問題領域的真實認知,也就是洞察問題領域的認知。領域專家多半不懂我們 modeling [...]

Continue reading about 探討「用 real world 的直觀來認知 model」

     
jim yeh on 一月 10th, 2007

鳥毅在他的網誌中提到他對軟體專案管理的看法: 據在下所知,台灣最早採用專案管理的是營建工程界,由於土木建築設計好後變動性較小,因此使用 WBS 比起軟體容易;軟體有許多不確定性,使用Agile開發後更模糊了設計與開發的界限,因此在下並不覺得 PMBOK 套用到軟體專案也適用。 專案管理不適用於軟體專案?要回答這個問題要先知道什麼是專案管理。依據 PMBOK 對專案管理的定義為「在專案活動中,為了達成專案目標所作的相關知識、技巧、工具及技術的應用。專案管理會完整經歷如專案初始、規劃、執行、控制與監控及結案等五大管理流程的應用及整合」。 專案的管理工作內容有: 識別出需求。 建立清楚與可達成的目標。 平衡品質、規模、時間及成本等專案限制,這些限制是會相互影響的。 為每一個不同考量及期待的利害關係人,調適規格、計劃及方法。 理論上,專案管理與您所開發的產品與服務的內容所採用的方法論沒有關係,所以,對於任何的領域而言,只要專案有明確可行的目標、專案開發的過程中需要規劃、執行與監控及結案等活動,並不會有不適用的問題,即使不同的應用領域會有不同的工程活動(軟體開發流程、軟體工程管理)及一般管理活動,但專案管理流程與這些管理及開發活動是可以相互整合的,所以照理說軟體專案不會有專案管理的不適用問題。

Continue reading about 專案管理不適用軟體專案?

     
jim yeh on 一月 9th, 2007

最近看到有人領域模型中的客戶類別如此設計: 這個設計觀點是將個人戶與公司戶都看成客戶,因且可以把公司戶與個人戶的都有的共通屬性放到客戶類別上,然後把個別所特有的差異化屬性放到衍生類別個人與公司上。表面上,這似乎是Party〔Fowler96〕樣式的應用,然而仔細推究其設計內容,卻會發現這個設計會使系統增加沒有必要的複雜度(Unnecessary Complex)。 因為個人戶與公司戶其實有很大的差異性,衍生類別的屬性很多,也有複雜的處理邏輯,就算我們採用的永續機制框架-Hibernate可以處理類別的繼承,但繼承卻讓我們的類別之間相互牽連,卻只是為了讓公司與個人的屬性不要重覆出現而要花費如此的成本似乎太奢侈了。 其實這個設計最大的問題是只從結構面的角度來設計類別,只考慮抽取共通屬性,卻缺少了行為面的封裝,這是營養不良的領域模型,設計的本質還是採用程序導向的基本思維,造成問題的主因是設計者並未針對實際發生的問題層面來設計,而是以預期的技術層面來考量,也就是說,樣式的錯誤引用把設計問題變複雜了。

Continue reading about 軟體設計須面對現實

     
jim yeh on 一月 5th, 2007

在《容忍異端的文化》一文中,與網友莫齋討論到組織內部目標一致性的問題,莫齋舉了一個具體實例,然而她所提的例子和之前討論的情況有點不同,但也很值得探討,於是另闢主題表達我的觀點。

Continue reading about 服務的供需法則