读程序员的README笔记09_代码评审

9月前作者：躺柒分类：Toy博客阅读(49) 违法举报

这篇具有很好参考价值的文章主要介绍了读程序员的README笔记09_代码评审。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

读程序员的README笔记09_代码评审

1. 行为准则

读程序员的README笔记09_代码评审文章来源地址https://www.toymoban.com/news/detail-751911.html

2. 代码评审

2.1. 代码评审是一种给予和接受反馈的专门的形式

2.1.1. 大多数团队会在合并代码的修改之前进行代码评审

2.1.2. 评审不是一个证明你有多聪明的机会，也不是一个橡皮图章式的官僚主义障碍

2.2. 高质量的代码评审文化有助于所有具有不同经验水平的工程师的成长，并促进他们对代码库的共同理解

2.3. 糟糕的代码评审文化会抑制创新，减慢开发速度，并且导致滋生怨恨情绪

2.3.1. 执行不力的代码评审会成为一种有害的阻碍

2.3.2. 轻率的反馈不提供任何价值，还会拖慢开发人员的速度

2.3.3. 缓慢的周转时间会使代码的变化停滞不前

2.3.4. 如果没有正确的评审文化，开发人员可能会陷入反复拉锯扯皮的分歧中，这可能会毁掉一个团队

3. 为什么需要评审代码

3.1. 评审可以捕捉bug并保持代码整洁

3.1.1. 代码评审的价值不仅仅是让人来代替自动测试和代码质量检查工具

3.2. 优秀的代码评审可以作为一个教学工具，传播认识，记录实现的决策，并提供代码的更改记录以确保安全性与合规性

3.2.1. 你可以从别人评审你的代码给予的反馈中学习

3.2.2. 评审者会指出那些你可能不知道的有用的类库和编码实践

3.3. 代码评审也是了解你的团队的编码风格的一种简单方法

3.4. 评审整个代码库的变更可以确保不止一个人熟悉生产环境中代码的每一行，对代码库的共同理解有助于团队更有凝聚力地扩展代码

3.4.1. 让别人知道你在改什么，意味着一旦出现了问题，你不是团队中唯一可以仰仗的人

3.5. 被记录下来的评审意见也是一种文档

3.5.1. 解释了为什么事情会这样做

3.5.2. 需要以某种特定方式编写代码的原因并不总是显而易见的

3.5.3. 可以作为实现决策的档案

3.5.4. 有旧的代码评审作为参考，可以为开发人员提供一份书面的历史记录

3.6. 安全性和合规性政策通常规定了代码评审作为一项防范措施来防止任何一名开发人员恶意修改代码库

4. 当你的代码被评审时

4.1. 一个精心准备的评审请求可以使开发人员很容易理解你在做什么并提供有建设性的反馈

4.1.1. 保持单个代码的小幅改动，将特性和重构工作分到不同的评审中，并写出描述性的提交信息，务必将注释和测试包括在内

4.2. 用评审草案降低风险

4.2.1. 代码修改的草案是一种思考和提出相应修改的很棒的方式，这种方式不需要投入那么多时间来编写测试、打磨代码和添加文档

4.3. 提交评审请勿触发测试

4.3.1. 在本地调试某项失败的测试比在CI环境中更容易一些

4.3.2. 不能在远程计算机上附加调试器或轻松地获取调试信息

4.4. 预排大体量的代码修改

4.4.1. 预排会议

4.4.1.1. walk-through

4.4.1.2. 一种面对面的会议，开发人员在会上共享他们的屏幕，并引导队友了解正在进行的修改内容

4.4.1.3. 是启发想法和让你的团队适应代码修改的好方法

4.5. 评审意见是针对代码的，而不是针对你个人的

4.5.1. 甚至都不算是你的代码，将来整个团队会拥有这些代码

4.5.2. 得到很多评论是一种完全正常的现象，尤其当你是团队中经验不足的开发者之一时

4.6. 保持同理心，但不要容忍粗鲁

4.7. 不要羞于要求别人评审你的代码

