剛才看到文章這個看法很有同感，以前也沒有深刻理解到可維護性的重要性。在現在的公司呆了一年半，才明白。因為現在的公司使用者量大，團隊開發人員多，遇到很多難以維護的程式碼，花費人員溝通成本，延緩功能的開發進度，去填補遇到的坑.....

http://www.cnblogs.com/freeflying/p/4788494.html

一、效能不是不重要，而是他沒有可維護性重要。要理解這一點，首先要理解可維護性的重要（請再讀上一篇我花數週找bug的段子）；然後要明白：解決效能問題，我們可以有很多程式碼以外行之有效的方法，而可維護性基本上就只能靠程式碼了；最後，還是要牢記：沒有犧牲，就沒有勝利！

二、所以，在絕大多數情況下，當效能和可維護性相沖突的時候，效能讓位於可維護性。我們採用其他辦法來彌補程式碼效能不夠高的問題。



優化首先需要找到效能“瓶頸”。否則，任何人都可以隨手一指，“這段程式碼需要優化”。
可讀性更強的程式碼總是更好優化
硬體永遠比軟體便宜(即硬體比技術人員便宜,看系統規模而定)

合理浪費堆硬體

說了這麼多，不知道有沒有引起同學們的反思。可能大家還是過不去心裡那道坎：明明有一種效能更高的方法我們為什麼不用？

因為浪費唄！

什麼？你有沒有搞錯？我的程式碼，至少省了一塊記憶體條！那是你還沒從“窮學生”的角色裡轉換過來。你花一週的時間對程式碼進行了優化（就先不考慮你的優化帶來的維護成本增加了），為老闆省下了一塊記憶體條的錢。你以為老闆會拍著你的肩膀表揚你麼？老闆打不死你！

兄弟，賬不是你那樣算的。當你是學生的時候，你的時間成本是0；但你進入工作崗位，每一天都是要發工資的。

通過程式碼來調高效能，是一種無奈——對硬體效能不夠的妥協（參考：

明明window 10 比window 95更耗效能，為什麼今天沒人用window 95？為什麼VS 2013要10G的空間我們都還屁顛屁顛的趕緊裝上？為什麼現在大家都用C#，沒人用匯編？(注:彙編比高階語言效能強,接近機器)

我們站在人類文明積累的今天，就應該理所當然的享受這一切成 果。有打火機你不用，你要鑽木取火。如果你是因為要學貝爺荒野求生裝逼，可以理解；如果你說你是因為怕浪費天然氣，我……我……我怎麼說你呢？“給做打火 機的一條活路，行不？”同樣的，程式設計師大神同學，你就當做好事，給下面寫底層做硬體的一條活路吧！你的程式碼都是 010001000010000001010101……了，你讓其他人怎麼活啊？

最後，我突然想到的一個程式設計師為什麼對效能如此敏感瘋狂，對可維護性毫不在意的一個可能原因：

• 效能很好理解，卡得要死和跑得飛快；可維護性很不好理解，至少得跑個兩三年才能體現，那時候，誰知道爺在哪裡偷著樂呢
• 效能上不來，程式設計師只有羞愧的低著頭，都是我的錯；需求有變更，開口就罵，“哪個SB又要改……”；

大家覺得是不是這樣的？所以，願意把程式碼百鍊成鋼繞指柔的人少。想來，是一種莫名的悲哀和淒涼。

 某網友說：

 感覺效能問題屬於眼前問題，可維護性問題屬於以後的問題。很多人就是感覺先把眼前自己的事兒處理完就行，程式只要能執行，老闆滿意就萬事大吉，至於以後維護愛誰誰吧，那個時候老子已經另謀高就了，爛攤子留給後面的倒黴蛋吧。

這段話的確說出了目前的現狀，被逼的，上面只看功能完成與否，功能完成的質量不管。那還關係程式碼的可維護性幹嘛。於是把程式碼複製，拷貝函式，只要能跑起來就好了。

效能、可維護性從來都是要折中，過分從程式碼中追求效能會增大開發成本、降低可維護性。
現實中老闆、客戶真不在意那點硬體成本。只要專案快點上線。二期三期四期優化都好說。

張口閉口 談效能的 經理 我之前在北京 也見過 幾個。

最後 用幾個 實際的專案，堵住了他的嘴

—— 別跟我談效能，即使我用濫反射，效能也比你的快。

 同意,除了核心功能和高併發的頁面,一直以來寫程式碼的風格,首先就是可讀性,可維護, 然後再是效能。

 我的思考：

效能問題：關鍵是找到效能的瓶頸點。而不是糾結於細微的。也就是主要矛盾。把主要矛盾解決掉後，就好多了

就拿php來說，是解釋性語言，解釋性語言是比不上編譯型語言快。但是在web應用中，不涉及到複雜的cpu計算(簡單的增刪查改資料庫,不是分詞這麼複雜的演算法,這種屬於cpu密集型)，瓶頸在磁碟讀寫(磁碟i/0)和資料庫上。

所以看不出php的劣勢出來。當達到facebook這樣的應用，他們就會感到一點點php優化，對整個成本的減低，省去很多伺服器。

所以有規模，就是規模成本。經濟學中有個規模效益。通俗例子理解，生產100個要這麼多成本，生產1000也是差不多的成本，但是可以得到更多利潤。所以只能把規模擴大，才能賺到錢。

你達不到那個規模的時候，去談優化效能，帶來的是得不償失的。

而且，就算是解決效能問題，關鍵是找到瓶頸在哪裡，解決了瓶頸，就會帶來質的變化。而不是糾結於細節優化。主次矛盾要分清楚。

單純說效能，那直接用匯編寫程式碼，發明高階語言幹嘛，組合語言更加接近機器二進位制，所以效能更強。但是組合語言不容易維護，因為難懂，難上手。不接近人類的思維習慣。

記得國外有本書中提到一個觀點：程式碼是寫給人(物件是程式設計師)看的，不是寫給機器看的，如果是寫給機器看的，那麼，直接使用二進位制01011這樣的方式去寫程式碼呢，機器識別就是二進位制。而且，效能更強，不用經過中間轉換，是不是。