性能，不是不重要,而是，它沒有可維護性重要

 

 

剛纔看到文章這個見解頗有同感，之前也沒有深入理解到可維護性的重要性。在如今的公司呆了一年半，才明白。由於如今的公司用戶量大，團隊開發人員多，遇到不少難以維護的代碼，花費人員溝通成本，延緩功能的開發進度，去填補遇到的坑.....

 

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

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

2、因此，在絕大多數狀況下，當性能和可維護性相沖突的時候，性能讓位於可維護性。咱們採用其餘辦法來彌補代碼性能不夠高的問題。



優化首先須要找到性能「瓶頸」。不然，任何人均可以隨手一指，「這段代碼須要優化」。
可讀性更強的代碼老是更好優化
硬件永遠比軟件便宜(即硬件比技術人員便宜,看系統規模而定)

 

 

 

 

 

合理浪費堆硬件

 

說了這麼多，不知道有沒有引發同窗們的反思。可能你們仍是過不去內心那道坎：明明有一種性能更高的方法咱們爲何不用？

 

由於浪費唄！

 

什麼？你有沒有搞錯？個人代碼，至少省了一塊內存條！那是你還沒從「窮學生」的角色裏轉換過來。你花一週的時間對代碼進行了優化（就先不考慮你的優化帶來的維護成本增長了），爲老闆省下了一塊內存條的錢。你覺得老闆會拍着你的肩膀表揚你麼？老闆打不死你！

 

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

 

經過代碼來調高性能，是一種無奈——對硬件性能不夠的妥協（參考：80年代遊戲開發者的辛苦困境。這樣寫性能就高，但爲何如今沒有誰再這麼寫代碼了？）。不然，絕大多數狀況下，堆硬件比優化代碼的效果好得多，並且便宜得多。硬件的成本按摩爾定律往降低，咱們程序員的工資也能按摩爾定律減麼？（注：硬件愈來愈便宜,而人員工資愈來愈增長,就拿工廠的普通工人用工成本也在增長）

 

 

 

 

明明window 10 比window 95更耗性能，爲何今天沒人用window 95？爲何VS 2013要10G的空間咱們都還屁顛屁顛的趕忙裝上？爲何如今你們都用C#，沒人用匯編？(注:彙編比高級語言性能強,接近機器)

 

 

 

咱們站在人類文明積累的今天，就應該理所固然的享受這一切成 果。有打火機你不用，你要鑽木取火。若是你是由於要學貝爺荒野求生裝逼，能夠理解；若是你說你是由於怕浪費自然氣，我……我……我怎麼說你呢？「給作打火 機的一條活路，行不？」一樣的，程序員大神同窗，你就當作好事，給下面寫底層作硬件的一條活路吧！你的代碼都是 010001000010000001010101……了，你讓其餘人怎麼活啊？

 

最後，我忽然想到的一個程序員爲何對性能如此敏感瘋狂，對可維護性絕不在乎的一個可能緣由：

• 性能很好理解，卡得要死和跑得飛快；可維護性很很差理解，至少得跑個兩三年才能體現，那時候，誰知道爺在哪裏偷着樂呢
• 性能上不來，程序員只有羞愧的低着頭，都是個人錯；需求有變動，開口就罵，「哪一個SB又要改……」；

你們以爲是否是這樣的？因此，願意把代碼百鍊成鋼繞指柔的人少。想來，是一種莫名的悲哀和淒涼。

 

 

 某網友說：

 

 感受性能問題屬於眼前問題，可維護性問題屬於之後的問題。不少人就是感受先把眼前本身的事兒處理完就行，程序只要能運行，老闆滿意就萬事大吉，至於之後維護愛誰誰吧，那個時候老子已經另謀高就了，爛攤子留給後面的倒黴蛋吧。

 

這段話的確說出了目前的現狀，被逼的，上面只看功能完成與否，功能完成的質量無論。那還關係代碼的可維護性幹嗎。因而把代碼複製，拷貝函數，只要能跑起來就行了。

 

性能、可維護性歷來都是要折中，過度從代碼中追求性能會增大開發成本、下降可維護性。
現實中老闆、客戶真不在乎那點硬件成本。只要項目快點上線。二期三期四期優化都好說。

 

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

最後 用幾個 實際的項目，堵住了他的嘴

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

 

 贊成,除了核心功能和高併發的頁面,一直以來寫代碼的風格,首先就是可讀性,可維護, 而後再是性能。

 

 

 個人思考：

 

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

 

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

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

 

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

 

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

 

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

 

單純說性能，那直接用匯編寫代碼，發明高級語言幹嗎，彙編語言更加接近機器二進制，因此性能更強。可是彙編語言不容易維護，由於難懂，難上手。不接近人類的思惟習慣。

記得國外有本書中提到一個觀點：代碼是寫給人(對象是程序員)看的，不是寫給機器看的，若是是寫給機器看的，那麼，直接使用二進制01011這樣的方式去寫代碼呢，機器識別就是二進制。並且，性能更強，不用通過中間轉換，是否是。