4.7.1. 让代码评审一直悬而未决是不体谅他人的做法

5. 评审别人的代码时

5.1. 分流评审请求

5.1.1. 当你收到评审请求的通知时，你作为评审者的工作就开始了

5.1.2. 大多数的修改是不那么紧急的

5.1.2.1. 如果紧急度不明确，请询问提交者

5.1.3. 你不需要评审每一项代码修改，要专注于那些你可以从中学习的修改和你熟悉的代码

5.2. 给评审预留时间

5.2.1. 代码评审类似于运维工作，其规模和频率在某种程度上无法预知

5.2.2. 大型的代码评审可能需要进行额外的计划

5.3. 理解修改的意图

5.3.1. 不要一上来就以提交评论的方式开始你的评审工作，首先要阅读并提出问题

5.4. 提供全面的反馈

5.4.1. 需要对代码修改的正确性、可实施性、可维护性、可读性和安全性提供反馈

5.4.2. 指出那些违反代码风格手册、难以阅读或令人困惑的代码

5.4.3. 阅读测试用例并寻找bug以验证代码的正确性

5.4.4. 寻找OWASP十大违规行为

5.4.4.1. SQL注入攻击、敏感数据泄露和跨站脚本攻击的漏洞

5.5. 要承认优点

5.5.1. 代码评审不一定全都是负面的评论

5.6. 区分问题、建议和挑剔

5.6.1. 并非所有的评审意见都有相同的重要性

5.6.2. 重大问题需要比中性的建议和肤浅的挑剔投入更多的关注

5.6.3. 在反馈前加上“可选”(optional)、“接受或不接受”(take it or leave it)或“非必须”(nonblocking)的字样

5.7. 不要只做橡皮图章

5.7.1. 可能会迫于压力，在没有真正看清楚的情况下就批准了某项评审

5.7.2. 要抵制那种用草率批准的方式快速给评审盖上橡皮图章的诱惑，橡皮图章式的评审是有害的

5.7.3. 期望一次性就能充分评审一项巨大的代码改动是不合理的

5.8. 不要只局限于使用网页版的评审工具

5.8.1. 代码评审通常在一个专门的UI中处理

5.8.2. 代码评审本身也只是代码而已

5.9. 不要忘记评审测试代码

5.9.1. 评审者经常会忽略测试代码，特别是当变更比较大的时候

5.9.2. 测试代码应该像代码的其他部分一样被评审

5.9.3. 一定要检查测试代码的可维护性和清洁度

5.10. ⑩推动决断

5.10.1. 不要成为促成“夭折”的原因，要帮助提交者评审以迅速批准他们的代码

5.10.2. 坚持质量，但不要成为不可逾越的障碍

5.10.3. 尊重正在进行的修改的范围

5.10.4. 如果对代码修改有重大分歧，而你和作者又不能解决分歧的话，请主动提出把这个问题移交给其他专家，他们可以帮助解决相关分歧

到了这里，关于读程序员的README笔记09_代码评审的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：如若内容造成侵权/违法违规/事实不符，请点击违法举报进行投诉反馈，一经查实，立即删除！

分享到：

领支付宝红包赞助服务器费用

读程序员的README笔记11_软件交付（下）

1.3.5.1. 通过持续交付，人力被完全从部署环节中移除 1.3.5.2. 打包、测试、发布、部署，甚至展开环节都是自动化的 1.3.6.1. Puppet、Salt、Ansible和Terraform等现成的解决方案可以与现有的工具集成，并且它们是专门为了自动化部署而设计的 1.4.4.1. 只需再次指向旧的版本 1.5.1.1.

2024年02月04日
浏览(59)
读程序员的README笔记04_防御式编程

1.2.1.1. 切记让你的代码安全而有弹性 1.2.1.2. 编写拥有良好防御性的代码是一种对那些运行你的代码的人（包括你自己！）富有同情心的表现 1.2.1.3. 防御性的代码较少发生故障，就算它发生故障，也更有可能恢复 1.2.1.4. 安全的代码利用编译时的校验来避免运行时的故障，使

