一、 目錄結構清楚，不宜過深，複雜，路徑最好用相對地址
二、 命名適當
三、 常變內容、界面使模板較好
四、 共公信息統一存儲
五、 Include文件不可嵌入較多
六、 目錄下不可存儲太多內容文件
七、 數據結構要設計合理
八、 數據校驗應在服務器端
九、 連接數據庫近晚，斷開連接近早
十、 儘量少使用SESSION與COOKIE
詳細說明：
(一) 目錄結構清楚，不宜過深，複雜，路徑最好用相對地址
a) 什麼樣的目錄放什麼樣的內容，這樣便於管理，使WEB程序的目錄結構，清楚明瞭，一看便知道某個文件夾下存儲了哪些功能模塊與內容。若隨便存放，時間一長久自己都將不從瞭解某目錄是用來做什麼的。如：經常要使用的可執行文件最要存放在（項目根目錄）根目錄，這樣做主要是便於瞭解其作用，同時也爲在程序中少輸入些地址字符。程序所用到的圖片統一存放在根目錄下images目錄中，若項目較大，分枝較多，可再在其目錄下建立也分枝程序相關的目錄名，存儲相關的圖片內容。程序的配置文件與常用共公函數類庫存放在include目錄中，存放在此目錄下的函數類庫文件擴展名得命名爲：.php切不命名爲.inc .ini之類爲擴展名的文件，主要是防此此類文件可供用戶下載，或查閱其源碼內容，這樣對其調用方便明確。模板文件應存儲在根目錄下templates目錄中，擴展名爲.html，如果項目較大，分類較多，模板文件可分類存放在下極目錄中。臨時文件存儲在根目錄tmp目錄中，此目錄通常設置爲任何人都可讀可寫。使用相對地址主要是方便程序移植。
(二) 命名適當
a) 命名最好是以程序用來作什麼用來命名。若一個單詞就要描述則用小寫單詞來命名，若要用多個單詞方能代表，也以小寫單詞之間加下劃線連接。要注意命名不可過長，這樣就不方便了，雖然能表達的更明確，但打字難打啊。程序中函數命名也可與此相同。不好之上也有，那就是每次命名都得要花時間去想個較合適的名字，由其是對於是我們這種英文水評較差的人來說可不是一件容易的事啊。（慘啊，哈哈！）
(三) 常變內容、界面使模板較好
a) 常變內容、界面使用模板較好，這是因爲當我某天感覺某不頁面不美觀時尚時，我想更換較新較好的界面，這時就用得上了。如果是按照傳統的製作將HTML頁面內容放在程序中處理輸入時，較麻煩非得要更改程序不可，這可能會帶來較大的不便萬一更改出錯，這就不太好了。（程序有很長一段時沒有維護了，突然要改，一時之間是難免不發生改錯的情況發生）。若是使用了模板則不用改程序，只要更改一下模板文件就行了。好了說了這麼我模板的好處，好像傳統的做法沒有一點好處是的，好像分文不值是的，也不是，模板也有它不好的地方，現在我也來說說它是怎麼個不好的。傳統做法是把HTML代碼嵌入在WEB程序中，這樣做的好處是，執行速度要比使用模板的要快，這是因爲它不用經過任何處理就能直接輸出，而模板就不一樣啦。模板先要打開讀取模板文件到字符串變量可數組字符串變量中，這是要時間的吧？讀處完了之後還得花時間用字符串操作函數替換模板中模板變量吧？替換完成了方能進入輸出。傳統做法與使用模板作法，您覺得哪個好呢？（我個人認爲如果是開發訪問量相當大的網站，選擇傳統的作法是一個不錯的選擇，我所說的是相對不是絕對，如果訪問量再大那就不能用腳本語言去寫了，那得用CGI + Socket + Demon了。不說了，說遠了，哈哈）
(四) 共公信息統一存儲
a) 共公信息統一存儲，這主要爲了方便團隊開發時都能進行調用用的最常的函數，不用每個開發人員都複製一份或自己寫一份存儲在程序文件中，這樣做浪費空間同時效率效果也不好。
(五) Include文件不可嵌入較多
a) Include文件不可嵌入較多，這是因爲每次程序include某個文件時，是要打開讀取這個文件的，這是要時間的哦，再就是說處理路徑時可能會遇到較難發現的BUG問題。
(六) 目錄下不可存儲太多內容文件
a) 目錄下不可存儲太多內容文件，你有沒有發現？每當你進入windows的system32文件夾時通常打開的時間要比打開其它文件夾時要長久點呢？這主要是因爲system32這個文件夾中文件較多，當你打開系統得花時間查找文件並顯示吧？如果文件較多較大時最好是分目錄分盤符來處理。假若您的機器夠好夠強勁的話，就當我沒說過，那就得另當別論了。
(七) 數據結構要設計合理
a) 數據結構要設計合理，如果數據結構設計不合理的話，不管你的程序寫的多精典，寫得我容易，也不是不能發揮其最大作用與價值的。這就相當於一個女人的胸部最大最豐滿，但人不夠高，而且又黑，身體又不好，身架又殘疾，你會說她美麗完美嗎？程序也一樣，有些代碼沉長又不起作用，存在也沒有什麼用。數據結構要精簡明瞭。
(八) 數據校驗應在服務器端
a) 數據校驗應在服務器端，這是因爲就算是他人不從我們的頁面輸入數據，自己做了個鏈接地址(GET)或自己做了個表單用POST方式傳送數據，我們的程序也將進入覈對查驗。若是放在客戶端，他人就能用以上方法逃過審覈了。但這樣做也有他不好之處，那就是當數據量大時，服務器會負載運行，審覈數據完整性是可開銷時間與系統資源的。在客戶端就不會佔用服務器太多的資源，因爲他佔用的是用戶的資源。
(九) 連接數據庫近晚，斷開連接近早
a) 連接數據庫近晚，斷開連接近早，這主要是因爲連接數據是要時間的吧？連接上了不即時使用也要佔用系統資源吧？連接數據庫連接數量是有限制的吧？所以得盡晚連接，儘早斷開連接，這個做能使佔用系統資源最少，爲下一次連接提供條件。
(十) 儘量少使用SESSION與COOKIE
a) 儘量少使用SESSION與COOKIE，因爲使用SESSION是要佔用系統資源的，SESSION是存儲在服務器端的，每次讀取SESSION中的數據是要較大開銷的。COOKIE雖然不佔用服務器資源，但COOKIE不太安全。
OK，就說到此吧。此文純屬個人看法，不符之處請多多指導，諒解！
作者：張樹林
2005-4-27
本文鏈接：
http://www.openphp.cn/index.php/article/2/182/index.html