思考:若是让你制定代码提交规范(Git工具),你会怎么作?html
代码的提交信息是开发中一个很小的细节,因为它自己对代码运行自己不形成任何影响,主要做用在于方便查找、回退代码,因此很容易被开发者忽略。 可是它的意义就像项目文档、注释同样,是高质量项目必备的内容,好的提交信息不只能帮助开发者快速找到指定版本的代码,同时节体现的也是开发者的习惯和意识。前端
这篇文章想和你们聊聊这个小小的细节和软件工程师(如下简称工程师)的修养,或许能给那些初入职场或处于职场上升瓶颈期的读者一些启发。git
咱们如今的项目的代码提交信息比较乱,因此颇有必要创建一个代码提交规范。github
下面就以3个不一样工程师的处理方式来聊聊工做中的自我修养。web
除非作过相似的工做,否则接到任务的第一件事通常是打开浏览器搜索“代码提交规范”之类的关键字,会发现相关结果不少。经过一番整理,获得下面的信息:shell
<type>(<scope>): <subject>
// 空一行
<body>
// 空一行
<footer>
type:提交类型,可选值以下
* work: 开发中(work in progress)
* feature:新功能(new feature)
* fix:修补bug(fix bug)
* doc:文档(documentation changes)
* style: 格式(change code format)
* refactor:重构(modify code but not feature)
* test:增长测试(test code)
* chore:构建过程或辅助工具的变更(changes don't modify src and test files, only config or tasks) scope: 用于说明 commit影响的范围,好比数据层、控制层、视图层等等,视项目不一样而不一样。 subject:commit 目的的简短描述。 body: 对本次 commit 的详细描述 footer: 描述一些特殊状况,不兼容变更和issue关闭。 复制代码
好比Commitizen
,基本操做以下:npm
# 安装命令行工具
npm install -g commitizen
# 安装依赖
commitizen init cz-conventional-changelog --save --save-exact
# 经过扩展命令提交
git add .
git cz
复制代码
把上面的编写格式整理成文档,而后在项目中安装依赖试用如下,任务完成~浏览器
可是这只是作为普通工程师的标准,优秀工程师该怎么思考呢?bash
优秀的工程师和普通工程师的区别在于会反思工做并主动改进。也就是说不仅知足把事情作完,而是主动把事情作好。 把事情作好大体有两种:前端工程师
显然制定提交规范属于第一种状况,因此优秀的工程师会进一步思考。
每次提交的信息须要编写的内容很是多,若是每次提交个代码像写篇小做文同样麻烦,必然会引发反感。 这就比如原本开车上班路上时间不到半个小时,可是如今要求低碳出行只能骑自行车要1个小时,这种规定的可行性就很低了。 因此精简:
git cz
命令虽然能够替代git commit
命令来提交代码,可是它的有工程师不使用git cz
而仍然使用git commit
命令来提交代码则校验就会失效。 因此须要一个校验工具来保证咱们的规范有效的执行,至于工具git早已经为咱们准备好了——钩子。钩子相似于web组件的生命周期,能够在执行某些操做先后触发对应的shell脚本。与git commit
命令相关的钩子有4个,按顺序分别是:
这里咱们选择commit-msg
来实现,对应的脚本会像下面的样子:
#!/bin/sh
if grep -Eq "^(work|feature|fix|refactor|doc|test|chore|style|revert):\s*\w+" "$1"; then
exit 0
else
echo "Please format your commit message as follow:"
echo "<type>:<title>"
echo "<description>(optional)"
exit 1
fi
复制代码
规范就像是制度,好的制度不只须要制定者花心思去设计,更须要执行者知晓和配合。 因此有了文档和工具以后须要考虑的另外一件事就是在团队内部推广。 推广的方式经常使用的有作个PPT开会培训一下,或者把资料放到团队的wiki上提醒你们查看,这里就不详述了。
到了这一步,任务不只作完了,并且也算是作好了。 但要实现我的的最大提高,优秀还不够,必须卓越。 因此除了把事情作好以外,还应该考虑将它最大价值化。
再回到例子中,这个解决方案有没有可能用于其它团队/场景?
编写格式这一块基本上没有太多问题,可是提交工具会成为一个较大的障碍。Node.js一般只是前端团队的工具。若是要在其它团队中推广使用,学习成本不说,还会在项目中引入额外的依赖,可操做性并不强。
那是否是也要针对其它开发语言的项目去找合适的解决方案?这固然能够但不见得是最好的方式,由于时间成本过高,最好的方式是找到一个通用解决方案。
其实这个方案git早已经为咱们提供好,仍是以前用到的钩子。虽然commitizen
这类Node.js模块不是跨语言的解决方案,可是其采用按步骤给出提示语,而后由用户输入的交互方式,对于不熟悉规范的人来讲仍是比较好的。因此咱们能够在钩子脚本中沿用这种形式。
但对于熟悉规范的开发者来讲可能但愿直接使用git commit
命令一次性提交,因此还加入一些校验——对于不符合规范的提交信息给出交互提示,引导开发者按步骤完成提交信息。因为脚本内容较长,这里就不贴出来了,感兴趣的读者能够去文末的仓库地址中查看。
若是要作得更完美一些可使用git提供的template功能,具体使用能够查看文末提供的仓库地址。
工做态度决定了工程师的潜力,思考维度决定了工程师能力的天花板(固然这句话在别的岗位也可能通用)。
制定提交规范虽然只是一件很小的事,可是能够从中总结出不一样级别工程师在这两个方面的差别:
普通工程师 | 优秀工程师 | 卓越工程师 | |
---|---|---|---|
工做态度 | 公司安排什么就作什么、学什么,缺少主动意识。 | 能完成公司安排的任务,有时候还会超预期完成,同时在工做之余会利用时间学习。 | 不只能经常超预期完成公司的任务,同时还会主动思考团队、产品现有的问题或能够改进的地方并给本身安排任务 |
思考维度 | 单1、点状的。只关注任务自己,只考虑如何完成任务 | 线性、纵向的。会思考任务背后的目标,以及怎样才能更好的达目标而不只是完成任务 | 网状,全局的。切换身份思考,让任务成果对组织产生最大价值 |
若是您以为这篇文章对您有帮助请点赞,感谢阅读~
参考文章:
提交规范仓库地址:github.com/yalishizhud…
个人新书《了不得的JavaScript工程师:从前端到全端高级进阶》已经上架,得到了阮一峰老师等众多技术专家推荐,但愿能帮助更多前端工程师一块儿成长提高,拥有全面能力和全局视野,成为了避免起的JavaScript工程师!