命名规范

  • 变量名, 函数名 小驼峰【命名法 camel Case】: numberOfPeople 第一个单词的首字母小写;第二个单词开始每个单词的的首字母大写
  • 组件名 大驼峰【命名法 Camel Case】: NumberOfPeople 每一个单词的首字母都大写
  • css样式名 中横线【命名法 kabab case】: number-of-people 单词小写用(-)中横线分隔
  • 常量名, graphql query 与 mutation变量名: 蛇底式大写【命名法 upper snake case】: NUMBER_OF_PEOPLE 复合词或短语中的各个单词之间:下划线(_)分隔并且没有空格
  • 禁用小写加下划线 :number_of_people

| 命名方式 | 应用范围 | 备注 | | --- | --- | --- | | camel Case | 变量名, 函数名 | | | Camel Case | 组件名, 枚举名 | 枚举: SaveType = { BUILD: 'BUILD' } | | kabab case | css样式名 | | | upper snake case | 常量名, graphql query与 mutation变量名 | | | snake case | 禁止使用 | |

应用范围

结构
应用范围
备注
动+宾 (+ 副词)
函数名, graphql mutation名称
名词(定语+名词)
组件名, 类名
形容词 (名词+形容词)
动词被动形态
(be+xxx)
状态变量
控制对话框是否显示: dialogVisible
尽可能不要用 is+形容词结构, 如 isSelected, 用 selected 就可以了.
is+名词结构可以使用, 如 isEnterprise

名词

camel Case: numberOfPeople Camel Case: NumberOfPeople kabab case: number-of-people snake case: number_of_people upper 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. 用并行的代码表达并行的概念。

Git分支

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

Git Commit type

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

提交 Commit 类型前缀 主要如下: feat: 新特性\功能 fix: 缺陷修复\bug docs: 文档相关 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。