- 综合排序
- 最热优先
- 最新优先
- 来自专栏快乐阿超
gitee代码评审建议
可以使用suggestion代码块 ```suggestion wrapper = Sf.mayColl(new HashSet(dataList)).mayLet(values -> wrapper.in
37220编辑于 2022-11-22 - 来自专栏【腾讯云开发者】
代码评审做个人？
代码评审作为保障软件质量的重要手段，是大型软件开发中不可或缺的重要一环。质量高的评审，对于提升质量和塑造团队氛围有着不可替代的作用。 本文总结了我作为评审的参与者，在命名、指引性注释和沟通方式三个方面的一些思考，或许这几个容易被人忽视的地方，才是影响代码评审质量的关键之处。愿你的代码评审，不被人喷“做个人”。 Code Review（代码评审）是一种流行的软件开发实践。通过在代码合入主分支前引入人工评审，能有效促进成员间的知识交流，提升软件质量。 我以评审者的身份参与过大量代码评审。 每一次代码评审，必定涉及到许多新名字。 正因如此，程序员的日常充斥着各类沟通工作，参与代码评审正是其中之一。 在代码评审时，评审者的工作内容似乎一句话就可简单概括：指出他人代码中的不足。这听起来易如反掌，对不对？
52220编辑于 2024-12-25 - 来自专栏架构之家
说透代码评审
1）代码评审费时费力： 项目期限 Deadline 已定，时间紧迫，天天加班忙成狗了，谁还愿意搞代码评审？ 代码评审形式可以分为： 机器检查 人工评审 纯线上评审 线下投屏评审(推荐) 这里推荐做法是线下投屏评审，或许传统、保守，但是利大于弊。 代码评审容易犯的错误：评审人用自己主观意见看待别人的代码。 代码评审 代码评审中发现的问题，根据严重性决定是否进行二次评审。 ，否则评审的时候，大家都在搞私事，容易流于形式，而要提高代码评审的质量，我们必须明确代码评审的形式，对象，参与者，关注点，流程，常见问题。
1K20编辑于 2022-07-12 代码评审实践指南
提交者应遵循的准则清晰说明修改背景：代码提交时要说清楚本次修改的目的和方式,要帮助评审的人了解代码的背景和解决的问题。 控制每次提交的代码量：尽量每个CR都包含较少的代码,可以分步有序提交，先整体后细节。原则是不要让评审者花太多的时间在一个CR上。 提交前自我审查：提交CR前自己要再检查一遍代码,自我review一次,避免低级错误。这既体现专业性，也表达对评审者的尊重。 保持开放心态：对于评审意见，应尽量采纳，即使认为细节无关紧要，也应尊重对方建议。遵守代码规范：不随意破坏既定规范，保持代码风格一致。 如果一个模块只有一个人在维护开发,那么也要给它配一个资深reviewer建立CR制度：规定代码提交必须经过评审（紧急Bug修复等特殊情况除外），未通过CR的代码不得入库。
29310编辑于 2025-11-25- 来自专栏DevOps时代的专栏
评审的艺术——谈谈现实中的代码评审
代码评审就是第二部分颇具槽点，可以大加讨论的典型。 代码评审是展现个性和性格的途径 我本人特别反对一种颇为常见的观点，就是“一个良好运作的项目，不同的人，应该写出一样的代码”。 代码评审本身，以及基于评审意见的来回沟通，和代码本身比起来，要更难以，也更不应该要求一致。 但是，就我个人而言，我可以谈谈我自己的代码评审风格： 我会关注三种问题，需求和业务上的问题、代码结构的问题、代码风格格式的问题。 我的习惯是，在明确代码要解决的问题以后，先快速走读一遍代码，判断我是应该粗略地抓主要矛盾呢，还是应该严格地挑刺呢。我也见过一些别的方式。 不一样的评审要求 我始终觉得，代码评审的要求不应该完全一致。 我不知道哪一种是最难的，但是如果因为这些原因很难做到良好的评审，我会在评审中说明，或者放弃一些评审的工作，保证评审的质量。 代码评审是建立在团队中影响的好方式。
67130发布于 2019-05-17 - 来自专栏MavenTalk
评审的艺术——谈谈现实中的代码评审
代码评审就是第二部分颇具槽点，可以大加讨论的典型。 代码评审是展现个性和性格的途径 我本人特别反对一种颇为常见的观点，就是“一个良好运作的项目，不同的人，应该写出一样的代码”。 代码评审本身，以及基于评审意见的来回沟通，和代码本身比起来，要更难以，也更不应该要求一致。 但是，就我个人而言，我可以谈谈我自己的代码评审风格： 我会关注三种问题，需求和业务上的问题、代码结构的问题、代码风格格式的问题。 我的习惯是，在明确代码要解决的问题以后，先快速走读一遍代码，判断我是应该粗略地抓主要矛盾呢，还是应该严格地挑刺呢。我也见过一些别的方式。 不一样的评审要求 我始终觉得， 代码评审的要求不应该完全一致。 我不知道哪一种是最难的，但是如果因为这些原因很难做到良好的评审，我会在评审中说明，或者放弃一些评审的工作，保证评审的质量。 代码评审是建立在团队中影响的好方式。
37810发布于 2019-07-19 - 来自专栏四火的唠叨
评审的艺术——谈谈现实中的代码评审
代码评审就是第二部分颇具槽点，可以大加讨论的典型。 代码评审是展现个性和性格的途径 我本人特别反对一种颇为常见的观点，就是 “一个良好运作的项目，不同的人，应该写出一样的代码”。 代码评审本身，以及基于评审意见的来回沟通，和代码本身比起来，要更难以，也更不应该要求一致。 但是，就我个人而言，我可以谈谈我自己的代码评审风格： 我会关注三种问题，需求和业务上的问题、代码结构的问题、代码风格格式的问题。 我的习惯是，在明确代码要解决的问题以后，先快速走读一遍代码，判断我是应该粗略地抓主要矛盾呢，还是应该严格地挑刺呢。我也见过一些别的方式。 不一样的评审要求 我始终觉得，代码评审的要求不应该完全一致。 我不知道哪一种是最难的，但是如果因为这些原因很难做到良好的评审，我会在评审中说明，或者放弃一些评审的工作，保证评审的质量。 代码评审是建立在团队中影响的好方式。
37620编辑于 2022-07-19 - 来自专栏DevOps时代的专栏
评审的艺术 — 谈谈现实中的代码评审
代码评审就是第二部分颇具槽点，可以大加讨论的典型。 代码评审是展现个性和性格的途径 我本人特别反对一种颇为常见的观点，就是“一个良好运作的项目，不同的人，应该写出一样的代码”。 代码评审本身，以及基于评审意见的来回沟通，和代码本身比起来，要更难以，也更不应该要求一致。 但是，就我个人而言，我可以谈谈我自己的代码评审风格： 我会关注三种问题，需求和业务上的问题、代码结构的问题、代码风格格式的问题。 我的习惯是，在明确代码要解决的问题以后，先快速走读一遍代码，判断我是应该粗略地抓主要矛盾呢，还是应该严格地挑刺呢。我也见过一些别的方式。 不一样的评审要求 我始终觉得，代码评审的要求不应该完全一致。 我不知道哪一种是最难的，但是如果因为这些原因很难做到良好的评审，我会在评审中说明，或者放弃一些评审的工作，保证评审的质量。 代码评审是建立在团队中影响的好方式。
52920发布于 2019-09-26 - 来自专栏腾讯移动品质中心TMQ的专栏
测试左移之代码评审
笔者自认代码基础能力还不错，就想通过代码Review来提前发现一些Bug。 多数项目中，代码评审工作是由开发同事相互执行的。 但往往开发同事为了赶进度，并没有时间进行代码评审，导致很多明显的Bug被遗留到了测试阶段。那代码评审是否可以由测试人员来做呢？显然是可以的。 诚然多数测试人员的代码能力没有开发人员的水平，代码Review的深度不如开发同事，但通过实践证明，测试人员也能胜任大部分代码评审的工作。 [1502938122633_2662_1502938288952.png] 因此，对于以上类似的判断逻辑代码，可以做的评审有三点: 1）是否能优化判断逻辑，使代码更加简洁易懂； 2）是否所有的分支都得到了合理的处理 [1502938163404_5910_1502938329802.png] 效果 代码评审在QQ浏览器漫画模块最近了三个版本进行了实践，共发现Bug25个，如下面的截图所示。
1.5K10发布于 2017-08-18 - 来自专栏三木的博客
使用gerrit作为代码评审工具
需求描述 其实作为项目代码的maintainer，一直习惯于mailing list + git的代码评审及管理，无奈公司主推敏捷+devops，老板让改用gerrit。 需求其实很简单，我们项目一直使用公司内部一个类似于github的代码托管网站来托管项目代码，使用邮件列表来评审代码。代码通过评审通过后，我再将patch push到代码托管服务器上去。 整个开发流程如下图所示： 现在需要切换到gerrit来作为代码评审工具，以便于能够和jenkins集成，搭建一个集开发、构建、测试、部署为一体的devops系统，结构如下图所示。
2.8K60发布于 2018-02-07 - 来自专栏项目管理
论代码评审的重要性以及未来AI在代码评审中的作用
代码评审在软件开发中扮演着至关重要的角色，它不仅有助于保证代码质量，还能促进团队成员间的知识共享与技能提升。 以下是对代码评审重要性的详细分析： 代码评审的重要性 提高代码质量：通过代码评审，可以发现并修复代码中的错误、冗余和不良实践，从而提高代码的质量。 减少缺陷：在代码评审过程中，可以尽早发现潜在的问题和缺陷，避免在后期产生更严重的后果。 促进知识共享：代码评审是一个很好的知识共享平台，团队成员可以通过审查他人的代码，学习新的编程技术和最佳实践。 代码评审的好处 提升编程技巧：通过代码评审，开发人员可以学习新的框架或库的使用，提升整个团队的编程能力和项目的整体质量。 持续学习和改进：AI可以通过不断学习和分析项目数据，持续优化代码评审和重构策略，提高团队的整体开发效率和代码质量。代码评审是确保软件质量和促进团队协作的重要环节。
65011编辑于 2024-12-17 - 来自专栏全栈程序员必看
java逻辑错误_java代码评审
测试文件：hello-jni/src/com/example/hellojni/HelloJni.java
83720编辑于 2022-11-08 - 来自专栏编程一生
代码评审的三怕
评审代码的流程 我自己总结的评审代码的流程，仅供参考： 1>确认代码的修改范围 2>梳理修改的部分的处理流程，之前没有流程图，需要先画流程图 3>进行逻辑正确性评审 4>对照代码规范和评审checklist 从上面二方库和三方库的升级方法来看，二者的升级都需要不小的工作量，作为代码评审的人要对结果负责。所以工作不仅是评审代码，还要确保上面需要的工作都做到位了。 最冤枉的是原来的代码本来问题也不大，只是风格不符合代码评审人员的习惯。结果评审人员非要编码人员改了，结果没改全出现了问题。虽然有一些手段进行规避，比如单元测试。但是修改的代价还是很高。 我在进行代码评审的时候，第一件事是确认代码编写人员的修改范围，看看这个修改范围我之前有没有对逻辑做细致的梳理。如果没有梳理过，那我先梳理一遍，照着梳理的内容进行评审。 最可怕的是评审出来问题后，评审人让写代码者改什么，写代码者就是无脑照办。评审人很可能由于使用脑补细节有疏漏，造成问题。
80030发布于 2021-09-28 - 来自专栏donghui的博客
ReviewBoard代码评审实践总结 顶
代码评审 代码评审（CodeReview），顾名思义是对代码进行评审，是软件工程的活动之一。 通过代码评审可以保证代码质量，促进团队知识共享……好处多多。 GIT有个Google开发的代码评审工具Gerrit，可以在提交前进行代码评审，评审通过之后才允许提交到版本库。 pre-commit-review是指代码提交到代码库前进行代码评审； post-commit-review是指代码提交到代码库后进行代码评审。 其中pre-commit-review的工作流为： 在代码修改后，提交人创建代码评审请求 相应的评审人通过评审请求对代码进行评审，如果评审不通过，提交人可以更新该评审请求 评审通过之后， ，在实施或推广之时，遇到如下问题： 代码提交人在评审请求通过之后还需要再提交代码至版本库，同时无法确保被评审的代码和提交的代码的一致性 没有实现在代码评审请求评审通过后自动提交代码
2.8K20发布于 2019-04-19 - 来自专栏啄木鸟软件测试
使用ChatGPT关于登录产品代码的代码评审
12.1 前端代码 前端代码包括login.jsp文件提取的HTML代码和index.js，由于index.css没有改动，不做评审。 12.1.1申请前端代码评审 请对下面前端代码进行评审 1）login.jsp文件提取的HTML代码 <! 12.2.1 jsp文件进行代码评审 1）申请jsp文件进行代码评审 对下面jsp文件进行评审。 12.2.2 Java文件进行代码评审 1）申请Java文件进行代码评审 对下面Java文件进行评审。 … self.db.init_login(username="",password="P@ss1") 12.3.1申请测试代码评审 请对下面测试代码进行评审。
52710编辑于 2024-12-19 - 来自专栏MavenTalk
代码评审鲜为人知的好处
代码评审究竟有什么好处？ 在前期发现问题，提高软件质量，降低软件成本。 事实上，代码评审的好处远不止这些。 对工程和业务逻辑的熟悉 和盲目地走读代码不同，代码评审之前起码是对大致的业务和实现有一定了解，是带着问题去看代码的，更容易帮助自己理清代码实现，熟悉业务逻辑。 大声地鼓励，宽容地讨论，知识共享，给团队一个互相学习进步的氛围 代码评审不是挑错，看到优秀的代码，要说出来，让大家都看得到，这是那些优秀代码的创造者们应得的奖励。 代码评审不能完全解决这个问题，但可以通过评审发现设计方面的问题，可以反思设计的疏漏，提高团队成员的设计能力。 发挥团队中“牛人”的作用 这些团队中的“牛人”可不见得写得了所有的代码，但是他们可以评审绝大多数代码，把他们的作用发挥出来。
71230发布于 2019-07-19 - 来自专栏Linyb极客之路
代码审查或评审的最佳实践
谁参与了代码审查？ 有了明确的目的和一系列要在审查中寻找的东西，决定谁应该参与审查要简单得多。我们需要决定： 1. 谁评审代码？ 人们很容易认为应该是一个或多个资深或经验丰富的开发人员。 如果评审的重点是分享知识，那么您可能希望每个人都查看代码。对于其他用途的评审，您可能会有一组评论者，其中一些评审会随机挑选。 2.谁签署评审？ 如果我们有多个评审者，重要的是要了解谁最终负责说评审已经完成。这可以是一个人，一组特定的人，一定数量的评审者，特定代码区域的特定专家，或者甚至可以通过一次否决来终止审查。 在具有高度信任的团队中，代码作者可能是决定何时足够的反馈足够并且代码已经更新以充分反映所引起的关注的人。 3. 谁解决了意见分歧？ 评审可能有多个评审者。 实施适合我们的代码审查流程的最佳方法是考虑： 我们为什么要做审查？评审人的工作更加容易，目的明确，代码作者在审核过程中会有更少的令人讨厌的意外 什么是我们寻找什么？
1.3K10发布于 2019-07-22 - 来自专栏dongfanger
代码评审，揭示黑盒背后的真相
三、代码评审的定义和意义 代码评审，Code Review（CR），是一种通过检查代码来提高代码质量的过程。 对于测试人员来说，参与代码评审，可以尽量提前发现问题，减少修复代价，提高效能。 四、代码评审的形式 多人讨论 组织会议，研发牵头讲解代码，架构和测试参与，讨论交流。这是最普遍的一种形式。 五、代码评审的方法 面向业务，面向业务，面向业务。重要的事情说三遍。 刚开始做代码评审，很容易把注意力集中在找代码规范问题上面，比如命名不规范、注释不清楚、代码实现冗长等。 幂等、并发等场景 代码评审要求测试人员具备代码能力，理解编程语言，掌握软件设计，熟悉代码结构和架构，多与开发同学交流，共同优化代码质量。 都需要修改 七、总结 从业务需求角度出发，剖析代码逻辑，运用测试经验，以更高的效率，发现更多的缺陷，这就是代码评审带来的烧脑体验。
40410编辑于 2023-08-09 - 来自专栏四火的唠叨
代码评审鲜为人知的好处
代码评审究竟有什么好处？ 在前期发现问题，提高软件质量，降低软件成本。 事实上，代码评审的好处远不止这些。 对工程和业务逻辑的熟悉 和盲目地走读代码不同，代码评审之前起码是对大致的业务和实现有一定了解，是带着问题去看代码的，更容易帮助自己理清代码实现，熟悉业务逻辑。 大声地鼓励，宽容地讨论，知识共享，给团队一个互相学习进步的氛围 代码评审不是挑错，看到优秀的代码，要说出来，让大家都看得到，这是那些优秀代码的创造者们应得的奖励。 代码评审不能完全解决这个问题，但可以通过评审发现设计方面的问题，可以反思设计的疏漏，提高团队成员的设计能力。 发挥团队中 “牛人” 的作用 这些团队中的 “牛人” 可不见得写得了所有的代码，但是他们可以评审绝大多数代码，把他们的作用发挥出来。
45610编辑于 2022-07-19 - 来自专栏donghui的博客
Jupiter（Eclipse代码评审插件）简单总结
1、Jupiter是开源的Eclipse代码评审插件，以XML形式存储review数据。 2、review数据需要在版本控制系统（CVS/SVN）中传递。 3、三个阶段：个人评审阶段（Individual Phase）、团队评审阶段（Team Phase）、问题修复阶段（Rework Phase）。 4、review问题列表支持各种filter规则（根据review问题状态、责任人等，通过这个filter可以列出具体阶段需关注的问题） 5、支持代码行级别的评审标注功能，能够在复查意见（也称为review issue）和源代码之间来回跳转。 官网：http://code.google.com/p/jupiter-eclipse-plugin 不足： 1、每次评审需要指定评审文件，评审文件的选取比较麻烦。
1.2K30发布于 2019-04-19
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号