出于整个团队代码可读性、可维护性考量,有必要约定一套基本规范(包括代码命名、基础设施、提交日志、对外文档、测试等方面),供各团队都能参考,从而提升项目可持续性发展,也便于各组之间能很好提升代码 CoverReview 效率。

各项配置

显而易见,工具能辅助人发现很多潜在问题;有必要引入依赖:huskylint-stagedeslint(快应用这块儿需建设)、prettier,使得可以从流程上,保证项目的代码风格统一,规避部分错误,且不造成冲突;具体配置,可参考如下代码:

{
"husky": {
  "hooks": {
    "pre-commit": "lint-staged",
    "commit-msg": "commitlint -E HUSKY_GIT_PARAMS",
    "pre-push": "yarn test:lint"
  }
},
"lint-staged": {
  "*.js": [
    "eslint --fix",
    "prettier --write",
    "git add"
  ],
  "**/**/**.{ux,json,pcss,md,vue,less,scss,css,qxml,wxml}": [
    "prettier --write",
    "git add"
  ]
}

根据项目情况,自行决定是否引入 commitlint 来督促项目成员有专业化的 commit message 提交。推荐使用:gitmoji

项目规范

对于各种方法、变量、文件等命名,这无疑是编程最需注重要素之一!

命名规范

  • 语义化:保证命名高度具有可读性,力争做到:见名知义
  • 参数、公有方法名:统一小驼峰(camelCased);
  • CSS 命名:统一短横线(kebab-case),更推荐使用以提升效率;
  • 文件名,文件夹短横线小驼峰都行,统一目录下,请务必保持统一;
  • 类名或公开对象:统一大驼峰(CamelCased);
  • 私有字段或方法:统一加 _ 前缀(_camelCasing);
  • 全局变量:统一加上 g 前缀;Eg:gCoreVersion;
  • 布尔类型值/方法:统一以 iscanhas 打头(同时优先遵循上一条);
  • 事件、方法回调:分别以 onhandle 打头;
  • 常量:统一采用“全大写 + 下划线的方法命名”,Eg: EVENT_LIMITATION;

  • 对象、数组字、符串、数字:建议分别以 ObjArr, Str, Num 结尾,针对容易混淆的命名;
  • 尽量避免使用缩写,除非是大众流行(application => app ✅ group => grp ❌);

所有命名,除非是 for/forEach 内的 key(/item),其他一律要使其该有的语义

代码规范

JavaScript

HTML、CSS

性能检查

每个项目有所区别,请阅读 Front-End Performance ChecklistFront-End Checklist 所给出的建议,确保项目是采取更优的用法。

构建尺寸

如果基于 webpack 或  rollup 来构建应用,请确保每个依赖是合理的,并且所构建出的内容,都是必要的,从而保证包是最轻量的; 可以使用的工具有:webpack-bundle-analyzerrollup-plugin-analyzer 等。

分支命名规范

master 分支

  • master 为主分支,也是用于部署生产环境的分支,确保 master 分支稳定性;
  • master 分支一般由 develop 以及 hotfix 分支合并,任何时间都不能直接修改代码;

develop 分支

  • develop 为开发分支,始终保持最新完成以及 bug修复后的代码;
  • 一般开发的新功能时,feature 分支都是基于 develop 分支下创建的;

feature 分支

  • 开发新功能时,以 develop 为基础创建 feature 分支
  • 分支命名: feature/ 开头的为特性分支, 命名规则: feature/user-modulefeature/cart-module

release 分支

  • release 为预上线分支,发布提测阶段,会 release 分支代码为基准提测
当有一组 feature 开发完成,首先会合并到 develop 分支,进入提测时,会创建 release 分支。
如果测试过程中若存在 bug 需要修复,则直接由开发者在 release 分支修复并提交。
当测试完成之后,合并 release 分支到 master 和 develop 分支,此时 master 为最新代码,用作上线。

hotfix 分支

  • 分支命名: hotfix/ 开头的为修复分支,它的命名规则与 feature 分支类似;
  • 线上出现紧急问题时,需要及时修复,以 master 分支为基线,创建 hotfix 分支,修复完成后,需要合并到 master 分支和 develop 分支;

对外文档

文档是开源项目的门面,须高度重视;除了认真 CR 内容外,仍有很多其他部分需要注意 ⚠️ ;因此这部分启用 Check List 来说明,以供项目可以一一核查:

  • [ ] 是否编写良好 README.md尤其开源项目
  • [ ] 专业化排版;如“中英文间留空格“等(prettier *.md尤其开源项目
  • [ ] 是否有引入其他方有可能侵权的资源,如视频、图片等;尤其开源项目
  • [ ] 是否完善上线及发布日志尤其开源项目

搜索引擎优化清单

  • [ ] 安装Google Analytics(分析)
  • [ ] 设置 Google Search Console
  • [ ] 在 Google 的Search Console中检查抓取错误,重复内容错误,标题丢失和其他技术错误
  • [ ] 抽查重定向问题(特别是 302 错误,应该为 301s)Browseo.net
  • [ ] 寻找断开的链接,错误和爬行问题 Seo Spider
  • [ ] 尝试将主要关键字纳入您的页面网址网址最佳做法
  • [ ] 将关键字添加到标题标签。您的标题标签引人注目吗?标题标签预览工具
  • [ ] 将关键字添加到您的 H1 标签。确保仅使用一个 H1 标签,并确保它在文档中显示在 H2,H3 等之前。
  • [ ]  向页面添加可抓取的文本
  • [ ] 是否有配置 title、 description(含社交系)meta;
  • [ ]  针对图片指定对应的 altSEO);
  • [ ]  是否配置配置 favicon、语言等;
  • [ ] 使用对 SEO 友好的文本链接到您网站上的其他页面。内部链接的最佳做法
  • [ ]  确保您没有重复的内容(非 www 到 www 重定向)
  • [ ] 检查您网站的速度并保持快速!Google Page Speed工具
  • [ ] 确保您的网站适合移动设备。Google Mobile Friendly测试工具
  • [ ]  创建 XML 网站地图,并将其提交到 Google Search Console
  • [ ] 创建 robots.txt 文件并将其提交到 Google Search Console Google Robots.txt
  • [ ] 在尽可能多的社交网站上声明您的品牌名称。Namechk
  • [ ] 使用 SEO 审核工具仔细检查所有内容。Seo Checklist Analysis

可使用工具:Checklist Tools Website

完备测试

编写测试用例,配置对应 CI,只有通过 CR & CI 的 PR,才给予合并,从而保证项目成员每次拉取下来的代码,是可以正常工作(纯文档项目除外)。