我如何为降低代码评审的强度辩护？

解答动态

• 

  公司的利益相关者如何看待他们的开发人员的生产力？我以前的老板曾经给我讲过一个关于这种狂热的故事。开发团队把这种狂热作为拖延时间的借口。因此，实施最简单的更改花费了数月时间。他说解决这个问题需要解雇一半的开发人员，所以几个月后，他继续工作。但是每个故事都有两面性。关于正在开发的应用程序的性质，您没有说太多。如果这是一个涉及潜在生命损失（如医疗设备）或数百万美元资产处理的任务关键型应用程序，那么这种严格程度可能是完全合理的。
  在我工作的地方，每个软件项目都要经过一个“特征化”过程。基于这一特征（“它是控制战斗机，还是仅仅是一个命令行实用程序”），每个项目都要经历不同程度的审查。正式评审的成本很高；这一成本必须根据软件项目的性质来确定。
  在任何情况下，作为新的团队成员，您的想法都会遇到很大的阻力，特别是如果团队长期以来一直以这种方式运作，而没有任何人质疑他们的观点。你必须与你的团队成员建立信任，按照他们的方式做事一段时间，并逐渐建立起改变的理由。
  进一步阅读帕金森琐碎定律
  
• 

  你提出了一些需要解决的实际问题。但你提出的解决方案不太可能使事情变得更好。没有人只是在推理，如果我们首先没有50个方法在同一个类中，可能它不会有太多的方法定位的问题。在我的经验中，最好的方式让人们看到“更好的方式”是跳进去，并编码它。一旦你有了一个好的例子，不要强迫它进入代码库。邀请别人和你一起复习。让他们自己看到好处。我完全重新设计了别人创建的课程，然后谦恭地询问他们的意见。一开始他们表现出一些抵触情绪，但如果你表现出你足够认真地对待他们，向他们学习，他们也会冷静下来，开始向你学习。
  对我帮助最大的是，我去找人看我的代码，而代码在我脑子里还很新鲜。而我仍然愿意重写它。我坐在他们的书桌旁，或者他们坐在我的书桌旁（玩我的书桌玩具）。我们花时间在一起编码。只有电子邮件的代码审查往往只会演变成脑残的检查。他们会挑刺，因为没有人觉得他们可以让你真正改变代码，所以他们只想让它看起来像他们审查了它。这是真的，因为这些通常发生在你完成并开始其他工作的几天后。这些都是浪费时间。抱歉，对于一个好的代码审查来说太晚了。你对合并工具所做的任何事情都无法解决这个问题。愿意互相学习是协作工作的基本要求。否则这是委员会设计的。我怎样才能证明和辩护这篇呢那就是：合并按钮应该由default 启用，你应该有一些分支，你可以合并到你喜欢的，每个人都可以看到。这不一定是发布分支。
  代码评审应该是建议，而不是强制 强制代码评审！=正式代码评审。在你考虑其他事情之前，让别人看看你的代码。
  代码作者应该有权在6小时内合并代码，比如说创建拉取请求，不管是否有批准。 我完全赞成在6小时内完成（这是一个很长的时间），但未查看的代码需要停止在某个地方。我宁愿完全取消代码检查清单，也不想把东西留着看。
  
• 

  如果你认为开发人员应该有权忽略某些注释，比如方法不符合首选顺序，你在注释中拼写的“Exception”错了，等…
  重要的是，所有参与的人都知道并理解哪些类型的评论是可忽略的。
  如果其他开发人员意识到这些评论通常会被忽略，他们可能会停止吹毛求疵。在某种程度上，我已经完成了这项工作。
  
• 

  值得提醒的是，当代码评审正确完成时，它们会产生奇妙的结果。我提醒自己，在发现可能导致生产崩溃或根本不符合预期结果的代码之前，我主要是在进行橡皮图章审查。在回顾中抓住它为我们节省了宝贵的时间。
  我理解，你实施它们的方式带来了几个问题，我有几个建议要解决那个：吹毛求疵细节，而不是把重点放在一般的问题上，在新来者感觉很糟糕的敌对气氛中，这些请求无法得到批准
  如果公关因为细节而不被接受，先问问自己，这是商业问题吗？我想这取决于不同的公关。开发任务很少是时间关键，但在许多情况下，额外的公关延迟几天是可以接受的。你可以想象通过评审作为开发过程的一部分，并对其进行解释。
  如果延迟是不可接受的，或者你看到了改进的空间，有几种方法可以加速你的复习过程，而不需要花费太多的时间目标：更灵活代码标准在评审前通过代码标准系统地通知新评审/评审接受/评审拒绝评审员修改请购单的可能性，并批准修改后的请购单，当建议的变更很小时，这些变更必须得到整个团队的同意。如果你建议这些过程中的一些改变，对大多数人来说是合理的，那么你成功的几率会比完全取消审查过程（这使得它是可选的）要高。值得提醒的是应该：不要指向事情（命名，设计等）坏，差，脏等，而不是不符合准则，你应该同意和书面某处。包括当事情不顺利的时候，偶尔会向公众征求意见和/或见解被检阅人。什么时候必要的（当事情复杂时）处理 在这个框架内，即使我不喜欢评审，也已经同意系统评审是一件很好的事情。使评审成为可选的愿望源于您对当前代码评审过程的失望。我不能责怪你。
  在做代码评审时，我会寻找3件事（按此顺序）：
  明显的错误-如果我第一眼看不到，我会继续前进。
  正确的架构和设计-我可能在这里花的时间最多。
  S
• End