我們這個單位的目的，說起來就是要根據本身的豐富經驗來『洞悉未來、未雨稠繆』，避免工作團隊因為想法太過直接，而不小心掉入『犧牲執行效能，設計欠缺彈性』的錯誤。簡而言之，這樣的角色似乎需要想太多，然而這件事本來就有許多困難與矛盾在，甚至很多時候，我們這個單位內都無法達成共識。
最近就有這麼一個案例，我和另一個同事合作評估一個新專案的開發策略，這個專案原本所使用的資料庫產品是價格昂貴的商業用資料庫，我主張盡可能善用該產品所提供的所有功能來達成這個專案所需，然而另一位同事的想法卻與我迥異。
他認為我的做法將會把這個專案與該產品綁得太緊，之後若公司因為精簡成本而決定不再使用該公司昂貴的資料庫產品，我們這個專案就必須改寫，又會多花開發的功夫。他主張，資料庫就只當作單純的資料倉儲，所有的資料運算都拉回應用程式（App Layer）內進行，與資料庫間的溝通指令全部只遵循國際標準（ANSI-SQL），不要使用各家資料庫提供的特殊指令語法。他認為，這樣將來如果這個專案如果要轉換到其他廠牌的資料庫產品，就可以避免修改，無痛轉移。
我相信一定有許多開發人員看到此都會點點頭，畢竟 Write once，run everywhere 無痛又不用改程式，是所有開發者的美夢啊。
這就是標準的『未雨稠繆、替未來鋪好後路、保留彈性』的做法，我當然尊重這位同事過去曾經為了類似的經驗痛苦過。
雖然這樣的思維是好的，但還是要看應用場合，因為世界上沒有任何決策是可以放諸四海皆準。如果是前端的 web 開發，我絕對贊成這個意見，因為我們沒辦法預期訪客使用何種瀏覽器，所有遵循標準是較好的做法。但對這種後端內部的方案決定，就算擔心未來可能有變數，我也無法贊成這種思考模式。
因為對我而言，這就是『為失敗所作的設計』。
因為我們擔心...：
- 如果營運不善，公司要精簡成本...？
- 如果以後再也沒有這麼方便的產品可以用...？
- 如果東西因此要改寫...？
講難聽點，以上面的出發點單純只是『如何在最糟的狀況下幫開發者（自己）省麻煩』。
我們不是想著『怎麼贏』，而是『失敗了怎麼辦』，所以我們會採取『最保守』的策略來應付。而我所上的『黑色卡內基』和『莫菲定律』都告訴我們，事情總是會往我們擔心的壞方向發展。於是乎，最後我們擔心的事情真的發生，公司真的經營不善而精簡成本，真的用上之前所鋪的後路，我們反而為此沾沾自喜，而或許高層對我們的高瞻遠矚和未雨綢繆感到佩服。
然而事情的真相卻是，我們的信念和潛意識促使了這件事發生。
當時面對同事，我簡單問了一句：「如果照這樣的設計決策，我們要避開所有高級資料庫提供的專屬特殊能力，請問公司為什麼要花大錢買商業用產品？我們一開始就用免費的資料庫像是 MySQL 不就好了是嗎？」
同事啞然：「這個問題我要想一想...。」
公司的採購到底有沒有值回票價，其實就在於我們有沒有物盡其用，儘全力發揮這個產品的所有潛力。我相信你絕不會家裡買了高級微電腦洗衣機，因為擔心有一天洗衣機壞掉沒得用，得自己洗衣服，一開始就避免用他的自動脫水功能來養成自己擰乾衣服的習慣。
這完全不合理嘛！
差別在於，採購這個產品的錢不是開發者自己掏錢出來買，所以不去用他的功能當然不會有浪費的感覺，也不會痛。
如果有一天，真的發生了必須捨棄所綁定的產品而要改寫程式的情況呢？那就動手改寫吧！洗衣機壞了的時候再來學怎麼自己洗衣服也不是什麼大不了的事情。
『對遵循標準的最佳化，就是違背對效能的最佳化。兩者絕對無法兼顧』。
然而『對效能的最佳化』有時候才是幫公司贏得市場的方向。我相信自己存在的目的，是用技術來幫助公司的 Business 可以『贏』，而不是只為了讓公司輸的時候有地方可以『逃』。
千萬不要讓預留後路的設計變成了『為失敗而做的設計』，只有在不傷害最佳表現的前提下所預留的後路，才是真正的後路。
沒有留言:
張貼留言