我的前端编码规范

记录一些前端开发日常的编码规范，如命名规范、代码风格、提交规范等，不定期更新。

命名规范

• 变量名，函数名 小驼峰【命名法 camel Case】: numberOfPeople 第一个单词的首字母小写；第二个单词开始每个单词的的首字母大写

• 组件名 大驼峰【命名法 Camel Case】: NumberOfPeople 每一个单词的首字母都大写

• css 样式名 中横线【命名法 kabab case】: number-of-people 单词小写用（-）中横线分隔

• 常量名，graphql query 与 mutation 变量名：蛇底式大写【命名法 upper snake case】: NUMBEROF_PEOPLE 复合词或短语中的各个单词之间：下划线（）分隔并且没有空格

• 禁用小写加下划线：number_of_people

例：

handleButtonClick
onChange={this.handleCardChange}
handleSubmit
hideDialog
handleNextStep
onConfirm = handleConfirmClick
onCancel
handleDialogClose
handleClickNextButton

应用范围

名词示例

camel Case: numberOfPeopleCamel Case: NumberOfPeoplekabab case: number-of-peoplesnake case: number_of_peopleupper snake case: NUMBER_OF_PEOPLE

Merge Request Checklist

• 检查是否和目标分支有冲突

• 检查是否修复所有 dn test 的问题

• 检查目录、文件名拼写

• 检查 graphql 文件名拼写，Query 首字母大写的 CamelCase，Mutation 首字母小写的 camelCase

• 检查 conf 中的命名是否符合规范

标准的项目研发流程包括以下几个阶段：

* 评审阶段
    * 需求评审
    * 交互评审
    * 视觉评审
* 开发阶段
    * 原型开发
    * 用户交互事件响应
    * 接入Mock数据
    * 后台接口数据对接
* 联调阶段
    * 预发联调
    * 整个业务串联测试流程
* 测试阶段
    * 埋点开发及验证
    * 自测用例覆盖
    * 交付提测
    * bug修复
* 发布上线

写作的基本准则（优化）

基本上写作的基本准则的每一部分都能应用在代码上：
    ● 让段落成为文章的基本结构：每一段对应一个主题。
    ● 去掉无用的单词。 .
    ● 使用主动语态。
    ● 避免一连串松散的句子。
    ● 将相关的词语放在一起。
    ● 陈述句用主动语态。
    ● 平行的概念用平行的结构。
  这些对应的 用在前端的代码风格上
    1. 让函数成为代码的基本单元。每个函数做一件事。
    2. 去掉无用的代码
    3. 使用主动语态
    4. 避免一连串松散结构的代码逻辑
    5. 把相关的变量、函数放在一起。
    6. 表达式和陈述语句中使用主动语态。
    7. 用并行的代码表达并行的概念。

Bug 分类

• fixed: 注明问题出现的原因
• Won’t fix：非问题，不需要修复的 bug，需置为“Won’t fix”
• Later：遗留 bug，需要将 bug 置为“Later”
• Worksforme：log 无效，且无法再复现的 bug，需置为“Worksforme”，由测试同学继续跟踪复现
• Duplicate：重复 bug 需要设置为“Duplicate”，并关联初始 bug，由测试同学跟踪初始 bug 解决状态
• invaild：无效的 bug，
• By Design：逻辑设计如此，不需要修复的 bug，需置为“By Design”。

Git 分支

存在三种短期分支            功能分支（feature branch）            补丁分支（hotfix branch）            预发分支（release branch）

更多见：https://markyun.github.io/blog/branch/

Git Commit type

bug fix - 组件 bug 修复；breaking change - 不兼容的改动；new feature - 新功能

提交其他 Commit 类型前缀 主要如下：feat: 新特性\功能fix: 缺陷修复\bugdocs: 文档相关style: 样式修改、错别字修改、代码的格式化改动，代码逻辑并未产生任何变化refactor: 重构或其他方面的优化perf: 性能提升test: 增加测试chore: 业务无关修改，如：发版、构建工具链修改等scope 可选，作用域标识，指明你需改的代码所属作用域subject 真实 Commit 描述，能说明白即可，字数不用太多

Git 日常操作

git diff 查看修改内容

git bisect  二分查找法 定位问题

git clone git@github.com:UED/test.git

git fetch origin    //取得远程更新，这里可以看做是准备要取了

git merge origin/master  //把更新的内容合并到本地分支/master


git remote -v //查看当前项目远程连接的是哪个仓库地址。

git push -u origin master //    将本地的项目提交到远程仓库中。

git push -u origin master -f // 强制提交

git commit --amend 修改上一次 commit

抛弃本地所有的修改，回到远程仓库的状态。
git fetch --all && git reset --hard origin/master

        git clone 地址  clone
        git branch 查看分支
        git branch daily/0.0.1 创建分支

        # 切换分支，格式为 daily/x.y.z
        git checkout daily/0.0.3
        # 提交代码
        git pull
        git add *
        git commit -m 'feat: 完成了某个新功能'

        # 将代码push到gitlab daily环境
        git push origin daily/0.0.3

        # 打publish tag将代码发布到CDN
        --tag 创建一个里程碑
        git tag publish/0.0.3
        git push origin publish/0.0.3

代码中的注释前缀和类型

TODO: 有功能待实现。此时需要对将要实现的功能进行简单说明。

FIXME: 该处代码运行正常，但可能由于时间赶或者其他原因，需要修正。此时需要对如何修正进行简单说明。

HACK: 为修正某些问题而写的不太好或者使用了某些诡异手段的代码。此时需要对思路或诡异手段进行描述。

# 标题行：50个字符以内，描述主要变更内容
	#
	# 主体内容：更详细的说明文本，建议72个字符以内。 需要描述的信息包括:
	#
	# * 为什么这个变更是必须的? 它可能是用来修复一个bug，增加一个feature，提升性能、可靠性、稳定性等等
	# * 他如何解决这个问题? 具体描述解决问题的步骤
	# * 是否存在副作用、风险?
	#
	# 尾部：如果需要的化可以添加一个链接到issue地址或者其它文档，或者关闭某个issue。