代碼可靠性

首先體現(xiàn)在代碼的嚴謹性上，在一些弱類型的語言中，使用變量是可以不事先進行聲明的，甚至直接使用也是不會報錯的。這就使得開發(fā)者養(yǎng)成了不好的習慣。

正常情況下，php程序員不會犯下為聲明就使用的錯誤，但是在數(shù)組的聲明中就有可能。為了避免聲明太多的變量，同時方便對數(shù)據(jù)通過循環(huán)處理，寫程序時，將數(shù)據(jù)賦值給數(shù)組。代碼在起初的業(yè)務邏輯中能夠正常使用，但以后業(yè)務邏輯發(fā)生變化，比如從數(shù)據(jù)庫中讀出非你想要的數(shù)據(jù)，就可能引起程序報錯。或者日后因為添加if語句，導致數(shù)據(jù)異常。這樣的程序嚴重依賴數(shù)據(jù)的完整性，就失去了代碼的可靠性。

可靠性代碼簡單歸納：

??? 1、變量特別是數(shù)組，進行初始化賦值。

??? 2、代碼不依賴數(shù)據(jù)的完整性，或者對數(shù)據(jù)的完整性進行驗證。

??? 3、從框架層代碼開始，兼容網(wǎng)絡等異常情況處理。

數(shù)據(jù)庫擴展性

數(shù)據(jù)庫設(shè)計基本上就決定了php代碼，但是數(shù)據(jù)庫的可擴展性，并不代表就是php代碼的可擴展性。

比如：完成一個審批流程的表設(shè)計，當前的需求，可能是每個環(huán)節(jié)只需要設(shè)計成一個人進行審批。然后數(shù)據(jù)庫對一個審批事件，就只創(chuàng)建一條審批記錄，當審批流轉(zhuǎn)到下一個人時，是通過直接修改這條記錄的審批人信息。

這樣的數(shù)據(jù)庫設(shè)計，就決定了可擴展很差。如果要加入多人審批，和查看歷史審批記錄。那么就需要重新設(shè)計數(shù)據(jù)庫，現(xiàn)有的程序也沒法用了。更加可怕的是，因為舊數(shù)據(jù)無法滿足當前的需求，新程序還要加入多種邏輯判斷，去兼容舊數(shù)據(jù)。

代碼擴展性

在可預期的未來，業(yè)務上的需求可能較為復雜。但如果目前就做這些需求的話，那么開發(fā)周期將會非常的長，這明顯不符合軟件快速迭代的需求。

那么我們是否在php設(shè)計模式上和數(shù)據(jù)庫設(shè)計上留有擴展空間。

比如現(xiàn)在公司想做一個兒童書籍的電商平臺，但是可預期的未來，公司會做兒童玩具，兒童衣服等產(chǎn)品。同時你需要滿足差異化的需求和統(tǒng)計分析需求。

在收到這樣的需求時，你當然可以想到，建立一張兒童商品表，添加一個分類的字段，然后根據(jù)日后添加的不同商品，添加部分特殊需要的字段。

但這是否在一開始就注定數(shù)據(jù)庫會不斷的冗余，代碼會不斷的耦合，每開發(fā)一個新的產(chǎn)品分類，可能就需要修改原有的代碼，加上各種if語句呢？

所有商品的主要信息記錄在同一張表里面，然后不同類型的商品特殊信息記錄在不同的商品里面。這樣在數(shù)據(jù)庫設(shè)計時，就不會因為添加的新類型的商品，而修改原有的數(shù)據(jù)庫表結(jié)構(gòu)了。

在php程序上就可以使用工廠模式，先定義公共模塊，再定義不同分類完成個性化定制。這樣可以減少修改原有代碼