jim yeh on 十月 12th, 2012

領域物件代表領域概念的真實資料,但對於詮釋資料的抽象概念卻會受到時空環境的影響而變化。當領域物件不能面對現實而調整,那麼系統的設計將變得愈來愈繁複,但改變領域物件需要變動資料庫又往往是工程浩大要承擔巨大的風險,到底有沒有兩全其美的辦法呢?在此同人分享領域物件的概念性表層設計,它提供開發者自行定義領域物件概念性表層界面,並透過動態代理,以領域物件的資料自動產生領域物界概念性表層的實作。

Continue reading about 領域物件的概念性表層設計

     
jim yeh on 八月 1st, 2012

很多人都知道軟體專案最難解決的是人的問題,但對超理智型管理者來說,人的問題不算什麼。實際上,超理智者經常視人而不見,因此根本不認為他們需要解決人的問題。就像某位長官一心想改變架構,卻拒絕承認架構變動會造成風險升高的衝擊,明顯的駝鳥心態;以為把頭埋在沙堆裡,看不到人,就沒有人的問題。

Continue reading about 看不到人,就沒有人的問題?

     
jim yeh on 五月 14th, 2012

所謂的抽象化思維就是從不同觀點的互動中,經由演化而創造出全新的不同觀點;它既不是業務觀點也不是技術觀點,而是彼此交織之後產生有用的解決問題觀點。其實把抽象化當技術的繆誤,不單單只出現執著於業務觀點的情形,執著於技術觀點也會犯了相同的錯誤;以為堅守特定觀點就可以解決問題,然而這樣的繆誤讓我們缺乏解決問題所需要的彈性呀。

Continue reading about 把抽象化當技術的繆誤

     
jim yeh on 十二月 16th, 2009

表面上看起來好像實作泛型可以讓某一段程式碼重複使用,但 Java 在泛型的限制,也增加他重構程式碼的困難度與複雜度。這麼說來,假如石頭成的想法是正確的,用 Java 的泛型來重構程式碼,只會讓程式員沒事自討苦吃。然而,同人在仔細研究他的程式碼之後,發現可以用更簡潔的方式來使用 Java 的泛型。

Continue reading about Java 泛型複雜嗎?

     
jim yeh on 八月 7th, 2009

同人看 Kenming Wang 這篇文章覺得怪怪的,倒不是不贊同他對寫好使用案例好處的觀點,而是覺得強迫新手去做我們認為有價值的東西是很危險的。

Continue reading about 強迫新手這麼做的風險

     

系統分析師該如何思考與學習的方法以展現其專業。然而,許多人對系統分析專業的疑惑出在忽略「結構與非結構的隔閡」,使得系統分析師陷入了過度簡化設計與過度工程化,也就是所謂過度設計的兩難情境。

Continue reading about 結構與非結構的隔閡-從軟體開發專案的四個困難談起

     
jim yeh on 六月 7th, 2009

程式碼的重覆性使程式不容易維護、以及增加系統出錯的機率,同時使得程式的再用性難以提昇。因此降低程式碼的重覆性對程式碼的品質與彈性有很大的助益。然而,在資料存取與與物件型別的無法分離的情況下,卻會使得開發者難以對治程式碼的重覆性;相同處理資料的邏輯,受限於處理資料的不同型態,使得開發者必須依據資料型態不同,而改寫同一段程式碼,使得程式碼很難共用。 就像一個比較常見的例子是資料永續存取的實作,常會因為存取資料型態的不同,而影響到資料存取的界面,因此對每一個需要持久化的商業領域物件,都必須重覆地實作它們的 CRUD 存取功能。 雖然透過永續層的概念,我們可以將這種重覆性隔離開來,加上有些 ORM 永續框架的協助,開發資料存取物件的負擔並不太大。然而即使如此,我們有沒有可能避免重覆開發資料存取的元件,不用針對每一種物件型別都要寫一支相對的資料存取物件呢?要達到這樣的目的,我們必須分離資料存取的處理程序與物件型別,但要如何才能做到呢?

Continue reading about 降低資料存取的重覆性

     
jim yeh on 二月 3rd, 2009

