代码评审的步骤 代码评审每个人都要参加嘛？
代码评审每个人都要参加嘛？
通过代码评审，团队中的每个人都有机会相互理解的代码内容，有助于促进跨库和整个团队的知识共享，让任何团队成员都可以接手并继续推动整个项目的演进。
如何解决代码和文档不一致的问题？
这里的文档不是指Javadoc、Doxygen等生成的API文档。对于一个负责任的团队来说，这类文档的更新可以保证代码同时更新。
首先看文件是干什么用的。重要性高，必须改变:如日本外包软件。这是以后保养的重要参考。一般的代码不一致是由于开发人员没有严格按照文档进行编码。或者有了新的需求变更，代码先行，没有回头修改阶段。应该记录在案。
这是一种不合理的操作模式。
如何避免？
专门指派的维护人员，通常是设计师、高级工程师、PM，在变更发生时及时做出修正。另外，加大评价力度。设计评审，代码评审。防止偏差
如何解决已经发生的偏差？
什么？;什么是错的？;的错误，并纠正和警告造成偏差的人，这是没有办法的。
Code Review常见的5个错误模式？
在代码评审时，每个人都会关心最佳实践，但最差的实践有时可能更有启发性。
代码审查对于研发是必不可少的。ampd团队，但它并不总是正确的。本文指出了所有开发人员在提交代码审查或拉取请求时可能会遇到的一些常见错误模式，并总结了这些错误模式:
错误模式:查找故障
想象一下下面的场景。代码编写者花费数小时甚至数天来创造他们认为最有效的解决方案。他们考虑了各种设计方案，并选择了看起来最相关的方案。他们考虑了现有应用程序的架构，并在适当的地方进行了修改。然后，他们以拉请求的形式提交了他们的解决方案，或者开始了代码审查的过程，他们收到的专家反馈是:
你应该使用标签，而不是空格。我不 我不喜欢大括号在这部分的位置。文档末尾没有空行。你的词库是大写的，所以你应该大写句子。尽管新代码与现有代码的风格保持一致很重要，但这些事情几乎不需要审计人员来完成。好的。人工审核员的成本很高，他们可以做计算机能做的事情。;t .检查是否符合风格标准是计算机很容易完成的事情，分散了代码审查的真正目的。
如果开发人员在代码评审过程中看到很多这样的注释，说明团队要么没有风格指南，要么有风格指南，但是风格检查还没有自动化。解决方案是使用checkstyle之类的工具来确保遵循了样式指南，或者使用sonarqube识别常见的质量和安全问题。持续集成环境可以做到这一点，而不是依赖人类审计员来警告这样的问题。
有时候，如果没有代码指南，或者内部代码风格随时间变化，不同的部分有不同的风格，那么这个自动检查可能会比较困难。在这种情况下，有一些方法可以应用自动检查。例如，一个团队可能同意提交一份报告，应用商定的代码风格，不包含其他更改。或者一个团队可以约定，当一个文件由于bug或者函数而被更改时，该文件也将被更新为新的样式，并且自动化工具可以被配置为只检查被更改的文件。
如果一个团队有多种代码风格，并且它可以 不要自动检查款式，很容易落入下一个陷阱。
错误模式:反馈不一致
每一个被邀请评审代码的开发人员都应该邀请至少一个或更多的意见。每个人都可以同时持有不止一种观点。有时，代码审查可能会陷入审查者之间关于不同方法的争论中，例如使用streams或classic for。循环是最好的。如果团队成员对同一段代码有不同意见，开发人员该如何修改，结束评审，将代码推向生产？
甚至一个评论家 的想法很容易改变，无论是在一次审查中，还是在一系列审查中。在一次审查中，审查者可能会敦促作者使用O(1)读取操作的数据结构，在下一次审查中，审查者可能会问为什么不同。用户会有几种数据结构，建议用单一结构的线性搜索来简化代码。
当一个团队没有。;不清楚它的最佳实践是什么样的，当团队没有 如果不知道它的优先级是什么，就会出现这种情况:
代码应该向更现代的Java风格发展吗？或者更重要的是代码一致性，所以继续到处使用经典构造？读取系统所有部分的O(1)数据结构很重要吗？还是O(n)的某些部分可以接受？几乎处处所有的设计问题都可以根据情况来回答。为了更好地了解答案，开发人员需要了解他们的应用程序和团队的优先级。
错误模式:最后一分钟设计变更
开发人员在代码评审过程中最令人泄气的反馈是，当评审人员从根本上不同意方案的设计或架构，强行完全重写代码时，他们要么通过一系列评审一步步完成(见下一节)，要么粗暴地拒绝代码，让作者重新打开。开始吧。
代码审查不是审查设计的合适时机。如果团队遵循经典的网关代码审查，那么在最后一步将代码展示给另一个开发人员之前，代码应该工作，并且所有的测试都应该通过。此时此刻，事实上，几个小时，几天，甚至几周(虽然我真的希望它 不是几周；代码评审应该是小菜一碟，但这是另一个话题)努力都花在评审的代码上了。代码评审中指出底层设计是错误的。这是对每个人的浪费。;是时候了。
代码评审可以作为设计评审，但是如果这是代码评审的意图，那么评审就应该在实现之初进行。然后，在开发人员走得太远之前，他们可以概述他们的想法，也许会有一些存根类和方法，以及一些对名称和步骤有意义的测试，也许还可以提交一些文字或图表，这样团队成员就可以对要采用的方法给出反馈。
如果团队成员在网关评审期间(即，当代码完成并运行时)发现了真正的演示设计问题，团队应该更新过程以更早地定位这些问题。这可能意味着进行其他类型的回顾，如前一段中建议的回顾、白板上的想法和配对。程序，或者与技术主管讨论建议的解决方案。在最终的代码评审中发现设计问题，是对开发时间的浪费，对代码作者的打击也很大。
错误模式:乒乓球评论
在理想的情况下，作者会提交代码供评审，评审人员会提出一些明确的解决方案。作者会建议修改并重新提交代码，代码会在评审后被推送。但是如果这样的事情经常发生，谁又能告诉Code Revi呢？Ew s流程有道理？
在现实生活中，经常会发生这样的事情:
代码审查开始。有评论者提出了几个建议:有的小而易，有的不修边幅，没有明显的解决方案，有的比较复杂。作者做了一些改动:至少是简单的改动，或者几处改动，为了让审稿人满意。作者可以向审阅者提问以澄清一些事情，或者作者可以做出评论来解释为什么没有做出具体的更改。评审人员回来后，他们接受一些更新，对其他修订提出进一步的意见，找出他们不知道的地方。;不喜欢，回答问题，并与其他评论者讨论或作者对他们的观点提出了质疑。代码编写人员进行更多的修改，添加更多的注释和问题，等等。审稿人检查修改，提出更多的意见和建议，等等。重复第5步和第6步，也许是永远重复。在这个过程中，理论上，修改和注释应该向零递减，直到代码准备好。最郁闷的是每次迭代都会带来至少和已经结束的老问题一样多的新问题。在这种情况下，团队进入了代码审查的无限循环。这有许多原因:
如果评审者很挑剔，并且评审者给出的反馈不一致，就会出现这种情况。对于陷入这些习惯的评论者来说，有无限多的问题需要发现，有无限多的观点需要提出。当没有明确的审稿目的，或者审稿时没有遵循的准则时，就会之所以会出现这种情况，是因为这样一来，每一个审核者都会觉得每一个可能出现的问题都必须找出来。它发生在不清楚什么是审查者 的注释对代码作者的要求。是不是每一条评论都意味着必须修改？所有的问题都暗含代码吗？没有自证，需要改进？还是有些评论只是为了下次教育代码编写人员，提问只是为了帮助评审人员理解和学习？评论应该理解为屏蔽或者不屏蔽。如果评审人员决定需要修改代码，他们需要清楚地说明代码作者应该做什么。姚行动了。
了解谁决定审计是否完成也很重要。这可以通过检查任务列表上的项目来实现，或者可以由授权足够好的个人来完成。它通常需要一个能打破僵局，解决分歧的人。这个人可能是高级开发人员、领导或架构师。老师，甚至是团队中的代码编写人员，因为在团队中，他们之间有着高度的信任。然而，在某些时候，需要有人说审查结束了或者当这些步骤完成时，审查就结束了。
错误模式:幽灵审查
在这里我承认我最容易犯一个异常:重影。无论我是评审人员还是代码作者，代码评审总会有一个点(有时是在开始！)，在审核过程中，我没有 完全没有反应。也许有一个重要或有趣的功能需要我检查，所以我决定把它留到更好的时候，那时我可以真正好好看看。也可能是复习量大，想留出足够的时间。或者我就是作者。经过20次迭代，我就可以 t面读和回复评论，所以我决定等等。等我脑袋准备好了再回来。
听起来熟悉吗？
不管什么原因，有时人们不。;在审核过程中，不要做出任何回应。这可能意味着在这个人读完代码之前，评审就已经死了。这是浪费。即使有人投入时间来创建一个资产(新代码)，它也没有。;投产前没有增加。增加价值。事实上，当它越来越落后于其他代码库时，它很可能已经腐烂了。
有几个因素会导致幽灵审查。巨大的代码审查量是一个因素，因为谁愿意去检查几十或几百个修改过的文件呢？不重视代码审查是另一个因素，因为不重视代码审查是真正的工作或交付结果。一部分原因是困难或令人沮丧的代码审查经历是另一个主要因素。没有人愿意停止编码(开发人员通常喜欢的东西)，参与一项耗费时间、摧毁灵魂的活动。
以下是解决幽灵审查的建议:
确保代码审查规模较小。每个团队都必须制定自己的定义，但这需要几个小时或几天的审查，而不是几周。确保代码评审的目的是明确的，评审者应该寻找什么是清楚的。当范围是It 当您发现代码中可能存在的任何问题时，很难激励自己去做一些事情。在开发过程中留出时间进行代码审查。最后一点可能需要团队纪律，或者团队可能希望采用，例如，目标或用于确定开发人员的任何东西。奖励良好代码评审行为和鼓励允许时间的生产力机制。
你的团队能做什么？
对于R ampamp团队，专注于创建一个有效的代码评审过程。我已经在我的博客上写了这个，但是我想在这里分享这个过程的一部分:
代码评审需要考虑很多事情。如果开发人员担心每一次代码评审中的所有事情，那么任何代码都几乎不可能通过评审过程。实现一个适合所有人的代码评审。过程中，最好的办法是考虑以下问题。
团队为什么要做评审？当有一个明确的目的，考官 的工作会更容易，代码作者也会减少审查过程中令人不快的意外。团队成员在寻找什么？当有目的时，开发人员可以在审查代码时创建一组更有针对性的检查内容。谁将参加？用什么？谁来做评审，谁来负责解决意见，谁来最终决定代码是否合格？团队何时进行评审，评审何时完成？审计可以在开发人员处理代码时或者在过程结束时反复进行。没有明确的指导，审查可能会继续下去。走下去，如果没有明确的指导，代码什么时候才能最终进行。团队在哪里进行评审？代码审查不会。;不需要特殊的工具，所以审查可能就像作者在他的办公桌前向他的同事展示他们的代码一样简单。一旦你回答了这些问题，你的小组团队应该能够创建一个运行良好的代码审查过程。记住:代码评审的目的应该是把代码投入生产，而不是证明开发人员有多聪明。
结论
通过建立一个清晰的代码评审过程，可以消除或者至少减轻代码评审的错误模式。许多团队认为他们应该进行代码审查，但是他们没有明确的指导方针。他们为什么要进行代码审查？Review.
不同的团队需要不同类型的代码评审，正如不同的应用程序有不同的业务和性能需求。第一步是找出团队为什么需要评审代码，然后团队可以开始:
自动化的简单检查(例如，检查代码风格，识别常见的错误，以及发现安全问题)。对评审的时间、内容和评审后由谁来决定制定明确的指导方针，将代码评审作为开发过程中的重点工作内容来抓。为什么要进行代码评审，这将有助于团队创建代码评审过程的最佳实践，从而更容易避免代码评审的错误模式。
版权声明：本文内容由互联网用户自发贡献，本站不承担相关法律责任.如有侵权/违法内容,本站将立刻删除。
