架構之必要

c9s
c9s
Oct 11, 2015 · 3 min read

前天在 PHPConf 2015 難得與中國頂尖的 PHP 工程師 Xinchen Hui (laruence) 請教關於 PHP Zend Engine 的 Contribution Work Flow,在 GitHub 送拉回請求 (Pull Request) 上有幾點多注意可以改善 review 以及 merge 的效率。Xinchen Hui 提到,不少人一看到 PHP 開始活躍了,就一股腦的提交了一堆新語言特性,但,誰來做?隨便改改幾千行,那產生出來的邊緣效應 (Side Effect) 跟臭蟲 (Bug) 誰來處理?

其實簡而言之,就是一種眼高手低的問題。

在台灣,似乎也可以看到不少眼高手低的狀況,不少工程師都在追求架構,而忽略了專業能力基本功的培養及訓練,好似架構是某種萬靈丹,聽起來夠酷夠炫,只要來個架構配方,一切問題都得以解決。但基礎功沒練好的話,寫出來的程式是個 O(N5) ,那再給你多棒的架構,都是枉然。

讀到這邊,請不要誤會我的意思,我不是說設計架構就是在眼高手低,而是一種忽略基本能力卻想要直接挑戰高難度場景的情形。

我可以理解處理架構、設計架構是很有趣的工作,但客戶若希望 “解決問題” ,工程師不一定要用到所謂的 “龐大神級超強架構” 才能解決問題,好像機器加越多、架構越大,你就越厲害越有面子,真的嗎?你思考一下,架構越大,用的機器越多,燒的錢也越多,企業營運是要靠相對的現金流才有辦法撐得下去,大家是在同一條船上,你把公司的錢燒得越快,企業就更容易裁員,你的飯碗也會不保,還會害你同事沒飯碗。

事實上,回到基本面,能夠盡可能用最小巧、效能最高的程式在有限的資源上解決問題,甚至是不靠程式,利用改善流程來解決問題,才應該是整個解決問題的方向才對。譬如在 iNDIEVOX 林志傑的分享中,我最欣賞的是排隊機制的設計,這種做法,既不用一股腦的狂加機器,也不用一頭熱的狂改程式,一樣能解決問題。

再者,在整個工作中,應該是責任感最為重要,而不是以設計架構 “好有趣”, “好好玩” 為主要動機。做壞了,你是否願意承擔責任?還是辭職逃避走人?這種心態就好像公司或客戶是你的白老鼠,給你個遊戲的平台玩玩,玩壞了?好像重來就好,這種心態應該避免。

還有一種狀況是, Project Leader 一直想在客戶專案上,實踐自己夢想已久的 “超級架構”,專案初期沒有評估成本,就直接將尚未成形的商業應用規劃在大型架構上,用一樣的預算,燒掉了額外消耗的人力不說,還因為架構過於龐大,讓整個專案時程延宕,結果團隊心力消磨殆盡,最後導致專案失敗收場。

我心目中的理想架構,是隨著企業價值一起成長,循著一種漸進的方式去演化。世界上,沒有什麼一開始就完美的架構,就像曾義峰 (Ant) 在 Enterprise Architecture Case in PHP 議程中說的「一種成功的架構,不見得會在另外一種商業模式上表現良好。」失敗的商業模型,再用多理想的架構處理,一樣是 0 x N = 0。

是人,免不了喜歡新奇酷炫的事物。我不是個基礎功扎實的工程師,也有眼高手低的狀況該反省。事實上,看到許多高手在各自領域中投入心血,更覺得自行慚愧,努力把基礎功繼續努力、堅持地練扎實,才是自己更應當做的事,彼此加油吧!

c9s

Written by

c9s

yet another programmer in 21 century