出于整个团队代码可读性、可维护性考量，有必要商定一套基本规范（包括代码命名、基础设备、提交日志、对外文档、测试等方面），供各团队都能参考，从而提升项目可持续性发展，也便于成员之间，能很好提升代码 CoverReview 效率等。鉴于此，有将近些年积淀的些许经验，整理成文，希望可以为追求“高效”工作的朋友们，带来少量参考性意见。
前台项目开发规范意见『有则推荐』: 自 2017 年初，就有开始利用闲余时光，打磨个人最新作品——「倾城之链」 ，有意将其打造成优良开放型平台，旨在云集全球优秀网站，让您更为便捷地探究互联网中那更广阔的世界；在这里，您可以轻松发现、学习、分享更多
有用或者有趣的事物。目前仍在不断迭代、优化中，假如您对此感兴趣，不妨先尝试一下： 「倾城之链」；亦十分欢迎提出您宝贵意见或者建议。 (Upade@2018-01-23 于深圳.南山)。也可以通过微信，扫描如下「小程序码」访问体验。
倾城之链 - 小程序温馨提示：npm 是前台开发广泛使用的包管理工具，它让 JavaScript 开发者分享、复用代码更方便。鉴于此，每位有经验的前台开发者，都应该对 npm、yarn、npx 等工具，以及 package.json、yarn.lock 等文件，有详尽的理解，如此才能便捷且更大限度的提升效率。先前也因未能理解其全貌，时有掣肘，故而总结了相关文章，如：Npm vs Yarn 之备忘详单、前台利器之 npx 使用纪要、关乎 package.json 的详细详情等；假如朋友们有更多实用玩法，欢请不吝分享。
显而易见，工具能辅助人发现很多潜在问题；非常必要引入依赖：husky、lint-staged、eslint、prettier，使得可以从流程上，保证项目的代码风格统一，规避部分错误，且不造成冲突；具体配置，可参考如下代码：
"scripts": { "watcher": "onchange \"src/**/**/*.{js,css,scss,vue}\" -- prettier --write {{changed}}", "prettier": "prettier --write \"src/**/**/*.{js,css,scss,vue}\"", "eslint-fix": "eslint src/**/**/*.vue --fix", "precommit-msg": "echo '🐉 Start pre-commit checks...' && exit 0",},"eslintConfig": { "root": true, "env": { "node": true, "es6": true }, "rules": { "no-console": 0, "no-useless-escape": 0 // ...... }, "plugins": [], "extends": [ "plugin:vue/essential", "plugin:prettier/recommended", "eslint:recommended" ], "parserOptions": { "parser": "babel-eslint" }},"prettier": { "singleQuote": true, "semi": false, "printWidth": 100, "proseWrap": "never"},"husky": { "hooks": { "pre-commit": "yarn run precommit-msg && lint-staged" }},"lint-staged": { "**/**.{js,json,pcss,vue,css,scss}": [ "prettier --write" ]}作为略有代码洁癖的我，非常喜欢利用 onchange 和 prettier 所配置的命令工具：watcher，每当写出代码，便能自动监听变化，将其美化，再也不用手动调整；极大提升了编写效率。为了方便，也有将其封装于 Arya Jarvis ：监听并美化指定路径下的代码。假如你喜欢，也能轻松运用。
根据项目情况，自行决定能否引入 commitlint 来督促项目成员有专业化的 commit message 提交。推荐使用：gitmoji：An emoji guide for your commit messages，执行git commit 使用 emoji 可以打标签，使得此次 commit 的主要工作得以凸现，也能够使得其在整个提交历史中易于区分与查找。
对于各种方法、变量、文件等命名，这无疑是编程最需注重要素之一！
见名知义；小驼峰（camelCased）；短横线（kebab-case），更推荐使用类以提升效率；短横线，小驼峰都行，统一目录下，请务必保持统一；大驼峰（CamelCased）；_ 前缀（_camelCasing）；g 前缀；Eg：gCoreVersion；is、can、 has 打头（同时优先遵循上一条）；on、handle 打头；Obj，Arr, Str, Num 结尾，针对容易混淆的命名；所有命名，除非是 for/forEach 内的 key(/item)，其余全部要使其该有的语义。
推荐参考编写一致、灵活和可持续的 HTML 和 CSS 代码的规范；假如想理解更多，可以阅读一直在于维护的：与时俱进版前台资源教程。除此之外，还需要额外补充少量相关要义。
请保证标签语义化，用适当的标签，做相关的事儿；见过有些开发者，喜欢使用 Div 增加 click 事件，辅之以 window.open 来实现链接跳转；这实在很没必要；而且客户也不是很方便使用。另外，设计好 Dom 层级，避免不需要的多层件套；比方，可以基于伪元素 before、after 来实现少量效果，而不用额外添加少量标签。
CSS：除了尽量使用类（最大限度上不要使用内联样式），精确而优雅的命名之外，请善用预解决工具，对各种 color、size、z-index 等常用的属性，统肯定义变量，方便编写，更利于后期维护；同时，还有常用方法，如居中、去浮动、阴影特效等操作统一封装（mixin），提升编写、维护效率，也能缩减源码量；对于 CSS 预解决器，推荐使用 Less 或者者 Stylus，而 Sass 会依赖 node-sass，而 node-sass 需要借助 Python 和 C++ 才能编译；跟环境耦合太重，很多时候，会出问题，但通过 npm rebuild node-sass命令，并不是所有时候都能处理问题。
每个项目有所区别，请阅读 Front-End Performance Checklist、Front-End Checklist 所给出的建议，确保项目是采取更优的用法。
假如基于 webpack 或者 rollup 来构建应用，请确保每个依赖是正当的，并且所构建出的内容，都是必要的，从而保证包是最轻量的； 可以使用的工具备：webpack-bundle-analyzer、rollup-plugin-analyzer 等。
develop 以及 hotfix 分支合并，任何时间都不能直接修改代码；bug修复后的代码；develop 分支下创立的；feature/ 开头的为特性分支， 命名规则: feature/user-module、 feature/cart-module；hotfix/ 开头的为修复分支，它的命名规则与 feature 分支相似；hotfix 分支，修复完成后，需要合并到 master 分支和 develop 分支；文档是开源项目的门面，须高度重视；除了认真 CR 内容外，仍有很多其余部分需要注意 ⚠️ ；因而这部分启用 Check List 来说明，以供项目可以逐个核对：
prettier *.md）尤其开源项目；alt（SEO）；favicon、语言等；可使用工具：Checklist Tools Website。
编写测试用例，配置对应 CI，只有通过 CR & CI 的 PR，才给予合并，从而保证项目成员每次拉取下来的代码，是可以正常工作（纯文档项目除外）；无论使用 Github 还是 Gitlab 管理项目，都有相关工具可以运用，方便快捷。
于 2020 年 04 月，深圳.福田。
原文首发于个人最新博客：静轩之别苑 — 前台项目开发规范意见。