架構之必要

天在 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。

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