同人的生活派對

這篇文章是投稿 ZDNet Taiwan 的文章原稿，由 ZDNet Taiwan 以〈軟體開發的難處 SA該如何解決？〉、〈為何SA很難落實簡單設計〉兩篇文章刊登。文章原稿未經 ZDNet Taiwan 編輯，內容可能與 ZDNet Taiwan 約略有所不同。

今(09)年初，應中山大學資管系主任鄭炳強教授的邀請，到他們學校做了一場演講。由於筆者與鄭教授原先並不認識，是透過台科大資管系主任李國光教授聯絡到筆者，因此，鄭教授邀請我在演講前先與他碰面、共進午餐，並且藉這個機會交流彼此在軟體工程方面的心得。

在那次午餐約會中，我們聊到了系統分析專業這個議題。鄭教授表示欣賞筆者寫的〈展現系統分析專業的七種能力〉，還曾在課堂上向他的學生推薦這篇文章…與鄭教授交流互動的過程中，也讓筆者得到不少收穫，回到台北後，一直想找機會分享這些收穫。

由於我一直想找機會回應那篇文章的讀者意見，也就是ZDNet讀者對於那篇文章的前半段〈怎樣才是專業的 SA？〉的一些留言，筆者發現這次行程的收穫，正好可以讓這篇文章有一個很好的起點。 Read the rest of this entry »

程式碼的重覆性使程式不容易維護、以及增加系統出錯的機率，同時使得程式的再用性難以提昇。因此降低程式碼的重覆性對程式碼的品質與彈性有很大的助益。然而，在資料存取與與物件型別的無法分離的情況下，卻會使得開發者難以對治程式碼的重覆性；相同處理資料的邏輯，受限於處理資料的不同型態，使得開發者必須依據資料型態不同，而改寫同一段程式碼，使得程式碼很難共用。

就像一個比較常見的例子是資料永續存取的實作，常會因為存取資料型態的不同，而影響到資料存取的界面，因此對每一個需要持久化的商業領域物件，都必須重覆地實作它們的 CRUD 存取功能。

雖然透過永續層的概念，我們可以將這種重覆性隔離開來，加上有些 ORM 永續框架的協助，開發資料存取物件的負擔並不太大。然而即使如此，我們有沒有可能避免重覆開發資料存取的元件，不用針對每一種物件型別都要寫一支相對的資料存取物件呢？要達到這樣的目的，我們必須分離資料存取的處理程序與物件型別，但要如何才能做到呢？ Read the rest of this entry »

在〈開發者的 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 字眼才知道是訊息格式的問題，那改天換了另一種交易訊息的實作方式，我想大概他腦筋又要轉不過來了吧。

以上網友的三種批評，表面上看起來好像是不同的問題，但其背後都存在同樣的本質，那就是從交易訊息的問題中可見一斑，他們無法以抽象性思考來看待軟體開發的問題。但為什麼開發者需要抽象化思考呢？ Read the rest of this entry »

最近某位開發者和同人討論需求規格的問題，但他的反應卻讓人感到困惑，不知是他的理解能力有問題，還是面對問題太過情緒化？以下是我們對話的內容。

開發者 D 君問同人：「規格好像沒有提到欄位空白該如何處理？」

同人回答：「沒特別說明就是代表將該欄位填入空白。」

D 君說：「為什麼不是未指定欄位內容呢？」

同人說：「如果是那樣，該欄位不應該在交易訊息中出現；但如果該欄位的內容是空白，那就應該不指定訊息欄位的值。」

D 君說：「不過，從交易訊息的定義來看，那個欄位是必要欄位，不可能不出現。」

同人說：「所以那個欄位是必要的，訊息中沒有指定值就代表欄位要填入空白。」

D 君說：「那規格應該交待這個細節？」

同人說：「不需要，規格文件不寫語法而只會記載語意，因為語法是屬於 common sense，沒必要詳盡記錄在規格文件中。不然，如果連 common sense 都要寫在文件上的話，那是否意味程式設計者也不需要懂程式語言了，反正文件上都會寫。」

