开发规范

版本：v20.1.4

Ref
Isobar前端代码规范 及 最佳实践
语义化版本 2.0.0
Square 公司怎么写提交信息
editor config

phpunit手册
GIT工作流
GIT
[大厂研发需求流程]https://mp.weixin.qq.com/s/SB3aHvalAmZ3_RVwjhpekg

关于「能愿动词」的使用

• 必须 (MUST)：绝对，严格遵循，请照做，无条件遵守；
• 一定不可 (MUST NOT)：禁令，严令禁止；
• 应该 (SHOULD) ：强烈建议这样做，但是不强求；
• 不该 (SHOULD NOT)：强烈不建议这样做，但是不强求；
• 可以 (MAY) 和 可选 (OPTIONAL) ：选择性高一点，在这个文档内，此词语使用较少；

代码风格选择

默认风格：
php psr2
python pep8
js

版本要求

2020.4.1开始新项目

php >= 7.2
laravel >=6.0

php
PSR-2
PHP 标准规范
Clean Code PHP

js
.jshintrc

python
Google Python风格指南
[pep8] (https://www.python.org/dev/peps/pep-0008/)

代码风格检查/修复工具

phpcs
https://github.com/squizlabs/PHP_CodeSniffer/
wiki:
https://github.com/squizlabs/PHP_CodeSniffer/wiki

install:
composer global require "squizlabs/php_codesniffer=*"

usage：
phpcs /path/to/code/
phpcs --standard=psr2 ./app #使用psr2规范检查
phpcs -a #每个文件交互方式确认

php-cs-fixer
https://github.com/FriendsOfPHP/PHP-CS-Fixer
composer global require friendsofphp/php-cs-fixer

phpunit
composer require phpunit/php-code-coverage

JSHint
http://jshint.com/docs/options/

python
pylint https://www.pylint.org/
flake8
https://pycodestyle.readthedocs.io/en/latest/intro.html#error-codes

code style
1. 项目根目录添加.editorconfig
设置

end_of_line = lf
indent_style = space
indent_size = 4 （js项目可设置 2 ）
charset = utf-8

1. 添加 .gitattributes 文件

* text eol=lf

代码

1. 类库导入顺序，依次导入 系统库、第三方库、内部库

优雅的代码

1. 不要复制代码 相似代码片段做合并

SVN/GIT提交规范

1. 禁止提交临时文件（本地测试文件,临时生成文件、日志、编译缓存文件等）
2. 禁止提交大小超过1M的图片、压缩包等文件
3. 禁止提交无用代码变动；如 空白行，调试代码等

4. 每次提交必须填写·提交信息（注释）·
   要能明确描述变动情况
   事例：
   add 用户登录功能
   add xx功能的单元测试
   fix 在一些情况下提示登录错误的问题
   update readme.md

5. 提交前保证代码 codestyle检查，单元测试 能通过；（非代码原因可例外）
   develop分支 每月可有 3次错误机会
   master分支 必须保证无错误

6. 提交代码前建议 DIFF看下修改的代码，移除调试代码

7. 注意文件大小写，window下文件不区分大小写。

** GIT 工作流程**
ref： http://jartto.wang/2018/12/05/git-flow/

1. 项目默认有 develop分支（测试服）以及master分支（正式服）
2. 项目主程（项目开发负责人）或经过项目主程授权的开发 可以直接工作的develop分支上
3. 项目主程 负责合并 develop分支到 master分支
4. 其他（临时抽调）开发人员提交代码 本地(基于最新develop分支)新建分支（feature or bug）推送到服务器上
   创建 merge request 到develop分支 ，分配给项目负责人（主程）
   同时确保 mrege request 的 集成测试 能通过
5. merge request 审核人（项目负责人） 负责codereview 合并或者驳回

worktile规范

1. 保持任务卡片状态是实时更新，状态符合实际情况;
   1.1 在做的任务要放到在做栏
   1.2 需要测试的任务添加测试检查项，并将测试人员添加到关注人
   1.3 做完后不需要测试人员测试自行移到 完成栏， 需要测试的话，测试人移到完成
   1.4 有截至日期的任务，若到期没有完成，评论里面说下原因并自行调整下截至时间（ps：但是紧急和bug任务除外）

2. 任务卡片标题简要明确（控制在2行内），具体内容可添加到任务描述里面

3. 短期（2周）内要做的任务必须设置截至日期；同时保证在做的设置截至日期
4. 被分配任务后，若worktile上没有创建任务卡片，请自行创建并将相关人员加关注人
5. 若检查项有 “测试” 项，则标明该任务开需要测试人员测试，测试后进行打勾
6. BUG反馈或优化建议的任务卡需要添加上相应的标签
7. 任务完成后 需要将任务交付相关结果（文件）备注上。 比如代码仓库地址,接口文档或者excel表格 等

worktile规范v2

1. 保持任务卡片状态是实时更新，状态符合实际情况;
   1.1 在做的任务状态要设置为进行中
   1.2 需要测试的任务修改为待测试
   1.3 做完后不需要测试人员测试的，自行修改为已完成
   1.4 有截至日期的任务，若到期没有完成，评论里面说下原因并自行调整下截至时间（ps：但是紧急和bug任务除外）
2. 任务卡片标题简要明确（控制在2行内），具体内容可添加到任务描述里面
   2.1 任务类型要选择对应的类型 如 任务，研发任务，研发需求，缺陷 等
   2.2 任务层级最多2层；任务的创建应该是事件而不是类别；
   部分任务可以创建3层但是负责人必须和父任务是同一个人
3. 短期（2周）内要做的任务必须设置截至日期；同时保证进行中的任务设置截至日期
4. 被分配任务后，若worktile上没有创建任务卡片，请自行创建并将相关人员加参与人
5. BUG反馈或优化建议的任务卡需要添加上相应的标签
6. 任务完成后 需要将任务交付相关结果（文件）备注上。 比如代码仓库地址,接口文档或者excel表格 等

性能规范

1. 数据库-单次http请求sql执行数限制在10条以内，严禁循环中执行sql查询（特殊情况例外）
2. 数据库-数据查询的时候禁止两个以上的大表join（数据量都大于1W条）
3. 前端-图片要加载合适大小的图片
4. 日志-不要往日志文件写入大量数据内容，避免日志文件快速膨胀
5. 单个请求耗时需要限制在5s内

UED规范

1. 图片不要改变原有比例显示
2. 表格 若一列宽度是固定死得（如图片/价格/销量）则把宽度就固定住不要自适应，这样为了给一些较宽的列（如标题）留出更多“宽度”

项目初始化规范

1. 编写详细readme.md 说明
   编写原则，新手可根据该文件说明，尽可能简单的 搭建可运行的项目

2.

安全规范

1. 禁止在日志文件中写入帐号、密码内容（mysql、redis、登录用户等）

其它

不同项目下的额外情况在 readme.md 以及文档中有说明

约定

1. 依赖的外部服务需要编写对应的链接测试脚本；（比如mysql elastic redis 等）

README编写规范

1. 符合Markdown语法，排版简洁友好
2. 项目名称，紧跟着项目简介
3. 该项目用到的参考资料（可选）

4. 项目运行环境说明
   依赖的系统（ubuntu 18.04, 或者某个docker镜像），第三方软件，第三方库等

5. 项目初始化安装步骤说明
   如何安装依赖第三库
   如何修改配置信息

6. 常用命令示例说明或者 demo链接以及结果

7. 其他需要注意的地方说明
8. 最终原则其他人可以根据readme运行起来项目

日报

1. 若一项任务需要多天完成 附上进度
2.

BUG评级

1. 低级程度
2. 影响程度

BUG反馈

根据反馈模板来反馈bug

TIPS

1. 调试bug的时候 多用异常 断言，若不符合预期就抛出已隐藏 暴露出来
2. 一些比较重要的配置项 不建议增加默认值；防止忘记配置了 导致使用错误的配置项
   另外最好能检查（断言）这个配置项已经配置了
3. 环境变量不要以数字开头（貌似docker-composer中不生效）

数据清洗

1. 数据一致性，原子性；多类型记录防止漏掉数据
2. 防止重复采集

58图网站项目 开发流程补充说明

1. 开发完成后移动任务卡到待测试
2. 由开发负责发布 测试服务器 自测，测试没问题 发布正式服务器
3. 若没问题

PHP项目注意

1. 正式测试环境，禁止启用TELESCOPE调试框架