分類彙整: 分析設計建模

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

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

分類: 分析設計建模, 問題解決, 編程技巧, 職場, 設計原則 | 發佈留言

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

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

分類: 分析設計建模, 利害關係人, 品質文化, 問題解決, 專案團隊, 專案管理, 思考, 溝通, 生活感觸, 管理, 組織, 職場, 衝突, 領導 | 發佈留言

把抽象化當技術的繆誤

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

分類: 分析設計建模, 問題解決, 專案團隊, 思考, 溝通, 生活感觸, 職場, 衝突 | 發佈留言

Java 泛型複雜嗎?

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

分類: 分析設計建模, 品質文化, 問題解決, 學習, 編程技巧, 職場, 設計原則, 軟體開發 | 發佈留言

強迫新手這麼做的風險

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

分類: 分析設計建模, 利害關係人, 問題解決, 寫作, 專案風險, 思考, 溝通, 生活感觸, 組織, 職場, 領導 | 2 則留言

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

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

分類: CNet/ZDNet, 分析設計建模, 利害關係人, 寫作, 專案團隊, 思考, 溝通, 生活感觸, 知識管理, 職場 | 3 則留言

降低資料存取的重覆性

程式碼的重覆性使程式不容易維護、以及增加系統出錯的機率,同時使得程式的再用性難以 … 閱讀全文

分類: 分析設計建模, 問題解決, 學習, 編程技巧, 設計原則 | 1 則留言

訊息交易的抽象化思考

在〈開發者的 common sense〉的留言中,同人看到一些網友的批評。我發現 … 閱讀全文

分類: 分析設計建模, 品質文化, 問題解決, 思考, 易經思維, 生活感觸, 編程技巧, 設計原則 | 9 則留言

開發者的 common sense

最近某位開發者和同人討論需求規格的問題,但他的反應卻讓人感到困惑,不知是他的理解 … 閱讀全文

分類: 分析設計建模, 問題解決, 專案團隊, 思考, 溝通, 生活感觸, 職場, 衝突, 設計原則 | 10 則留言

再談程式設計的迷思

昨天同人在〈又見少了概括性論點〉提到〈必須面對的真相─五大程式設計迷思〉在文章結 … 閱讀全文

分類: CNet/ZDNet, 分析設計建模, 問題解決, 學習, 思考, 編程技巧, 職場, 設計原則 | 2 則留言