2024年02月05日
浏览(56)
读程序员的README笔记01_学习如何学习

6.3.2.1. 错误是不可避免的。成为一名软件工程师的路途艰辛，我们有时会失败 6.5.4.1. 代码从不说谎。注释有时却会。 6.5.4.1.1. Code never lies. Comments sometimes do 6.5.4.1.2. 去读源代码，因为它并不总是与设计文档相吻合 6.5.4.1.3. 不要只读你自己的代码库，还要去阅读高质量的开

2024年02月05日
浏览(50)
读程序员的README笔记10_软件交付（上）

3.1.1.1. 打包一个构件称为发布 3.1.3.1. 部署的软件还不能被用户访问 3.1.3.1.1. 只是被安装了而已 3.1.3.2. 一旦部署，软件就会通过将用户转移到新的软件上而进行展开 3.1.4.1. 交付过程是更大的产品开发周期中的一部分 6.10.2.1. 每季度或每年发布一次

2024年02月04日
浏览(156)
读程序员的README笔记14_技术设计流程（下）

1.4.2.1. 该项目将需要至少一个月的工程时间 1.4.2.2. 变更将对软件的扩展和维护产生长期的影响 1.4.2.3. 变更将显著影响其他团队 1.5.2.1. 设计文档是一种工具，可以帮助你思考、获得反馈、让你的团队了解情况、培养新的工程师，并推动项目规划 1.5.5.1. 阅读大量的设计文档

2024年02月04日
浏览(40)
读程序员的README笔记18_职业生涯规划

3.1.5.1. 他们的工作职责之一是管理他们的团队，而管理的一部分就是对你投入时间 3.1.5.2. 对管理者而言，反复取消一对一面谈可以是一个有价值的信号 3.3.2.1. 每个目标都附有3到5个关键结果，它们是标志着目标达成的具体指标 3.3.2.2. 不要把关键结果变成待办事项清单 3.

2024年02月04日
浏览(50)
读程序员的README笔记05_日志、监控与配置

6.1.1.1. 测量的是某个事件发生的次数 6.1.1.2. 通过使用计数器获得缓存命中数和请求总数，你就可以计算出缓存命中率 6.1.2.1. 一个基于时间点的测量值 6.1.2.2. 既可以上升又可以下降 6.1.3.1. 根据事件的大小幅度分成不同的范围 6.1.3.2. 每一个范围都会有一个计数器，每当某

2024年02月05日
浏览(51)
读程序员的README笔记13_技术设计流程（上）

3.4.1.1. 外界干扰是深度工作的“杀手” 3.4.1.2. 避免所有的交流方式 3.4.1.2.1. 关闭聊天 3.4.1.2.2. 关闭电子邮件 3.4.1.2.3. 禁用电话通知 3.4.1.2.4. 换个地方坐 3.4.2.1. 有形产出是一份设计文档 4.2.3.1. 如果有一个以上的问题，询问哪些问题是最优先的 4.3.7.1. 注意与外人交流时不

2024年02月04日
浏览(66)
读程序员的README笔记12_On-Call

4.4.2.1. 回应不一定代表解决方案 4.4.3.1. 每次更新时，提供一个新的时间预估 4.5.3.1. 如果请求者没有回应，就说你将在24小时内因缺乏回应而关闭该任务票，然后真的这样做 5.3.1.1. 工程师必须找到问题，确定其严重性，并确定谁能修复它 5.3.1.2. 确认问题并了解其影响，以

2024年02月04日
浏览(41)
读程序员的README笔记16_构建可演进的架构（上）

3.1.1.1. 致软件依赖于其他的API或代码行为 3.1.1.2. 依赖性显然不可避免，甚至是可取的，但必须取得平衡 3.1.1.3. 高依赖性的系统很难修改 3.1.1.3.1. 它们有紧密的耦合性和高度的变更放大效应 3.1.1.3.2. 紧密的耦合性是指那些严重依赖彼此的模块，它们导致了更高的变更放大的

2024年02月04日
浏览(50)