圖文并茂PHP跟老大的對話
思維導圖
介紹
叫老大不光是因為職位比我高，還因為技術也讓人佩服！
今天跟老大聊聊我們一些代碼結構的問題，有些可能會對你是有幫助的。如果大家有不同的看法，可以提出來，一起討論一下。
對話
1>單個文件巨大（超過5000行）
我:文件大會不會影響性能??？PHP語言在處理源文件的時候(這個主要是php的詞法分析和語法分析)，會將源文件切分為一個一個的標記(token)。如果文件很大的話，把我們當前不需要的方法都會做標記的，這樣不是明顯影響性能嗎？
老大:這個在性能方面的影響是比較小的。我們在考慮性能的時候，要考慮全局觀，比如展示頁面的時候，打開頁面很慢，那我們首先考慮的就不是文件大小的問題，而是每個模塊的加載速度。比如，通過你的斷點設置，你發現某個產品列表的讀取是比較慢的，那就要考慮，是不是組裝數據慢了，還是從接口(數據庫或者中間層）讀數據慢了？如果是組裝數據慢了，那就要重構這個算法，或者跟產品人員商量能否修改方案。如果是接口讀取數據慢了，那是不是需要加機器或者加索引來解決問題。——所以，考慮性能問題，不能抓住小問題，要考慮的是最影響性能的地方進行修改。
我:那如果切分大文件類到不同的類有什么不好嗎？
老大:如果在一個方法體中，你通過很多的require_once添加很多的類文件，那么不也是影響性能嗎?——require_once本身也耗費性能！
給我畫了一張圖(類似于上面的圖):
我:那我可以用include，邏輯加載文件，按條件加載文件。這樣就能減少加載文件的數目！
老大:那么你怎么按照條件加載？
我:比如，我可以按照分類去加載文件，電影的時候，我就把電影相關的程序文件加載進來，電視的時候就把電視相關的程序文件加載進來。
老大:那將來電視要用到電影里的內容的時候，你怎么辦？或者很多分類用到你電影分類里的內容的時候你怎么辦？
我:那我就放置一堆的"||"代碼(如if('電影' === $category || '電視' === $category || '音樂' === $category){})。 后來我琢磨了一下，確實是，這樣做的話，一個方法里會有很多這種if語句，那我要對應某一個分類內容的時候，我就要看一堆的if了。還真不如寫在一塊呢或者重構代碼了！
#p#
2>autoload()方法。
類似下面的代碼。
- <?php
- Test::getName();
- function __autoload($className){
- echo $className,"\n";exit();
- }
運行結果:
我們都知道__autoload()方法性能并不是很好，一般不鼓勵去使用這個方法。所以，我在調用類的時候，我就加了這么一句:
對話:
我:我覺得__autoload方法性能不是很好，所以我在調用別的模塊的時候，我就用了include方法。
老大:你這樣做，一是整個代碼看起來沒那么規范，二是，如果將來要修改框架了，我們就要查看所有的這樣的代碼文件，因為比如，你的入口文件移動到別的文件夾下面，那么你的Test.class.php文件在什么位置，你知道嗎？
如果我們調用__autoload()方法，我們只需要修改這個接口就可以了，因為所有的類調用都經過了這個方法，這樣比較好管理。
#p#
3> 一個方法盡量保持在一個屏幕內,一行不超過80個字符。
我:我覺得我們的類里面的方法太長了，很多都超過幾個屏幕，才能把當前的方法看完。我個人比較推崇"盡量把方法放在一個屏幕內"和"讓一個方法做一件事"。有的時候看到一個很長的方法的時候頭大了！
老大:
一個方法就是做一件事啊，比如test()方法，就做test（）。以前php沒有面向對象的時候，我們經常不是把代碼都寫在一個文件里嗎？
我們不應該“為了拆方法，而把方法硬性拆分。而應該是因為業務需要而對方法拆分!”。而且函數調用我們知道，本身也是耗費性能和內存的。如果你這個方法體內的有些部分，其他方法也要調用，那么這時候你可以把這部分代碼做成一個方法。如果你的方法里有很多調用其他類里的方法，不也看著很麻煩嗎？還不如寫到一個方法里呢！這樣還比較直觀些。
#p#
4> 找回以前刪除的代碼。
我:如果某個功能產品要求撤下來，但是過了很長一段時間，產品又要求再上這個功能。那么我原來的代碼是刪除呢？還是只做注釋呢！
老大:刪除掉！
我：那我怎么恢復呢？要把原來代碼做備份嗎？
老大：你可以使用版本管理軟件做恢復。如svn。
例子演示:
(1)最初代碼
svn提交代碼:
(2)產品要求下線代碼
svn提交代碼:
(3)隔了一段時間，產品又要求重新上線該模塊。
svn操作:先查詢日志，然后針對日志進行合并
總結
上面的問題，我估計你也遇到過，所以大家共勉下吧！
題外話:曾經我在離開一家工作一年的公司的時候！項目經理就跟我說你如果頻繁跳槽，會對你的將來的發展是不利的，但是沒有告訴我怎么不利？現在我有點明白了，因為我到過的公司很多技術過硬的人，都是在這個公司帶過3年以上的人。我發現如果你在一家公司待很長時間，對你的技術提升是很有幫助的。
1》 不停的重構代碼，提升你的代碼質量。
我們開始進入公司的時候，一般都是公司急需趕個項目人手缺乏。等項目完成，一般都是1年左右。如果你在公司待足夠長的時間，這個項目多多少少會跟你扯上邊的，這時候，你會不停的翻看自己的代碼，你也會不斷的調整代碼， 不斷的重構你的代碼——跟寫文章一眼，你不停的看自己寫過的文章，你會不停的做修改，越修改你的文章會越讓你喜歡。
2》業務熟悉，能夠更快更好的寫出代碼！——我個人比較喜歡“行云流水”似的感覺。
你如果在一個公司待了很長一段時間，那么你對這個領域是非常熟悉的。新需求上來，你會很快的知道怎么做代碼架構，比如上面提到的，你就知道方法中，哪些代碼部分可以抽出來，獨立做成一個方法;你也會知道，將來什么地方會頻繁修改的。——寫代碼，如行云流水般！
原文鏈接：http://www.cnblogs.com/baochuan/archive/2012/03/21/2409023.html
【編輯推薦】
