設計模式和效率 哪個比較重要？ 為什嗎？

昨天在GitHub給某開源PHP項目Pull了request
我把common庫裡的一個常用核心函數改為 先判斷config裡是否enabled
再決定load class 而不是load後 再在method內判斷N次config是否enabled
我想這在效率上還是有很大區別的

提交後 Owner回複說 他明白我的出發點是效率 可是這個判斷應該留給class去處理
好吧 我一想 對 可能這樣"看著乾淨些" 但就因為這原因 就可以捨棄效率了?
那個函數單次請求至少會被調用15次 對我來說真不合理
我也沒打算去爭執 畢竟是別人的項目 但就是蠻糾結的

我對我自己的的代碼品質感覺很良好 開始兩次的PR都被owner merged了
上一次被close的原因和上述一樣 請勿擔心 謝謝。

回複內容：

在效能最佳化裡有一句話，就是在效能沒有明顯表現出問題之前，不要進行最佳化，因為對效能的最佳化往往會影響代碼的解耦和可重用性

至於題主的具體例子，就不作評論了，畢竟沒看到具體的代碼你這是代碼寫少了。簡潔設計的低耦合可擴充性遠比一點點效率更重要。自己覺得什麼不對就去最佳化，知道“Premature optimization is the root of all evil”這句話嗎？

順便吐個槽：什麼時候開始PHP還在乎這點執行效率了？設計模式難道不是為了提高效率？（設計模式是長期程式工作者總結的一套提高開發效率與程式執行效率的編程方法，在這種情況下， 應該根據項目需求與項目的具體實現變更！）效率不是瓶頸的情況下，設計模式重要。很明顯的效率問題肯定是要提前就處理掉的，但是對於你說的例子這個config問題，我不贊同你的說法。
我說不上來具體原因，但是，在method內部調用config來做判斷是對的。效率上有很大影響是不可能的。你可能很少做效能測試。
這樣的效能最佳化，在效能測試的報告裡完全不可見，你這個最佳化相當於一個人為了減肥，而把鼻毛給剪了，不能說你沒效果，但是確實沒有意義，不值得為此付出的代價設計模式更重要
設計模式是經驗的總結
很多時候必然會走向設計模式
如果它不好只能說明你沒理解用錯了地方

而效能問題很多時候是想象的產物
脫離了實際情境出來的效能是無意義的

而且樓主的問題看來就是想當然的提前最佳化

按設計模式搭建出來的系統
大家都有能力去看懂去最佳化效能
按提前最佳化局部效能搭建出來的系統
連自己到後來都不想碰code效率優先，運行效率在99%的環境下不是問題。可讀性，可維護性一般優先度在運行效率之前。真有比較嚴重問題才去針對特定的1%到10%部分進行最佳化

