比较优秀的做法是：每一次 pr 都有 review ，而不是全都写完了，QA 都测完了才 review ，然后重写，这样会导致 QA 也要重新测试。

组员是你领导吗？是的话让你咋改就咋改，不是的话，难道你是怂 B 吗？你不改能把你吃了还是咋地

@dynastysea 当然是领导啊，要组员不得怼死他。

@JingXiao 一点都不轻松，经常性的推翻重来，谁能受得了，关键我特喵的也记不住他的哪些吊想法，问多了，还得挨批。提交个 mr 战战兢兢的。

@MrRongts 那领导还说个毛线，要么辞职要么忍

这就是某些人的执念，所以只能做做程序员

@S1ahs3r 你还别说，就一个 key 命名的问题，我一不留神就给我乱来，搞得现在要半夜起来更新数据改这该死的 key 。

@dlmy 忙的时候，MR 就堆在哪里，堆个 10 几 20 个一点不夸张，交付的时候经常出现合并冲突，然后丢代码，然后又让我们去改。 闲的时候，开始 review 了，一行一行的看, 写的跟他想法不一样，就要按他的想法来，重写，你还得拿笔记，想想心里都堵的慌。

@dynastysea 裸辞太亏了，放开了，准备开怼了。混个 n+1

@profchaos #34 哪对了，这不就是代码风格不同，还能分个高下的。 那分号结尾对不对，尾随逗号对不对，箭头函数括号对不对，实验新三元组对不对。 只要有统一的代码风格强制限定，无论怎么配置我都认为对，反之无论怎么写都是错。