# 项目开发规范
## 编码规范
### 命名规范
- 普通变量名一律使用小驼峰,使用匈牙利命名法,私有变量以下划线开头, 常量需大写,建议变量名称使用英文全称,不简写,不使用拼音和缩写。
- 项目配置项一律使用`.env` 文件进行配置,不得写在代码内部,版本管理 提交一份`.env.example`样例,包含所有的该配置的配置项名称。配置项一律使用`config()`函数来读取
- 方法函数返回值类型统一,方法参数需指定参数数据类型,
- 方法内其他非正常逻辑内的提示一律使用异常抛出形式结束。
- 方法内部代码块变量需要定义才能使用,除了控制器之外方法必须写注释,模型需使用 `@property` 注释具体有哪些字段
- `if` 和 `for foreach` 等语句块不得超过三级嵌套
- 方法函数内部的代码根据逻辑功能区分,切换不同的逻辑使用空格分开,函数的行数不超过120行,行代码长度不超出换行提示线
- 不得直接使用sql语句,所有查询统一走Model,不得在Model之外操作数据库
## 目录和架构规范
### 架构图
- 所有的路由统一经过理由`Router`,路由权限统一路由组配合使用中间件统一控制,不得在`Controller`内部处理访问权限控制
- 控制器只处理请求接收验证和返回,不得在控制器内部编写逻辑代码
- 不同的域请求由不同的`Domain`处理器处理
- `Service`服务层负责处理数据服务,`Adapter`层负责函数调用适配器功能,所有的数据`CURD`统一由`Repository`内定义,不得在非`Repository`层外调用数据库操作。
- 小郭整理架构图如下![](
https://kmzsccfile.oss-cn-shenzhen.aliyuncs.com/upload/origin/2019/06/21/%E5%9B%BE%E7%89%871.png)
### 小柳整理,针对THINKPHP框架个人建议做如下调整
- 个人建议将结构划分为 `Router` - `Controller` - `Service` - `Model` 四层
- 所有模型统一创建至`application\common\model`文件夹下,不单独创建应用的模型,模型除基础类属性外、建议统一编写-增(insert)删(del)查(list - get) 改 ( update ) 父类,所有模型基层至此父类
- 统一在Service创建至`application\common\service`下、由其他控制器调用
- ![](https://kmzsccfile.oss-cn-shenzhen.aliyuncs.com/upload/origin/2019/06/21/liucheng.png)
### 测试和部署规范
- 项目在未上线前分为本地服务器和线上测试服务器,流程为本地测试正常后提交线上测试服进行测试,测试服的服务器配置和生产服保持一致,不得开发测试代码直接提交生产服或`master`分支,不得直接连接生产服数据库
## 其他规范
### Git使用规范统
- Git提交规范统一使用`Angular`提交规范, 具体内容请详看:[Commit message 和 Change log 编写指南](http://www.ruanyifeng.com/blog/2016/01/commit_message_change_log.html),每次提交,`Commit message` 都包括三个部分:`header`、`body` 和 `footer`
### type用于说明 `commit` 的类别,只允许使用下面7个标识
- `feat`:新功能(`feature`)
- `fix`:修补bug
- `docs`:文档(documentation)
- `style`: 格式(不影响代码运行的变动)
- `refactor`:重构(即不是新增功能,也不是修改bug的代码变动)
- `test`:增加测试
- `chore`:构建过程或辅助工具的变动
- 如果`type`为`feat`和`fix`,则该 `commit` 将肯定出现在 `Change log` 之中。其他情况(`docs`、 `chore`、`style`、`refactor`、`test`)由你决定,要不要放入 `Change log`,建议是不要。
### scope
- `scope`用于说明 `commit` 影响的范围,比如数据层、控制层、视图层等等,视项目不同而不同。
如果你的修改影响了不止一个`scope`,你可以使用*代替
- `subject`是`commit`目的的简短描述,不超过50个字符
网友评论