代码可靠性
首先体现在代码的严谨性上，在一些弱类型的语言中，使用变量是可以不事先进行声明的，甚至直接使用也是不会报错的。这就使得开发者养成了不好的习惯。
正常情况下，php程序员不会犯下为声明就使用的错误，但是在数组的声明中就有可能。为了避免声明太多的变量，同时方便对数据通过循环处理，写程序时，将数据赋值给数组。代码在起初的业务逻辑中能够正常使用，但以后业务逻辑发生变化，比如从数据库中读出非你想要的数据，就可能引起程序报错。或者日后因为添加if语句，导致数据异常。这样的程序严重依赖数据的完整性，就失去了代码的可靠性。
可靠性代码简单归纳：
1、变量特别是数组，进行初始化赋值。
2、代码不依赖数据的完整性，或者对数据的完整性进行验证。
3、从框架层代码开始，兼容网络等异常情况处理。
数据库扩展性
数据库设计基本上就决定了php代码，但是数据库的可扩展性，并不代表就是php代码的可扩展性。
比如：完成一个审批流程的表设计，当前的需求，可能是每个环节只需要设计成一个人进行审批。然后数据库对一个审批事件，就只创建一条审批记录，当审批流转到下一个人时，是通过直接修改这条记录的审批人信息。
这样的数据库设计，就决定了可扩展很差。如果要加入多人审批，和查看历史审批记录。那么就需要重新设计数据库，现有的程序也没法用了。更加可怕的是，因为旧数据无法满足当前的需求，新程序还要加入多种逻辑判断，去兼容旧数据。
代码扩展性
在可预期的未来，业务上的需求可能较为复杂。但如果目前就做这些需求的话，那么开发周期将会非常的长，这明显不符合软件快速迭代的需求。
那么我们是否在php设计模式上和数据库设计上留有扩展空间。
比如现在公司想做一个儿童书籍的电商平台，但是可预期的未来，公司会做儿童玩具，儿童衣服等产品。同时你需要满足差异化的需求和统计分析需求。
在收到这样的需求时，你当然可以想到，建立一张儿童商品表，添加一个分类的字段，然后根据日后添加的不同商品，添加部分特殊需要的字段。
但这是否在一开始就注定数据库会不断的冗余，代码会不断的耦合，每开发一个新的产品分类，可能就需要修改原有的代码，加上各种if语句呢？
所有商品的主要信息记录在同一张表里面，然后不同类型的商品特殊信息记录在不同的商品里面。这样在数据库设计时，就不会因为添加的新类型的商品，而修改原有的数据库表结构了。
在php程序上就可以使用工厂模式，先定义公共模块，再定义不同分类完成个性化定制。这样可以减少修改原有代码
