你们公司的代码规范是怎么严格执行的？

[xuhaodong66]

目前打算这样子：

公司基于 gitlab 开发，在 gitlab 中新建一个代码规范仓库，每周安排一个人去审查一个项目（非自己），将评审结果的表格提交到仓库中，评审结果指向审查项目的 issue， 在 issue 中指出不规范的地方和正确的示例。

[windsage]

committer 机制

[xuhaodong66]

@windsage 可以详细点吗，不太明白

[lizhuoli]

靠 clang-format 等严格的 lint 工具执行，外带一个静态代码扫描(基于 Clang AST 和正则搭配)，基本就差不多了，不靠人力用技术手段约束

[feiyuanqiu]

代码格式、简单的 bad smell 这类风格问题，本地用 intellij idea + Alibaba Java Coding Guidelines + google-java-format，gitlab 仓库用 gitlab-ci 集成 checkstyle、sonar 等自动化工具任务，绝对比人有效靠谱。

code review 应该做剩下的自动化工具不擅长的部分，让熟悉业务的人检查代码对需求的实现是否正确合理； reviewer 能否仅凭代码和 commit 信息就看懂代码的逻辑和意图，有任何看不懂的地方就打回去让提交者改。

另外提一点，code review 最好在代码合并时做，而不是等上线后再巴啦巴啦提一堆问题让别人改，除非 leader 有很大的决心一直推动，否则我不觉得能维持多久，你会一直被问这些问题：程序跑得好好的为什么要改？修改的限期是多久？修改与做新需求的优先级谁高，工作排期紧张时先做需求还是先改代码？代码改了要不要测试？这额外的测试工作量怎么说服测试接受？...

[ihainan]

所有的新 Feature / Bug Fix 必须开 Issue 来记录，所有提交必须走 PR，PR 需要指向新建的 issue，每个 PR 都会触发 Travis 编译、跑 UT、检查风格（ Scalastyle ）和检查测试覆盖率（ scoverage ）。PR 需要指定两个 reviewer，直接用 GitHub 的 Review 功能来给 comment，除了代码逻辑还必须检查是否有测试覆盖新提交的代码，另外每日都有 Jenkins 重新部署环境和跑 FVT。

[lincanbin]

CI 自动化检测咯，出问题抄送 group 里所有成员。

[phobal]

正规开发流程应该是这样的

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 到主分支。

[xw900812]

@phobal 没错，我们就是这样的干的。。。尽量自动化，不需要人力来检测。