表面上看起來好像實作泛型可以讓某一段程式碼重複使用，但 Java 在泛型的限制，也增加他重構程式碼的困難度與複雜度。這麼說來，假如石頭成的想法是正確的，用 Java 的泛型來重構程式碼，只會讓程式員沒事自討苦吃。然而，同人在仔細研究他的程式碼之後，發現可以用更簡潔的方式來使用 Java 的泛型。
同人看 Kenming Wang 這篇文章覺得怪怪的，倒不是不贊同他對寫好使用案例好處的觀點，而是覺得強迫新手去做我們認為有價值的東西是很危險的。
系統分析師該如何思考與學習的方法以展現其專業。然而，許多人對系統分析專業的疑惑出在忽略「結構與非結構的隔閡」，使得系統分析師陷入了過度簡化設計與過度工程化，也就是所謂過度設計的兩難情境。
程式碼的重覆性使程式不容易維護、以及增加系統出錯的機率，同時使得程式的再用性難以提昇。因此降低程式碼的重覆性對程式碼的品質與彈性有很大的助益。然而，在資料存取與與物件型別的無法分離的情況下，卻會使得開發者難以對治程式碼的重覆性；相同處理資料的邏輯，受限於處理資料的不同型態，使得開發者必須依據資料型態不同，而改寫同一段程式碼，使得程式碼很難共用。 就像一個比較常見的例子是資料永續存取的實作，常會因為存取資料型態的不同，而影響到資料存取的界面，因此對每一個需要持久化的商業領域物件，都必須重覆地實作它們的 CRUD 存取功能。 雖然透過永續層的概念，我們可以將這種重覆性隔離開來，加上有些 ORM 永續框架的協助，開發資料存取物件的負擔並不太大。然而即使如此，我們有沒有可能避免重覆開發資料存取的元件，不用針對每一種物件型別都要寫一支相對的資料存取物件呢？要達到這樣的目的，我們必須分離資料存取的處理程序與物件型別，但要如何才能做到呢？
在〈開發者的 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 字眼才知道是訊息格式的問題，那改天換了另一種交易訊息的實作方式，我想大概他腦筋又要轉不過來了吧。 以上網友的三種批評，表面上看起來好像是不同的問題，但其背後都存在同樣的本質，那就是從交易訊息的問題中可見一斑，他們無法以抽象性思考來看待軟體開發的問題。但為什麼開發者需要抽象化思考呢？
最近某位開發者和同人討論需求規格的問題，但他的反應卻讓人感到困惑，不知是他的理解能力有問題，還是面對問題太過情緒化？以下是我們對話的內容。 開發者 D 君問同人：「規格好像沒有提到欄位空白該如何處理？」 同人回答：「沒特別說明就是代表將該欄位填入空白。」 D 君說：「為什麼不是未指定欄位內容呢？」 同人說：「如果是那樣，該欄位不應該在交易訊息中出現；但如果該欄位的內容是空白，那就應該不指定訊息欄位的值。」 D 君說：「不過，從交易訊息的定義來看，那個欄位是必要欄位，不可能不出現。」 同人說：「所以那個欄位是必要的，訊息中沒有指定值就代表欄位要填入空白。」 D 君說：「那規格應該交待這個細節？」 同人說：「不需要，規格文件不寫語法而只會記載語意，因為語法是屬於 common sense，沒必要詳盡記錄在規格文件中。不然，如果連 common sense 都要寫在文件上的話，那是否意味程式設計者也不需要懂程式語言了，反正文件上都會寫。」 D 君說：「我知道了，你的意思是說我沒有 common sense！」 同人說：「如果你覺得我那裡說你沒 common sense，請明說我可以向你道歉，否則你這種情緒化的言論，只會讓人感到不舒服！」 D 君：… 同人將這件事寫在噗浪上，有噗友認為這類的開發者能力不行，沒什麼產值卻會製造問題。不過，在此事我所看到的問題倒不是開發者能力，而是認為重點在開發者只看文件做事的心態。開發者傾向用詳盡的文件來取代個人的思考與互動的溝通，這才是我認為最可怕的事情。
昨天同人在〈又見少了概括性論點〉提到〈必須面對的真相─五大程式設計迷思〉在文章結構上的問題。其實那篇文章除了結構問題之外，同人也在該篇文章內容中，發現了一些值得探討的問題，因此想在這篇文章發表我的看法。 以該篇文章內容而言，同人認為值得探討的有兩個地方，一個是程式語言一直再改變的迷思、另一個則是作者建議讀者，儘量避免用遞迴的方式來寫作程式。第一個問題只是沒有交待清楚作者想要表達的概念，而第二個問題就是嚴重的偏見了，值得讓人進行思辨以建立正確的觀念。
最近寫了很多的占星文章，不知道有沒有人不習慣呀？為了擔心有些讀者無法適應，同人在此寫了一篇有關軟體開發的文章以中和主題，並用來分享我對彈性分類策略的設計心得。 許多的資料查詢，常會根據某些不同的分群觀點來將資料作分類。例如交易資料中的「產品分類」或是「單據種類」，使用者經常會希望將這些欄位當作查詢條件，讓他們可以找出相同產品分類或是單據分類的資料。 然而，實際上的查詢作業需求可能會比較複雜，也就是使用者可能會需要在一次資料查詢的結果，希望把不同資料分類，但彼此的分類之間卻同屬於相同分類群組的資料顯示在一起。我們可以新增資料分類群組的欄位，並依據資料分類來設定其分類群組的內容。這種作法在資料查詢方面的實作上非常簡便，但缺點則是要在資料的維護上額外花費一些成本。 因為這樣的設計會造成資料欄位的遞移相依，違反資料正規化的原則。當資料分類內容修改時，分類群組的內容也要跟著修正；而實際上很可能會因為程式的瑕疵或系統出現異常現象而造成資料不完整或缺乏一致性的風險。 而且，很多依據分類群組集中查詢的需求往往是在專案後期才提出來，如果開發者並不願意因此改動資料庫結構，要如何在不增加群組欄位的情況下，實作出依據分類群組集中查詢的功能呢？ 答案當然是將分類群組欄位化成對應的查詢語法或群組欄位的顯示內容，這樣會讓查詢資料的實作程式變得複雜些。因為程式實作者除了必須知道資料的來源之外，尚須瞭解群組欄位與資料分類之間如何轉換。而當相同的查詢需求散布在系統各個程式之間時，就會增加程式開發的複雜度與出錯機率。尤其使用者可能會視作業方式來增加分類群組的需求，開發者應該如何運用設計的彈性，以降低程式開發沒有必要的複雜度呢？ 同人在此提出一種設計手法，運用彈性分類群組策略的設計來解決以上的問題
除了軟體功能之外，開發者還必須兼顧性能的設計，其中當然包括兼顧操作的人性化需求外，還必須思考如何減少因為設計不良而造成操作錯誤的機會。
許多採用使用案例建模方法進行需求分析的開發者，對於不需要使用者介入的系統自動作業，通常會用工作排程者來當成使用案例的主要參與者。讓系統工作排程來啟動使用案例以與系統互動，這對系統開發者而言，可以讓他們了解系統應該如何與外界互動以完成系統所提供的功能，這樣看起來是可行的需求塑模手法。 不過，工作排程者牽涉到系統設計的觀點，如果我們不想讓需求相依於系統設計，那麼我們就必須將工作排程者變成更共通而抽象化的概念。工作排程者的抽象化概念是什麼呢？我們不難理解，工作排程者也只不過是實現時間概念的具體設計。因此，照理時間才是系統自動作業的主要參與者。 然而，當我們把時間當成系統自動作業的主要參與者時，我們會遭遇到另一個問題。那就是基於黑箱的角度來看系統，使用案例應該是以使用者或外部系統來看系統，瞭解如何系統與互動而達到特定目的或產生價值。很顯然地，系統自動作業並沒有辦法為「時間」達到任何的目的或創造價值。 換句話說，我們並未找到系統自動作業的真正使用者，即使我們把工作排程者當成使用者，以使用系統的組織觀點來看，我們將會無法了解系統自動作業和組織目標的達成有何關係，而遺漏了相當重要的使用案例觀點（use case view）。
最新迴響