D 君說：「我知道了，你的意思是說我沒有 common sense！」

同人說：「如果你覺得我那裡說你沒 common sense，請明說我可以向你道歉，否則你這種情緒化的言論，只會讓人感到不舒服！」

D 君：…

同人將這件事寫在噗浪上，有噗友認為這類的開發者能力不行，沒什麼產值卻會製造問題。不過，在此事我所看到的問題倒不是開發者能力，而是認為重點在開發者只看文件做事的心態。開發者傾向用詳盡的文件來取代個人的思考與互動的溝通，這才是我認為最可怕的事情。 Read the rest of this entry »

昨天同人在〈又見少了概括性論點〉提到〈必須面對的真相─五大程式設計迷思〉在文章結構上的問題。其實那篇文章除了結構問題之外，同人也在該篇文章內容中，發現了一些值得探討的問題，因此想在這篇文章發表我的看法。

以該篇文章內容而言，同人認為值得探討的有兩個地方，一個是程式語言一直再改變的迷思、另一個則是作者建議讀者，儘量避免用遞迴的方式來寫作程式。第一個問題只是沒有交待清楚作者想要表達的概念，而第二個問題就是嚴重的偏見了，值得讓人進行思辨以建立正確的觀念。 Read the rest of this entry »

最近寫了很多的占星文章，不知道有沒有人不習慣呀？為了擔心有些讀者無法適應，同人在此寫了一篇有關軟體開發的文章以中和主題，並用來分享我對彈性分類策略的設計心得。

許多的資料查詢，常會根據某些不同的分群觀點來將資料作分類。例如交易資料中的「產品分類」或是「單據種類」，使用者經常會希望將這些欄位當作查詢條件，讓他們可以找出相同產品分類或是單據分類的資料。

然而，實際上的查詢作業需求可能會比較複雜，也就是使用者可能會需要在一次資料查詢的結果，希望把不同資料分類，但彼此的分類之間卻同屬於相同分類群組的資料顯示在一起。我們可以新增資料分類群組的欄位，並依據資料分類來設定其分類群組的內容。這種作法在資料查詢方面的實作上非常簡便，但缺點則是要在資料的維護上額外花費一些成本。

因為這樣的設計會造成資料欄位的遞移相依，違反資料正規化的原則。當資料分類內容修改時，分類群組的內容也要跟著修正；而實際上很可能會因為程式的瑕疵或系統出現異常現象而造成資料不完整或缺乏一致性的風險。

而且，很多依據分類群組集中查詢的需求往往是在專案後期才提出來，如果開發者並不願意因此改動資料庫結構，要如何在不增加群組欄位的情況下，實作出依據分類群組集中查詢的功能呢？

答案當然是將分類群組欄位化成對應的查詢語法或群組欄位的顯示內容，這樣會讓查詢資料的實作程式變得複雜些。因為程式實作者除了必須知道資料的來源之外，尚須瞭解群組欄位與資料分類之間如何轉換。而當相同的查詢需求散布在系統各個程式之間時，就會增加程式開發的複雜度與出錯機率。尤其使用者可能會視作業方式來增加分類群組的需求，開發者應該如何運用設計的彈性，以降低程式開發沒有必要的複雜度呢？

同人在此提出一種設計手法，運用彈性分類群組策略的設計來解決以上的問題 Read the rest of this entry »

最近有位程式開發者 P 君展示他所開發的系統功能，那是供使用者維護代碼的操作界面。由於之前原程式開發者認為按照規格不容易做到，因此委由另一位程式設計師改用折衷的設計方式，希望能夠同時達到使用者便於操作及容易開發兩個目的。

系統操作界面總共只有三個欄位，同時考慮到使用者操作的便利性，因此我將此界面規格設計為可直接修改顯示在資料清單上的資料、並在刪除時提供勾選的方式讓使用者可進行多筆資料刪除；而在新增資料方面，我認為使用者會需要看到清單上的資料，因此設計直接在清單底端直接輸人新增資料。

