如何在代码审查中找到积极的东西？
在去年出现了一些严重的质量问题之后，我公司最近引入了代码审查。很快引入了代码审查过程，没有任何准则或任何清单。 我和另一位开发人员选择在合并到主干中之前查看对系统所做的所有更改。 我们还被选为“技术主管”。这意味着我们对代码质量负责，但我们无权执行流程中的更改，重新分配开发人员或保留项目。 从技术上讲，我们可以拒绝合并，然后将其恢复开发。实际上，这几乎总是以我们的老板要求准时交货为目的。 我们的经理是MBA，主要负责制定近期项目的时间表。在尝试过程中，他几乎不知道从业务角度来看我们的软件的功能，并且即使没有开发人员的解释，也难以理解最基本的客户需求。 目前，开发工作是在SVN的开发分支中完成的，开发人员认为准备就绪后，便将票务系统中的票证重新分配给我们的经理。然后，经理将其分配给我们。 代码审查导致我们团队内部出现一些紧张关系。尤其是一些年长的成员对更改提出了质疑（即“我们总是这样做”或“为什么该方法应有一个明智的名称，我知道它的作用？”）。 在最初的几周后，我的同事开始放任自流，以免给同事造成麻烦（她告诉我自己，在客户提交错误报告后，她知道该错误，但担心该错误开发人员会对她指出这一点感到生气）。 另一方面，我现在以指出问题的方式而闻名。 我认为我的标准不是太高。 我目前的清单是： 该代码将编译。 代码至少有一种工作方式。 该代码将适用于大多数正常情况。 该代码将适用于大多数情况。 如果插入的数据无效，则代码将引发合理的异常。 但是我完全接受提供反馈意见的方式的责任。我已经在提出可行的观点，解释了为什么应该更改某些内容，有时甚至只是询问为什么要以特定方式实现某些内容。当我认为这很糟糕时，我指出我会以另一种方式开发它。 我所缺乏的是找到能够指出“好”东西的能力。我读到有人应该把坏消息夹在好消息中。 但是我很难找到一件好事。“嘿，这一次您实际上承诺了所做的所有事情”比谦虚或乐于助人更自负。 示例代码审查 嘿乔， 我对Library \ ACME \ ExtractOrderMail类中的更改有一些疑问。 我不明白为什么您将“ TempFilesToDelete”标记为静态？此刻，对“ GetMails”的第二次调用将引发异常，因为您在其中添加了文件，但是在删除它们后再也不会删除它们。我知道该函数每次运行仅调用一次，但是将来可能会更改。您能否将其设为实例变量，然后我们可以并行使用多个对象。 ...（其他一些无效的地方） 次要点： 为什么“ GetErrorMailBody”将异常作为参数？我错过了什么？您不会抛出异常，只需将其传递并调用“ ToString”即可。这是为什么？ SaveAndSend不是该方法的好名字。如果邮件处理出错，则此方法发送错误邮件。您可以将其重命名为“ SendErrorMail”或类似名称吗？ 请不要只注释旧代码，请将其彻底删除。我们仍然在颠覆它。