因為我的部落格有「統計」的功能，可以看得出來讀者是從那個網址串連進來的。剛巧看到「HEMiDEMi 共享書籤」有對之前我所整理一篇「使用案例分析常見的幾個問題」做一些迴響討論，其內的討論內容，我想也蠻有可能是眾多讀者的疑惑，所以剛好一併做個回應。當然，限於文筆表達的能力，一定仍有疑惑與無法完整瞭解筆者心中的假設點，這一些，是很歡迎在爾後 HSDc. 每兩個月固定所舉辦的「軟體設計鮮思維」面對面來做溝通討論的。

底下列出該書籤網站讀者的討論，以及個人所做的回應。

—————————————————–
引述 :『使用案例 (use case) 易學難精，若沒有把持最根本的原則與精神，很難擺脫掉既有傳統的束縛，把既往對領域與平台的知識給表達在使用案例中，就淪為「另一種」需求記錄的工具而已。 作者認為，使用案例表達的就是「純粹」的資訊系統「局部」功能觀點的需求模型，只要把握這一點，甚至在不需要作系統內部結構分析的情況下，馬上就可以轉移至程式碼的實作階段，而且是很快速直覺，可順應短線的專案開發生態。』
—————————————————–
william 說: 雖然觀點有點極端，但仍有參考價值。

Qing 說：我大概把他提出的論點看了一下, 覺得還滿合理的, 很多問題看起來都很像是很多初寫 Use Case 的人會做的事。不知道william學長覺得那些觀點極端呢?

William 說：雖然在稍後幾個段落裡，他有提到「可順應短線的專案開發生態」，也稍微提到事後還可再 refactor architecture，但我不認為這是正統的做法。除非真的只是在做 throw-away prototype，否則我認為 functionality 和 architecture 應該並進，不可過於忽略任何一個。否則以「短線的專案開發生態」而言，我高度懷疑事後是否真的還有精力去 refactor architecture，尤其當 architecture 的亂度已變得難以駕馭時。

Qing 說：這樣子看的確是一個先天不良的架構, 要在日後繼續演化, 其實並沒有那麼容易。

Hi, 我是本文的作者，從文章的內容內，諸如 william 所提到，似乎過於極端了點。這應該是個人的文章表達意涵不夠完整。

不過，個人從來是主張 “architecture first”，所以即使是短線的專案生態，仍舊以架構為最優先考量的，若各位到本人的部落格內搜尋 “architecture” 一字即可瞭解個人所重視的程度的。

william 應該是誤解了個人對 “architecture(架構)” 與 “structure(結構)” 二字的定義，在內文中，個人其實沒有提供不做 architecture，而是指可以忽略 structure 結構的分析。但在忽略時的配套措施，一定會加上 analysis class 的框架，才可能讓結構爾後做好重整的。

那麼，為何要忽略結構的設計呢？ 事實上，個人更為重視的才是結構的分析設計！但，國內的專案開發，的確存在太多不合理的現象，現實上在本人所擔任顧問的期間，竟然還沒看過有哪一個專案做好結構分析與設計的。與其如此，倒不如先順應國內短線專案開發的生態，務實一些，先做好使用案例的功能需求分析與實做開發，光這兩點，已是相當不容易了。而在第二個階段，再施以結構重整及程式碼重構的方式，讓系統的品質更有其延展與彈性度，當然，前提是待開發人員的技能、技術與溝通默契成長後，以及老闆肯願意為該系統(可能要準備產品化)釋出更多的資源(resource)。當然，william 的考量點不是沒有道理，所以必然要有配套措施，這也是在內文中提及至少會提供兩個配套措施的。

這是一種務實的作法，並不是昧於現實，也不是妥於現實，而是在理想、目標與現實找出一個動態平衡點。

P.S. 個人覺得 william 與 Qing 的考量與 concern 的建議不錯，個人準備把本討論串轉貼至本人的部落格： http://www.kenming.idv.tw 成為新的文章，也方便繼續討論。