这是一个创建于 2390 天前的主题，其中的信息可能已经有所发展或是发生改变。
目前打算这样子：
公司基于 gitlab 开发，在 gitlab 中新建一个代码规范仓库，每周安排一个人去审查一个项目（非自己），将评审结果的表格提交到仓库中，评审结果指向审查项目的 issue， 在 issue 中指出不规范的地方和正确的示例。
 | 1 windsage 2019-05-14 23:40:05 +08:00 via Android  1 committer 机制 |
 | 2 xuhaodong66 OP @windsage 可以详细点吗，不太明白 |
 | 3 lizhuoli 2019-05-15 00:19:58 +08:00 via iPhone 1 靠 clang-format 等严格的 lint 工具执行，外带一个静态代码扫描(基于 Clang AST 和正则搭配)，基本就差不多了，不靠人力用技术手段约束 |
 | 4 feiyuanqiu 2019-05-15 00:47:46 +08:00 3 代码格式、简单的 bad smell 这类风格问题，本地用 intellij idea + Alibaba Java Coding Guidelines + google-java-format，gitlab 仓库用 gitlab-ci 集成 checkstyle、sonar 等自动化工具任务，绝对比人有效靠谱。 code review 应该做剩下的自动化工具不擅长的部分，让熟悉业务的人检查代码对需求的实现是否正确合理； reviewer 能否仅凭代码和 commit 信息就看懂代码的逻辑和意图，有任何看不懂的地方就打回去让提交者改。 另外提一点，code review 最好在代码合并时做，而不是等上线后再巴啦巴啦提一堆问题让别人改，除非 leader 有很大的决心一直推动，否则我不觉得能维持多久，你会一直被问这些问题：程序跑得好好的为什么要改？修改的限期是多久？修改与做新需求的优先级谁高，工作排期紧张时先做需求还是先改代码？代码改了要不要测试？这额外的测试工作量怎么说服测试接受？... |
 | 5 ihainan 2019-05-15 01:03:05 +08:00 1 所有的新 Feature / Bug Fix 必须开 Issue 来记录，所有提交必须走 PR，PR 需要指向新建的 issue，每个 PR 都会触发 Travis 编译、跑 UT、检查风格（ Scalastyle ）和检查测试覆盖率（ scoverage ）。PR 需要指定两个 reviewer，直接用 GitHub 的 Review 功能来给 comment，除了代码逻辑还必须检查是否有测试覆盖新提交的代码，另外每日都有 Jenkins 重新部署环境和跑 FVT。 |
 | 6 lincanbin 2019-05-15 01:14:34 +08:00 via Android 1 CI 自动化检测咯，出问题抄送 group 里所有成员。 |
 | 7 phobal 2019-05-15 09:59:55 +08:00 1 正规开发流程应该是这样的 1、在开发期检查。前端的话可以配置 ESLint 的代码里面，结合编辑器插件使用，可以在开发期对基础的错误进行检查。 2、在 commit 期检查。结合 git hooks，可以在 git commit 的时候执行自定义的 hooks，你可以在 hooks 中定义检查规则，不符合规范的无法 commit。 3、在 merge 之前 review。在 gitlab 中对开发人员配置角色，每个项目指定 2-3 个有 merge 权限的人，其他人没权限将代码提交到 主分支上。规定每一次代码改动必须提 merge request，经过 code review 才能进入第 4 步。 4、在 merge 之前跑 pipeline。可以在 gitlab 配置 gitlab-ci，在里面集成单元测试、集成测试 等，只有这些都跑过了，才能进行 merge 到主分支。 |
Select Language