有些新人发现自己的代码提交MR后，会收到一堆的代码评审意见，必须要做大量的改动。这多半是因为在开始做之前，没有做好设计，做出来后才发现问题很多。 建议在做一个新功能之前，写一个简单的设计文档，表达清楚自己的设计思路，找资深的先帮你做一下设计的审查，发现设计上的问题。设计上没问题了，再着手开发，那么到评审的时候，相对问题就会少很多
我在做代码审查的时候，有时候会发现一些非常明显的问题，有些甚至自己都没有测试过，就等着别人代码评审和测试帮助发现问题。这种依赖心理无论是对自己还是对团队都是很不负责任的。 一个好的开发人员，代码在提交代码评审之前，肯定是要自己先评审一遍，自己把基本的测试用例跑一遍的
代码评审效果和质量与CR代码量成反比，每次CR代码量小一些，看起来速度快，又不至于失去耐心，所以要经常进行代码评审，但是每个CR代码量要少，我建议要少于 200 行/CR
写好简介，主要变更，以及附上原型和问题链接，每个MR只讨论一件事，逻辑较为复杂，需要提供简要的功能描述和截图
如果你有个改动很大的 MR，可以在写了一部分的情况下先提交，但是在标题里写上 WIP，以告诉项目维护者这个功能还未完成，方便维护者提前 review 部分提交的代码
- 解决所有的 discussions（Gitlab 设置）
- 至少 1 个 reviewer 同意才能合并