- 代码的格式,选择 Laravel 风格
- 代码提交前一定要经过格式化 + 优化导入
-
短函数,单个函数不超过 80 行(重要),最好 40 行以内,一个函数实现一个功能,有明确的输入输出
-
函数命名必须有意义,尽最大可能使用动宾结构,加上必要的函数注释
-
常量:所有字母必须大写,词间以下划线分隔,比如:API_VERSION
-
属性,小驼峰,比如 $adminUser
-
类函数:小驼峰,如 getUser
-
不允许使用拼音命名,除非专有名词,比如人民币单位:yuan
-
尽可能使用已有的开源组件(正在维护的、活跃的、稳定的),不要重复造轮子
-
路由规范:保留原项目的规范,使用具体的接口语义,只使用 GET 和 POST,查询接口用 GET,写入接口用 POST
-
异常情况需要记录错误日志,以方便排查(尤其是第三方返回的接口,如支付回调)
-
响应格式规范化
Content-Type: application/json;charset=UTF-8 { body }
body 的 json 内容:
- 正常情况
{ "errno": xxx, "errmsg": xxx, "data": {} }
2.失败异常情况
{ errno: xxx, errmsg: xxx }
- 表名、字段名全使用蛇形命名,见名知意
- 表设计默认情况存在 id(主键),created_at(创建时间),updated_at(更新时间),deleted_at(软删除)四个字段
- 不使用存储过程、视图、触发器、Event
数据库最擅长的是数据持久化(存储数据),并不擅长做计算,因此要把计算放到程序中去实现,数据库制作自己最擅长的事情
- 禁止使用外键,如果有外键完整性约束,需要程序自行控制
外键会导致表与表之间的耦合,影响 SQL 性能,所以互联网项目一般不推荐使用外键
- 禁止使用 ENUM,可使用 TINYINT 代替之
使用枚举时,若想新增一个枚举,需要执行一个 DDL(表结构修改)的操作,数据量大的情况下可能会锁表,影响线上业务运行
- 数据库相关操作一定不能使用原生 SQL,要使用查询构造器进行语句的构建
原生 SQL 不容易管理,会对维护、重构造成很大的障碍