思考以下场景。
产品负责人大橘向团队中的三个开发人员--三猫, 四狗, 五谷--汇报了他们刚刚交付的报告所须要的紧急批改。第二天上午10点有一个客户会议，批改必须上线，这样大橘能力演示。当初是下午6点。五谷正在通勤回家，四狗正在去别墅的路上（她请了假）。三猫却恰好在他的笔记本电脑旁。
上面是接下来产生的事件。
- 三猫看到大橘的音讯，并让大橘晓得， 没问题，他能够进行更改。然而他从早晨9点开始和今天整个上午都不在，因为他有家庭事务。因而，他可能无奈在早上现场推送更改或反对。
- 四狗，作为后座的乘客，在Slack上看到了这，并说 "没问题，如果有什么须要实现的，我早上会在那里"。
- 三猫开始写一些代码，并关上了一个pull request（PR）。
- 早晨8点，五谷回到家，看了看Slack，让团队晓得她当初能够帮忙了。她看了看三猫的PR，发现没有测试，因为这是一个急件，于是决定增加测试。因为需要在Slack上，而且他们能够在彼此的fork上进行合作，这不是一个问题。
- 三猫早晨9点上班。
- 早晨10点，五谷实现了测试，这时四狗曾经上线，能够进行审查。四狗抓到了一个bug（五谷在脑海中反转了一些需要，因为她很困），五谷调整了代码后，他们推送上线。
- 到了早上，四狗又做了一些批改，因为大橘在最初一刻提出了一些十分额定的要求，并把它们推送到了网上。三猫从他的手机上批准了第二个PR（他很放心，正在查看）。客户会议获得了微小的胜利。
把性别反过来，这基本上是我团队一个周四深夜的状况。我感觉十分骄傲。不过不同寻常的是，这并不是我以前24岁时，为一家守业公司熬夜时那种愚昧的自豪感。看看我，我的工作很重要 如果我不间断工作24小时，世界就会灭亡
这次我的自尊心被不同的事件所激发。
- 我的团队中的三个开发人员都同样相熟代码 并同样具备批改和审查工作的能力。
- 整个团队奋起直追，没有留下任何一个人加班到深夜。
- 因为咱们有三个人，所以即便在匆忙的状况下也能实现高质量的工作。
后果是
- 只管这是一项紧急的工作，但测试工作曾经全面开展。因而没有开发债权。
- 所有的bug都被审查发现了。
- 团队的友情和彼此的信念达到了前所未有的高度。
- *
我在同一个团队曾经快一年了，这个时候你对代码曾经有点太相熟了，所以你开始有了想法：s_我要不要换个团队？_当初，要思考不同的起因：你是否受到挑战？路线图上有什么？你的职业规划是什么？我在这里就不说这些了。我想说的是，为什么我特地喜爱在这个团队工作，以至于我不想换。
通过思考，我意识到我喜爱在我的团队工作，不是因为_谁_在团队里，也不是因为_团队的工作内容。我喜爱的是咱们工作的形式。
- 整个团队晓得咱们所领有的大部分代码库，所以咱们一起探讨/设计和架构。这导致了十分好的各种想法和弱小的技术设计（咱们恰好有一个相当多样化的团队，对咱们来说是侥幸的）。
- 当咱们中的一些人不在时，咱们能够在紧急情况下替换。
- 咱们常常进行重构和试验--而且这样做很平安。
咱们是怎么做到的？**咱们为团队制订的Pull Request审查规定和准则。
团队成立的时候，咱们只有3个开发人员，一个产品负责人和半个经理（另一半经理忙于治理一个更大的团队）。咱们决定，既然咱们人这么少，不如把咱们当成一个团队来运作。于是咱们想出了一个公关审查规定。无论咱们中的一个人写什么，另外两个人都要承受 而后，随着咱们一直地审查对方的PR，咱们把规定集扩大为一些准则。
我在这里写下这些规定和准则，因为我意识到兴许有些人会发现它们对他们的团队有用。也可能这些会给你带来一些思考，你会有齐全不同的想法。
规定1
**每次PR审查必须至多有2个同团队开发人员的批准。经理批准不算。
首先要留神的是，因为咱们一开始是3人团队，这是最现实的。所有3个开发人员都是100%的知情者。对于更大的团队来说，这可能是不同的。你的指标是邓布利多--Horcruxes的状况，如果你死了，至多有2到3集体晓得Horcruxes。咱们的团队当初有5个开发人员，其中有2个老家伙，1个新来的，还有2个中坚力量。咱们还是想保持每个人都审核每个人的PR的模式，但如果改成1个老前辈+1个其余开发者的最低限度，可能会比拟正当。
"经理审核不算数"--兴许这让你感觉 "WHAT，我是经理，而且是个了不起的编码员，我的审核齐全算数，你怎么敢。" 经理审核的确_有帮忙。咱们有了不起的经理，他们恰好是很棒的编码者，当他们有工夫审查时，他们常常会有很好的提醒或想法来帮忙咱们。
但你必须思考你的经理花了多少工夫在编码上。是否超过50%？那么他们也是一个开发人员，所以好吧，让咱们来计算他们。然而，在咱们公司，开发经理偶然会做十分多的编码工作。到最初，是开发人员要和正在编写的代码一起生存。因而开发人员有最终的发言权。我十分不喜爱看到经理和开发人员有限的审批周期，一个经理始终在审批一个开发人员的PR，即便团队中还有3个开发人员还没来得及看。
规定2
**每个PR必须有一个好的形容。通过浏览形容，评审员应该可能了解代码的目标。即便有Jira ticket或需要页面，也必须如此。
没有形容的PR - 在我的团队中，这种状况永远不会通过。最好的状况是，他们没有写，因为Jira ticket有一个很好的形容。最坏的状况是：Jira ticket没有任何形容。Jira ticket什么都没有。
没有形容的PR的审核者有2个工作。
- 通过浏览PR中的代码变动，理解代码的作用； 2.
- 试图依据......审查者对宇宙和以后地缘政治气候的个别认识来决定代码是否做了_它应该做的事件？
如果没有明确解释代码要做什么的申明，审查它的正确性是不可能的。你基本不晓得什么是正确的。你是在你认为正确的假如上操作的。
规定3
PR必须有足够的单元测试和集成测试覆盖率。
现实状况下，评审员能够很容易地看到所笼罩的测试案例列表。
如果测试覆盖率曾经存在，或者因为某种原因测试覆盖率不残缺（工作被宰割到另一个票据中，依赖性），PR形容应该提到这一点。
给出好的PR评审是很难的，也是很费时间的。这是因为一旦你理解了代码应该做什么，你就必须进行评审，记下你想要的测试覆盖率_这个。你要制订你本人的测试用例列表，并决定它们是哪种类型：单元测试/集成/端到端。
你还必须思考是否有可能的生产影响，以及是否须要在部署前对实时数据进行任何测试。
当初你晓得了所有这些，你再去回顾PR，查看他们是否涵盖了你想到的所有内容。现实状况下是混合的--你想到了一些他们没有想到的货色，而他们也想到了一些你没有想到的货色，你们一起做得很好。这就是可能轻松地看到PR中笼罩的测试用例列表的中央（而不是必须浏览100行或1000行的测试，并且必须弄清楚哪些用例是真正被测试的）。
须要留神的是，如果遵循了规定2，你只须要浏览形容就能够晓得代码应该做什么。所以，你能够在审查任何理论代码之前，就进行审查测试覆盖率的步骤!
我集体喜爱把所有这些--提到的测试、任何实时数据测试、任何实时客户端影响/须要的prod config变动--都放在PR形容上。这样一来，它就在一个中央。能够是一个链接的Jira ticket。只有它在某个中央，并且曾经被思考过了。
规定4
**如果PR是一个bug修复，它必须蕴含一个测试，如果bug修复被复原，这个测试将失败。
我认为这是不言而喻的，但就像大多数不言而喻的事件一样，它不是。
假如有一个排版谬误，你用了 != 而不是 ==。过后是早晨 10 点，你本不应该进行编码，但你感觉那天早晨你想多走几步路。于是你开了一个bug修复PR，把 != 改成了 ==。一些凶恶的人，也在工作，批准了它，而后把它放到了主分支。
三天后，你的好友三猫终于筹备好了他那份失控的PR：他认为这是一个小性能，没有把它分解成更小的ticket，但后果并不是这样，当初他有一个2000行的PR，他在求他的团队审核。
三猫从上游合并，代码抵触的中央你把==换成了!=.三猫很累，他没留神到怎么回事，!=又回来了。
因为没有测试来抓它，所以bug又回来了。
这是一个人为的例子，但如果你在较长的工夫内留神--这种状况始终在产生。把3年内的bug摆出来，你会发现那些没有被测试捕捉的bug又呈现了。
就这样吧! 三条规定，还有第四条更多的是常识性的我的项目。
我意识到，这些规定，导致咱们团队产生了一些品质相当不错的代码。我对此非常高兴，绝不居功自傲。
同样，这些规定可能你会感觉不对，也可能它们恰好对你有帮忙。如果它们引发了任何思维或想法，我很快乐!