為失敗所作的設計?

        由於目前在任職的公司內,我所屬的單位算是掌管公司技術方向的單位,有部分的工作內容就像是技術總監那樣(Tech Director),必須對公司內的專案所採用的技術提供審閱和建議,也需要指導設計方向與使用的開發樣式。

        我們這個單位的目的,說起來就是要根據本身的豐富經驗來『洞悉未來、未雨稠繆』,避免工作團隊因為想法太過直接,而不小心掉入『犧牲執行效能,設計欠缺彈性』的錯誤。簡而言之,這樣的角色似乎需要想太多,然而這件事本來就有許多困難與矛盾在,甚至很多時候,我們這個單位內都無法達成共識。

        最近就有這麼一個案例,我和另一個同事合作評估一個新專案的開發策略,這個專案原本所使用的資料庫產品是價格昂貴的商業用資料庫,我主張盡可能善用該產品所提供的所有功能來達成這個專案所需,然而另一位同事的想法卻與我迥異。


        他認為我的做法將會把這個專案與該產品綁得太緊,之後若公司因為精簡成本而決定不再使用該公司昂貴的資料庫產品,我們這個專案就必須改寫,又會多花開發的功夫。他主張,資料庫就只當作單純的資料倉儲,所有的資料運算都拉回應用程式App Layer內進行,與資料庫間的溝通指令全部只遵循國際標準ANSI-SQL,不要使用各家資料庫提供的特殊指令語法。他認為,這樣將來如果這個專案如果要轉換到其他廠牌的資料庫產品,就可以避免修改,無痛轉移

        我相信一定有許多開發人員看到此都會點點頭,畢竟 Write once,run everywhere 無痛又不用改程式,是所有開發者的美夢啊。

        這就是標準的未雨稠繆替未來鋪好後路保留彈性的做法,我當然尊重這位同事過去曾經為了類似的經驗痛苦過。

        雖然這樣的思維是好的,但還是要看應用場合,因為世界上沒有任何決策是可以放諸四海皆準。如果是前端的 web 開發,我絕對贊成這個意見,因為我們沒辦法預期訪客使用何種瀏覽器,所有遵循標準是較好的做法。但對這種後端內部的方案決定,就算擔心未來可能有變數,我也無法贊成這種思考模式。

        因為對我而言,這就是為失敗所作的設計

        因為我們擔心...
  1. 如果營運不善,公司要精簡成本...?
  2. 如果以後再也沒有這麼方便的產品可以用...?
  3. 如果東西因此要改寫...?
        我們滿腦子想的是:如果事情不如預期,我們會受到什麼影響?

        講難聽點,以上面的出發點單純只是如何在最糟的狀況下幫開發者(自己)省麻煩

        我們不是想著怎麼贏,而是失敗了怎麼辦,所以我們會採取最保守的策略來應付。而我所上的黑色卡內基莫菲定律都告訴我們,事情總是會往我們擔心的壞方向發展。於是乎,最後我們擔心的事情真的發生,公司真的經營不善而精簡成本,真的用上之前所鋪的後路,我們反而為此沾沾自喜,而或許高層對我們的高瞻遠矚和未雨綢繆感到佩服。

        然而事情的真相卻是,我們的信念和潛意識促使了這件事發生。

        當時面對同事,我簡單問了一句:「如果照這樣的設計決策,我們要避開所有高級資料庫提供的專屬特殊能力,請問公司為什麼要花大錢買商業用產品?我們一開始就用免費的資料庫像是 MySQL 不就好了是嗎?

        同事啞然:這個問題我要想一想...。

        公司的採購到底有沒有值回票價,其實就在於我們有沒有物盡其用,儘全力發揮這個產品的所有潛力。我相信你絕不會家裡買了高級微電腦洗衣機,因為擔心有一天洗衣機壞掉沒得用,得自己洗衣服,一開始就避免用他的自動脫水功能來養成自己擰乾衣服的習慣。

        這完全不合理嘛!

        差別在於,採購這個產品的錢不是開發者自己掏錢出來買,所以不去用他的功能當然不會有浪費的感覺,也不會痛。

        如果有一天,真的發生了必須捨棄所綁定的產品而要改寫程式的情況呢?那就動手改寫吧!洗衣機壞了的時候再來學怎麼自己洗衣服也不是什麼大不了的事情。

        『對遵循標準的最佳化,就是違背對效能的最佳化。兩者絕對無法兼顧

        然而對效能的最佳化有時候才是幫公司贏得市場的方向。我相信自己存在的目的,是用技術來幫助公司的 Business 可以,而不是只為了讓公司輸的時候有地方可以『逃』。

        千萬不要讓預留後路的設計變成了為失敗而做的設計只有在不傷害最佳表現的前提下所預留的後路,才是真正的後路

熱門文章