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