性能永遠不是優先考慮的問題

我從來不會一開始就考慮性能問題。如果項目成本很低，甚至到項目結束時，如果沒有感覺到明顯的性能問題，也不會去管。要知道現在已經不是DOS的年代，CPU的計算能力很高，但成本很低了。重要一點是，如果隻針對提升性能對代碼做改動，很容易破壞代碼的複用性和可維護性。而返過來，提高了代碼的複用性和可維護性，則很容易提高性能。

下面有一個PHP的代碼執行個體，功能是幫助使用者重置密碼（代碼為了簡單說明問題，請不要太在意一些無關的細節）requestResetPassword是接收使用者重置密碼的請求并且做了相應的檢查。為了更好的複用性，我将重置密碼的操作單獨配置設定到一個新的resetPassword的函數，更改完密碼的後再調用sendEmail向使用者發送一封通知郵件。

　　現在問題是，這三個函數都同時使用checkUserExists這個函數來檢查使用者不存在，資料庫查詢了三次，這樣帶來了一些額外的開銷。

如果要去掉三者之間任意一個checkUserExists，看上去是可能的。但是如果之後有某些功能要調用resetPassword或者sendEmail，使用者不存在時，系統可能會發生錯誤。

還有一個解決方法是，将resetPassword的邏輯寫到requestResetPassword裡，再過一點，把sendEmail的邏輯也寫進去。這樣函數調用減少，資料庫查詢也變成一次了，性能得到了提高。但是重置密碼和發送郵件的功能将不能得到複用，并且違背了單一責任的原則，代碼複雜度也提高了。

不過，因為函數分離和複用性都很好，如果實際性能受到影響，可能考慮用緩存的方法減少資料庫查詢，我改動了它們共用的checkUserExists函數：

　　

也可以用同樣的方法改動getUserInfo函數。

這裡可以看到，當代碼的複用性提高時，想提高性能是很簡單的，性能的瓶頸也很容易被發現和修改。

盡管這個例子對性能影響還不夠大，還有一些影響更大的，比如說周遊，我可能為了複用而将周遊封裝到一個函數中，并且多次使用它。這些開銷對我的項目根本沒有預想中那樣有太大的影響，或者說是微乎其微的。是以我更願意把時間花在如何提高代碼的複用性和維護性方面，而不是糾結于浪費多這一點性能。實際性能如果真的達不到要求，也可以權衡增加硬體配置。

我是很同意文中觀點的，比如平時在項目中會經常使用foreach周遊list數組，數組長度一般不會超過幾十個，這樣隻是理論上對性能有影響，實際根本感覺不到。

我還是期待開發出有更多人使用的産品，那時再調整優化性能就顯得意義更大。用簡約的技術實作最大的效益。

程式員真的很高傲，在我接觸過的人中，包括我自己也是。我以前經常對一些簡單的代碼感到不屑，而總想在項目中寫一些犀利的代碼，讓人看起來很NB，但結果總是和想象差太遠，代碼總是寫的很差，邏輯也不夠清晰。歸根到底，是我帶着這樣的思想去寫代碼，而忽略了程式設計的根本：解決問題。現在我改掉了這個壞毛病，以解決問題為目的去程式設計，以簡單為主。出乎意料的是别人有時會對我說，這裡的代碼寫得很棒。

踏實的做事，會有意想不到的收獲。

<a href="http://blog.sae.sina.com.cn/archives/657">http://blog.sae.sina.com.cn/archives/657</a>

<a href="http://www.php.net/manual/zh/function.is-array.php">http://www.php.net/manual/zh/function.is-array.php</a>

<a href="http://cn2.php.net/manual/zh/function.exit.php">http://cn2.php.net/manual/zh/function.exit.php</a>