如何產生四不像的系統?
當在做系統的架構設計時, 慣於先找出系統的範圍, 接著將抽象需求透過各種文件及圖形概念性地形式化, 透過OO設計, 封裝出各種組件, 以及相互關係及責任歸屬... 等
大致上會如下圖般, 系統有外框(範圍), 有小方塊(元件或類別), 然後會有關係(如:9使用1) , 最後我們許下願望: 王子與公主從此過著幸福快樂的日子
過了一陣子, 有個超強的騎士(PG), 覺得為什麼要繞道呢? 明明走直線是最低距離, 所以硬是將某個小方塊切成一半, 讓9可以直接使用1,
騎士: 經過我的Refactory, 系統效率成長30%, 而且在我周祥且神奇的手法下, 更好維護.
而後果呢? 就是我們多了2個三角型要多維護, 僅管騎士再三保證他考慮得很周祥, 但往往因為小方塊不完整, 故常常會出現奇怪的BUG ...
到了測試時, 國王身旁的謀士(User), 開始提出當初沒想到或不同的假設及條件下的指令, 外框就不再是方型了, 而變成多邊型.
User: 這不難改吧~ 而且這應該是常識(not mine).
而後果呢? 系統開始無法用一言以蔽之, 如: 催收暨客戶管理暨評分卡之無敵系統
驗收後, 維護人員會收到如下圖的系統.
然後它會很神奇的在User漫駡, 維護者幹譙, 被廠商放棄 ... "順利"地運轉了n年, 好像也沒什麼大不了的 ~~~
本文僅獻給無數辛苦的維護者,
因為User並不會來看這篇, 所以他不會知道自己做了什麼或說了什麼 "惡",
而廠商拿了錢完成了專案也算仁至義盡, 後續來電或到廠協助是出自於他們良心, 善心與愛心, (大多數的維護費都是少的可憐)
所以不要再抱怨了, 有機會就自己動手改到"較"好維護, 沒機會就開始改依林四 (不過還是逃不了的)
... 說穿了 這就是現實的人生.
而從意念式的需求最後形式化的系統及程式, 仍然是fat and dirty 的存在著 !!