但這樣的設計，原先負責開發的 D 君認為開發困難度較高。因此專案經理就與我討論可否折衷一下，請另一位開發者P君改用既能滿足輸入資料與顯示清單在同一個畫面，又能降低開發的困難度。我認為如果能夠做到那當然很好，但強調必須符合可用性的需求；也就是為了操作簡便，必須要能夠讓使用者同時修改或刪除整批資料。

然而，當同人看到 P 君展示的系統時，卻發現他所開發出的軟體，不但無法完全達到我先前所提到的需求，而且還有無法符合可靠性需求的問題。P 君把新增、修改及刪除的功能放在資料輸入的表單中，卻為了同時容納這三個功能的需要，讓每個欄位都可讓使用者輸入。顯然，這是個粗糙的設計。因為這讓使用者有可能在修改或刪除資料時，改動到他不該更動的欄位而使系統產生難以預料的問題。

同人對這樣的設計實在感到不可思議 Read the rest of this entry »

許多採用使用案例建模方法進行需求分析的開發者，對於不需要使用者介入的系統自動作業，通常會用工作排程者來當成使用案例的主要參與者。讓系統工作排程來啟動使用案例以與系統互動，這對系統開發者而言，可以讓他們了解系統應該如何與外界互動以完成系統所提供的功能，這樣看起來是可行的需求塑模手法。

不過，工作排程者牽涉到系統設計的觀點，如果我們不想讓需求相依於系統設計，那麼我們就必須將工作排程者變成更共通而抽象化的概念。工作排程者的抽象化概念是什麼呢？我們不難理解，工作排程者也只不過是實現時間概念的具體設計。因此，照理時間才是系統自動作業的主要參與者。

然而，當我們把時間當成系統自動作業的主要參與者時，我們會遭遇到另一個問題。那就是基於黑箱的角度來看系統，使用案例應該是以使用者或外部系統來看系統，瞭解如何系統與互動而達到特定目的或產生價值。很顯然地，系統自動作業並沒有辦法為「時間」達到任何的目的或創造價值。

換句話說，我們並未找到系統自動作業的真正使用者，即使我們把工作排程者當成使用者，以使用系統的組織觀點來看，我們將會無法了解系統自動作業和組織目標的達成有何關係，而遺漏了相當重要的使用案例觀點（use case view）。 Read the rest of this entry »

本篇文章是投稿 ZDNet 的文章原稿，並以〈怎樣才是專業的 SA？〉與〈系統分析專業的七種能力〉兩篇文章刊出。原稿未經 ZDNet 編輯，其內容可能會與刊登的文章內容有約略的不同。

對於很多從事軟體設計工作，對系統分析有興趣的開發者而言，常會關心系統分析專業能力的學習，以讓他們能夠在將來勝任系統分析的工作。 要成為系統分析師需要學些什麼呢？當然系統分析師必須要懂技術，才能根據軟體需求提出最適合的技術觀點，也就是運用解決方案領域（solution space）的知識來把事情做正確。不過，如果系統分析師不懂問題領域（problem space）知識，將會很難導出使用者實際的軟體需求，以做出正確的事情。

通常系統分析師會透過訪談利害關係人來取得軟體需求，但如果系統分析師缺乏問題領域知識，很可能會在溝通過程中出現困難，使得所導出的軟體需求無法符合使用者的需要。

在實際的軟體開發過中，要讓系統分析師同時兼顧於解決方案領域與問題領域的知識是很困難的。在現實世界中，通常很難找到不僅懂得軟體開發的技能，又同時具備問題領域知識的人才。而且軟體開發專案本身存在時程與成本等限制，多半不允許系統分析師花太多的時間與成本學習問題領域知識。因此，要期待系統分析師學習問題領域知識是不切實際且又不符合經濟效益的做法。

系統分析師要如何展現出系統分析的專業，才能整合問題領域與解決方案領域的知識，有效地提出具體可行的問題解決方案？ Read the rest of this entry »