您的位置: 首页  >  文章  >  新人入职如何进行CodeReview

新人入职如何进行CodeReview

分类: 文章 • 2024-09-22 07:44:45

新人入职如何进行CodeReview

新人入职如何进行CodeReview
2021校招互联网大厂开奖，程序员薪资倒挂，含泪迎来1024

正文开始：

大厂比较注重长期价值，注重codereview (cr)，我认为Code Review最大的作用促进工程师日常代码交流和技术成长，与此同时对产品质量进行把关。很多团队在Code Review前期重点会是找问题（代码规范、潜在缺陷、BUG，代码设计等等），越到后期它更大的意义将演变成工程师交流土壤的培育和人员成长的促进。

CodeReview的目标

CodeReview的目的是提升代码质量，尽早发现潜在缺陷与BUG，降低修复成本，同时促进团队内部知识共享，帮助更多人更好地理解系统。

  • 传播知识。
    相信很多人第一次提交 Code Review 都有类似的经历：短短几百行代码，却被提了密密麻麻几十条 comments，更新了十多次代码，才最终被 accept 。其实当代码被 accept，提交代码的工程师通过这次 review 就学习到了代码规范和很多好的实践。同时，通过 review 更资深工程师的代码，年轻的工程师也更直观地学习架构和编码；另外，工程师之间也可以通过 review 代码来共享项目知识，看代码实现在绝大多数时候是了解项目的最好方式。

  • 增进代码质量。
    这点也很容易理解，有经验的工程师可以在架构设计、代码细节等各个方面帮助到初学者。不同工程师也会有知识盲点，互相 review 进步也很快。另外，被 review 的代码质量更高还有一个很多人注意不到的心理因素：在状态不佳的时候，工程师难免会匆忙写些“潦草”的代码，但是当你知道自己的代码会被review 的工程师提交 comment 打回来，自然会更仔细些 : -)

  • 找出潜在的 bug。
    这是大部分团队进行 Code Review 的目的。就像上面提到的，Code Review 在这方面效果不错。其实我认为大部分代码 bug 应该由单元测试，功能测试，性能测试和回归测试来保障。不过由于静态分析不理解业务，另外有些 bug 在测试中并不容易复现，这两种情况下，经验丰富的工程师来 review 代码就尤其重要了。

如何CodeReview？

  • 明确代码风格和书写规范
    比如阿里的代码书写规范，华为的代码书写规范

  • 熟悉团队的CI/DI工具以及CodeReview工具
    Crucible：Atlassian 内部代码审查工具；
    Gerrit：Google 开源的 git 代码审查工具；
    GitHub：程序员应该很熟悉了，上面的 “Pull Request” 在代码审查这里很好用；
    LGTM：可用于 GitHub 和 Bitbucket 的 PR 代码安全漏洞和代码质量审查辅助工具；
    Phabricator：Facebook 开源的 git/mercurial/svn 代码审查工具；
    PullRequest：GitHub pull requests 代码审查辅助工具；
    Pull Reminders：GitHub 上有 PR 需要你审核，该插件自动通过 Slack 提醒你；
    Reviewable：基于 GitHub pull requests 的代码审查辅助工具；
    Sider：GitHub 自动代码审查辅助工具；
    Upsource：JetBrain 内部部署的 git/mercurial/perforce/svn 代码审查工具。

  • Code Review形式

    • 一对一评审
      提交的merge request 不要超过2天的工作量
      无论何时你发起了一个关于 6 行代码的评审请求，你总会得到很多同事关于这 6 行代码的指指点点。但当你 push 了一个花了几周时间的代码分支，你常常会得到一个很快回复的：LGTM!（Looks Good To Me）
    • 团队评审会议
      每周一次（或者每个迭代一次），时间控制在60~90分钟

  • 提交Merge Request的格式
    用简短但是足够说明问题的语言（理想是控制在3句话之内）来描述：

    你改动了什么，解决了什么问题，需要代码审查的人留意那些影响比较大的改动。
    特别需要留意，如果对基础、公共的组件进行了改动，一定要另起一行特别说明。

  • 注意事项
    尽早的进行评审，不单是代码评审，复杂的故事需要提前进行方案评审
    每次Review的代码不要超过两天的工作量（大的故事开独立的feature分支，各个开发基于这个feature分支进行开发；小的故事直接基于develop分支进行开发）
    每次Review时间不要超过90分钟
    发现问题并能够给出问题的解决方案
    每次Review不要超过500行代码

  • check list
    代码格式
    代码可读性
    有没有漏掉重要的case
    测试用例和防坑
    异常处理
    工程结构

  • CodeReview 时关注什么

    • 计的合理性和业务逻辑的正确性
      • 代码的设计是否符合设计要求
      • 业务逻辑是否正确
      • 关注业务可拓展性
      • 关注使用到的数据结构、设计模式和代码性能
    • 检查代码可读性和可维护性
      • 代码的可读性强
      • 注释的正确性和详略得当
      • 命名规范
      • 重复的代码
      • 繁琐的逻辑
      • 过长的函数和代码文件
      • 是否对代码进行了格式化
    • 分享设计、技术、知识和经验

参考文章：
https://www.jianshu.com/p/e9f9aef9a0e9
https://blog.****.net/huver2007/article/details/75095303
https://blog.****.net/zxh19800626/article/details/84995166
https://www.zhihu.com/question/41089988
https://www.jianshu.com/p/c73def1ae844

相关推荐