在〈開發者的 common sense〉的留言中,同人看到一些網友的批評。我發現這些批評顯示了有些開發者不擅於抽象化思考,而習慣於用經驗法則來取代思考。然而,誠如 Brooks 所言:「軟體的本質是複雜的,而不是偶然發生的」對治複雜度本來就是開發者的天職,而軟體開發的抽象化思考則是其用以統理複雜度的利器。由此看來,那些網友的批評著實令人為他們捏一把冷汗呀。 從路邊的垃圾桶與路人的留言,我們可以發現他們弄錯 common sense 的意思。他們認為 common sense 不能一概而論,因為每個人的 common sense 都不同。但這樣的觀點令人感到疑惑,如果每個人的 common sense 都不一樣,所以無法一概而論,那這種 common sense 還能叫做 common sense 嗎? 到底他們觀點上邏輯的矛盾,問題是出在那裡呢?同人認為問題並不是開發者的 common sense 不存在,而是忽略了開發者應該將經驗化成一般性的通用概念。舉例來說,軟體工程領域本身就是從實務發展出來的理論,其中許多概念就是開發者必須知道的 common sense,對開發者來說是合理的知識,也是他們都知道、無須解釋或加以論證的常識。 由此可知,如果開發者缺乏一般性的通用概念,那他碰到問題就很難舉一反三,自然也就難以掌握重點,而只能依據表相來處理問題,往往使得問題變得更複雜。oofunp 的留言就很像欠缺概念思考的開發者常見的反應,一開始以自己熟悉的技術來看問題,最後才發現自己對問題的理解是錯誤的。尤其「以為抽象化是將資料庫定義抽象化」的想法,更是整個弄錯抽象化思考的意義,結果最後他還是誤解了業務規則的意思。 同人前一篇文章所提到的業務規則,並非來自技術領域上萬用的設計,而是對問題領域經過抽象化思考後,所萃取而得到可以解決業務需求的重要概念。顯然 oofunp 的誤解是以技術的角度來看待抽象化思考,才會產生嚴重的觀念混淆。事實上,抽象化思考重視的不是技術實作,而是如何從實際問題當中萃取出重要的抽象概念,以增進我們對問題領域的瞭解,才能採用最適當的技術來開發軟體系統。 此外,過份強調技術經驗而輕忽概念性思維的開發者,很容易表現出自己對問題的盲目。就像 X files 留言的批評一樣,責怪同人沒有交待清楚是 XML 格式的問題,直到別人提出質疑才說明與列出參考文獻,認為同人缺乏部落格文章寫作的 common sense。但我的文章已經很清楚地提到是有關「交易訊息」語法的問題,難道他不瞭解交易訊息是 XML 技術的一般化抽象概念表述嗎?XML 只是實現交易訊息概念的一種技術,用以解決跨系統整合的問題。如果他要看到 XML 字眼才知道是訊息格式的問題,那改天換了另一種交易訊息的實作方式,我想大概他腦筋又要轉不過來了吧。 以上網友的三種批評,表面上看起來好像是不同的問題,但其背後都存在同樣的本質,那就是從交易訊息的問題中可見一斑,他們無法以抽象性思考來看待軟體開發的問題。但為什麼開發者需要抽象化思考呢?

Continue reading about 訊息交易的抽象化思考

     
jim yeh on 一月 23rd, 2009

最近某位開發者和同人討論需求規格的問題,但他的反應卻讓人感到困惑,不知是他的理解能力有問題,還是面對問題太過情緒化?以下是我們對話的內容。 開發者 D 君問同人:「規格好像沒有提到欄位空白該如何處理?」 同人回答:「沒特別說明就是代表將該欄位填入空白。」 D 君說:「為什麼不是未指定欄位內容呢?」 同人說:「如果是那樣,該欄位不應該在交易訊息中出現;但如果該欄位的內容是空白,那就應該不指定訊息欄位的值。」 D 君說:「不過,從交易訊息的定義來看,那個欄位是必要欄位,不可能不出現。」 同人說:「所以那個欄位是必要的,訊息中沒有指定值就代表欄位要填入空白。」 D 君說:「那規格應該交待這個細節?」 同人說:「不需要,規格文件不寫語法而只會記載語意,因為語法是屬於 common sense,沒必要詳盡記錄在規格文件中。不然,如果連 common sense 都要寫在文件上的話,那是否意味程式設計者也不需要懂程式語言了,反正文件上都會寫。」 D 君說:「我知道了,你的意思是說我沒有 common sense!」 同人說:「如果你覺得我那裡說你沒 common sense,請明說我可以向你道歉,否則你這種情緒化的言論,只會讓人感到不舒服!」 D 君:… 同人將這件事寫在噗浪上,有噗友認為這類的開發者能力不行,沒什麼產值卻會製造問題。不過,在此事我所看到的問題倒不是開發者能力,而是認為重點在開發者只看文件做事的心態。開發者傾向用詳盡的文件來取代個人的思考與互動的溝通,這才是我認為最可怕的事情。

Continue reading about 開發者的 common sense

     
jim yeh on 一月 16th, 2009

昨天同人在〈又見少了概括性論點〉提到〈必須面對的真相─五大程式設計迷思〉在文章結構上的問題。其實那篇文章除了結構問題之外,同人也在該篇文章內容中,發現了一些值得探討的問題,因此想在這篇文章發表我的看法。 以該篇文章內容而言,同人認為值得探討的有兩個地方,一個是程式語言一直再改變的迷思、另一個則是作者建議讀者,儘量避免用遞迴的方式來寫作程式。第一個問題只是沒有交待清楚作者想要表達的概念,而第二個問題就是嚴重的偏見了,值得讓人進行思辨以建立正確的觀念。

Continue reading about 再談程式設計的迷思