PHP 跟老大的對話

 思維導圖 

  介紹        叫老大不光是因為職位比我高，還因為技術也讓人佩服！       今天跟老大聊聊我們一些代碼結構的問題，有些可能會對你是有協助的。如果大家有不同的看法，可以提出來，一起討論一下。       對話 1>單個檔案巨大（超過5000行）我:檔案大會不會影響效能啊？PHP語言在處理源檔案的時候(這個主要是php的詞法分析和文法分析)，會將源檔案切分為一個一個的標記(token)。如果檔案很大的話，把我們當前不需要的方法都會做標記的，這樣不是明顯影響效能嗎？ 老大:這個在效能方面的影響是比較小的。我們在考慮效能的時候，要考慮全域觀，比如展示頁面的時候，開啟頁面很慢，那我們首先考慮的就不是檔案大小的問題，而是每個模組的載入速度。比如，通過你的斷點設定，你發現某個產品列表的讀取是比較慢的，那就要考慮，是不是組裝資料慢了，還是從介面(資料庫或者中介層）讀資料慢了？如果是組裝資料慢了，那就要重構這個演算法，或者跟產品人員商量能否修改方案。如果是介面讀取資料慢了，那是不是需要加機器或者加索引來解決問題。——所以，考慮效能問題，不能抓住小問題，要考慮的是最影響效能的地方進行修改。 我:那如果切分大檔案類到不同的類有什麼不好嗎？ 老大:如果在一個方法體中，你通過很多的require_once添加很多的類檔案，那麼不也是影響效能嗎?——require_once本身也耗費效能!  

                       給我畫了一張圖(類似於上面的圖): 我:那我可以用include，邏輯負載檔案，按條件負載檔案。這樣就能減少負載檔案的數目！ 老大:那麼你怎麼按照條件載入？ 我:比如，我可以按照分類去負載檔案，電影的時候，我就把電影相關的程式檔案載入進來，電視的時候就把電視相關的程式檔案載入進來。 老大:那將來電視要用到電影裡的內容的時候，你怎麼辦？或者很多分類用到你電影分類裡的內容的時候你怎麼辦？ 我:那我就放置一堆的"||"代碼(如if('電影' === $category || '電視' === $category || '音樂' === $category){})。 後來我琢磨了一下，確實是，這樣做的話，一個方法裡會有很多這種if語句，那我要對應某一個分類內容的時候，我就要看一堆的if了。還真不如寫在一塊呢或者重構代碼了！  2>autoload()方法。類似下面的代碼。 

<?phpTest::getName();function __autoload($className){    echo $className,"\n";exit();}

運行結果:

 我們都知道__autoload()方法效能並不是很好，一般不鼓勵去使用這個方法。所以，我在調用類的時候，我就加了這麼一句:

對話:我:我覺得__autoload方法效能不是很好，所以我在調用別的模組的時候，我就用了include方法。 老大:你這樣做，一是整個代碼看起來沒那麼規範，二是，如果將來要修改架構了，我們就要查看所有的這樣的代碼檔案，因為比如，你的入口檔案移動到別的檔案夾下面，那麼你的Test.class.php檔案在什麼位置，你知道嗎？        如果我們調用__autoload()方法，我們只需要修改這個介面就可以了，因為所有的類調用都經過了這個方法，這樣比較好管理。 3> 一個方法盡量保持在一個螢幕內,一行不超過80個字元。 

我:我覺得我們的類裡面的方法太長了，很多都超過幾個螢幕，才能把當前的方法看完。我個人比較推崇"盡量把方法放在一個螢幕內"和"讓一個方法做一件事"。有的時候看到一個很長的方法的時候頭大了！ 老大:        一個方法就是做一件事啊，比如test()方法，就做test（）。以前php沒有物件導向的時候，我們經常不是把代碼都寫在一個檔案裡嗎？       我們不應該“ 為了拆方法，而把方法硬性拆分。而應該是因為業務需要而對方法拆分!”。而且函數調用我們知道，本身也是耗費效能和記憶體的。如果你這個方法體內的有些部分，其他方法也要調用，那麼這時候你可以把這部分代碼做成一個方法。       如果你的方法裡有很多調用其他類裡的方法，不也看著很麻煩嗎？還不如寫到一個方法裡呢！這樣還比較直觀些。 4> 找回以前刪除的代碼。我:如果某個功能產品要求撤下來，但是過了很長一段時間，產品又要求再上這個功能。那麼我原來的代碼是刪除呢？還是只做注釋呢！老大:刪除掉！我：那我怎麼恢複呢？要把原來代碼做備份嗎？老大：你可以使用版本管理軟體做恢複。如svn。 例子示範:(1)最初代碼

svn提交代碼:

 (2)產品要求下線代碼

svn提交代碼:

(3)隔了一段時間，產品又要求重新上線該模組。

svn操作:先查詢日誌，然後針對日誌進行合并

 

 

 總結 上面的問題，我估計你也遇到過，所以大家共勉下吧！ 題外話:曾經我在離開一家工作一年的公司的時候！專案經理就跟我說你如果頻繁跳槽，會對你的將來的發展是不利的，但是沒有告訴我怎麼不利？現在我有點明白了，因為我到過的公司很多技術過硬的人，都是在這個公司帶過3年以上的人。我發現如果你在一家公司待很長時間，對你的技術提升是很有協助的。1》 不停的重構代碼，提升你的代碼品質。我們開始進入公司的時候，一般都是公司急需趕個項目人手缺乏。等項目完成，一般都是1年左右。如果你在公司待足夠長的時間，這個項目多多少少會跟你扯上邊的，這時候，你會不停的翻看自己的代碼，你也會不斷的調整代碼， 不斷的重構你的代碼——跟寫文章一眼，你不停的看自己寫過的文章，你會不停的做修改，越修改你的文章會越讓你喜歡。2》業務熟悉，能夠更快更好的寫出代碼！——我個人比較喜歡“行雲流水”似的感覺。你如果在一個公司待了很長一段時間，那麼你對這個領域是非常熟悉的。新需求上來，你會很快的知道怎麼做代碼架構，比如上面提到的，你就知道方法中，哪些代碼部分可以抽出來，獨立做成一個方法;你也會知道，將來什麼地方會頻繁修改的。——寫代碼，如行雲流水般！  附件:跟老大對話    網友對話 跟大家交流收穫很多，也感謝大家多提意見，我們共同探討。  youxiachai:不用注釋來注釋那些可能有用的代碼.....最近,看代碼整潔之道,也提到了一樣的問題? 我:這書我也看過，跟以前同事聊過，但是他們都比較推崇盡量寫注釋。我也懶得寫注釋————呵呵。  如果我們的代碼規範大家都比較認可的話，那麼我們可以省略掉很多注釋。 如:listVideo我們都知道這是擷取視頻列表的。 ——————後來我發現，我看的是《代碼大全》，誤會了！ msnweb：都是挺初級的問題， 有一點 不同意 require_once 影響效能。.... 和db socket io 這種效能影響根本不用考慮。
還有一點 就是單元測試。 這對你的水平提高會很大。我：對，我這個都是初級的問題，但是很多初級的問題，往往是我們工作很多年都容易忽略的地方。有的時候，看代碼的時候老是覺得不舒服，但是說不出來，哪裡不舒服。
我:單元測試我這裡是比較頭疼的問題，因為現在的代碼架構已經有很多年歷史了，裡面有很多的比如rewrite,alias，甚至還有把變數放到apache的設定檔的，然後通過php去讀取。

maxspeed40k:autoload影響效能是網路上最大的謬論之一。
多個小檔案塊還是單個大檔案塊，可以在沒有opcode緩衝和有opcode緩衝下做個效能測試，你會發現不一樣的答案，另外，單個大檔案同時編輯方便嗎?載入以及依賴的問題是用autoload不正好是解決這個問題的？我：這個真沒做過實驗，哪天時間允許，我做個實驗試試。
maxspeed40k：一
行80個字元少了一點，以前代碼要列印，印表機品質不高，所以限制為80，現在完全可以達到120。一個方法的代碼如果超過一螢幕，是應該考慮重構，如何
寫得更加簡潔，將一些代碼東西提煉出提高複用，通過方法名讓代碼更容易立即，更多好處可以參考《代碼大全》相關章節，有非常好的介紹。我們看下
cake,yii,discuz...我:同意他的觀點。
如果方法中的代碼很多沒有複用價值，你還重構嗎？我一般的做法是把那些經常需要變化的和其他方法調用的公用代碼剝離出來做成一個方法。

大家還有什麼寶貴意見都可以進行交流。