认识达内从这里开始

在这个开放的时代发展背景下，协作共赢是我们提倡的一种合作模式，那在软件开发过程中如何协作呢？本文小编和大家一起探讨一下。

以前刷到一个新闻，说美丽国程序员因同事不写注释，不遵循驼峰命名，括号换行，还天天 git push -f ，他最后受不了枪击了4名同事。最后自已也自杀，这是在用生命在维护代码。代码不规范，的确让人看着头痛。俗话说：没有规矩不成方圆。高效的协作，前提是大家都遵循一套都认可的规则或标准。

公司制定了编程规范，各个团队有各种检查的最小集，也有各种开发工具来辅助提交代码时检查。但在MR的Commit Message上似乎并没有较好达成一致，不少团队虽在这一方制定规范，其出发好像并不是为了有效地协作，而是对Commit的溯源管理，比如要求有需求单号，问题单号等。这些存在Commit Message也没有关系，但Message最为重要的还是：

能详细描述此次Commit的背景与动机，甚至能提醒在Review时要关注什么

可带一个链接，能链接到Issue或问题单，能让Review时翻开查看知道修改的原因

目前在一些材料中都会推荐 Angular git commit message ，甚至在此基础上衍生出 conventional commits specificaion 。 业界的规范统一之后，有一好处是形成生态，相关生成工具、检查工具也会应运而生。我们就不要闭门造轮子了。

CI的静态检查、门禁会自动发现代码中的基本问题，以及拦截一些不满足规范要求的问题。能自动化搞定的事情就不要让人来搞，但毕竟工具不能代表人，所以代码提交者还得考虑Committer与Reveiwer的时间是宝贵的，有必要花时间先进行自我的检查，并不一定要搞个CheckList，但目的无外乎：

工作做细：Commit Message是否描述详细，能帮助带来更有价值的Revive意见

自我进化：确保不再出现以前Review发现的同样问题

有效注释：MR既然是给人Review，那要尊重Reveiwer，不好理解的地方要恰当注释，不符合一般用法要注释强调

二次确认：对提交的代码再次进行比对确认，确保是否遗漏或误操作

一次MR多少行代码合适是一个比较有争论的话题，太少看不出全貌，太多又让人生畏。用代码行数来说一次MR是不恰当的，既然是要让人Review，就要站在如何支撑更好的Review效果来思考：

单一：一个MR应该只解决一个问题，如实现一个需求功能点，或者是解决一个Bug。能让人快速了解代码改进是解决了什么问题，才有针对性地思考与Review

短小：一个MR应该是一个完全的逻辑实现点，对于较大的需求可以拆分多个功能实现点来一次次提交，切忌一次提交一个需求完整的所有代码;也可以按实现阶段提交，如接口定义，数据定义，框架骨干，接口实现等

测试：无论什么层次的代码，应该写一点代码，自己测试一点，通过自我测试来降低一些低层错误;同样有测试用例的代码，也会让Reviewer加强对代码的理解，通过输入输出，发现一些场景是否考虑到

有些协作不应该只是发生在代码MR阶段，正好本文开头所有讲的，设计的问题若在MR阶段提出，修改的工作量会让提交者失了修改的动力。对于代码提交者而言，应该先有对应的Iusse对代码层设计简单描述出来，通过文档协作方式，让Reviewer提前参与进来。设计不需要长篇大论，就事讨论事即可，也不需要Word文档，代码仓库的Issue或Wiki都是比较好的承载方式。

这一点开源软件做得比较好，由于大家所处不同的地域，不同的时间，通过Issue把讨论过程完整记录下来。而我们集中办公反而当面交流效率更高，也让讨论的过程记录缺失。而传统要求的形式化Word文档设计随着版本的迭代，落入文档历史尘埃中，无法搜索到。若试图再通过开发人员额外的关联标注，也仅仅只是给开发人员增加工作量，并没多大的意义。

【免责声明】本文系本网编辑部分转载，转载目的在于传递更多信息，并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题，请在30日内与管理员联系，我们会予以更改或删除相关文章，以保证您的权益!更多内容请添加3216764521学习了解。欢迎关注“达内在线”参与分销，赚更多好礼。