由於我在公司所處的團隊的工作內容，有部分是在 review 公司內其他團隊的 HLD ( High-Level Design - 高階設計 ) ，並給予本身專業上的建議，最近我發現，這樣的職掌讓我面臨了許多矛盾與衝突。
原因是：每個設計其實都有他本身的道理。
除非找來的工程師是個沒經驗的初學者，犯了很多沒 sense 的錯誤，不然稍有年資的工程師所做的設計多半有他站得住腳的考量。那個考量很可能是「成本與風險」，也可能是「架構和彈性」，也可以是「效能和穩固」，更可以是「商業價值和使用者經驗」。以上任何一個顧慮你都不能說他錯，但是大家抓住的利基點都不同，互不退讓之下，事情往往難以敲板定案。
常常我們當初做的設計決策，是基於當時諸多環境背景的限制下妥協的產物，例如：時程、預算、資源。等到後人接手維護時，則怎麼看都不順眼，不斷批評。甚至當時的首要考量，也因為時空推移，最重要的關鍵因素不再重要，取而代之的卻是其他原本不怎麼重要的因素。
簡單說，沒有完美的設計，所有的設計都可以被挑剔、被批評。這時候，保留和理解當時設計的考量，變得格外重要。
接手系統的負責人，因為不懂當時的考量，所以可能會多走冤枉路，踩下前人踏過的洞。或是過度害怕未知的恐懼，所以因循陋習 ( 無論這次資源是否足夠，都沿襲過去資源不足時的做法，有聽過煎魚去頭去尾的寓言故事嗎？ )。
無論是那一種清境，手上負責的系統都會逐漸衰敗下去。
去年我跟公司提出一個解決辦法，去彌平設計師和管理層之間的期望落差，並且留下可供追溯的資料參考。就是在每次的需求變更或新專案，都由管理階層填一張表，給系統各個面向一個相對分數，作為之後分析師與設計師執行的方向。
舉例：假設把系統面向分為「效能」、「穩固」、「管理維護」、「擴展」四個面向，然後給與管理階層總和無法整除的點數，讓他們對這四個面向各自配分。
因為分數只是相對意義，故意設計成無法整除，就是要避免主管把點數平均分配。當點數不夠分配的時候，可以看出主管會優先「犧牲」那一個面向。
這非常重要，不但提示我們最後可以優先妥協的面向，也是解決設計師和工程師之間意見相左的依據，更是日後設計被批判時的防禦利器（因為很可能被犧牲掉的項目就是「管理維護」，接手的人通常會痛罵這點）。
最近公司就有一個爭論：過去公司的產品被要求要使用
IoC Pattern，當時的考量是什麼我們不得而知，只是一直沿用下來。然而這個 Pattern 對管理維護卻成為莫大的包袱。
深受其害的同事於是找了一篇強調
IoC 是
邪惡的文章轉給我：
我的想法是，工具本質是中立的，使用的人是邪惡的它才會變得邪惡。菜刀是拿來做料理的，但是有人若拿來殺人，我不能就這麼說：菜刀是邪惡的。
那篇文章的標題若改為：「dependency-injection EVERYWHERE is evil」會精確許多。
對我來說，濫用工具和禁止特定工具都是邪惡的。
世上沒有完美的設計，只有合適的設計。
請問大家為了找到「合適的設計」，有去思考該導入了什麼樣的流程或方法？
留言
張貼留言