大家平时做code review吗?

问题描述

大家codereview都怎么做的?都有哪些内容?

解决方案

解决方案二:
互查,但基本上也就是看看注释,大家都是写程序的,不好撕破脸说别人写的没效率或者有隐患吧
解决方案三:
引用1楼coolbamboo2008的回复:

互查,但基本上也就是看看注释,大家都是写程序的,不好撕破脸说别人写的没效率或者有隐患吧

你意思是不是有bug也留着让做测试的人指出来?
解决方案四:
我们一般很少去做这些事情~~我问过我一些朋友也好少去做这些事,只能说以前的代码写的太渣,都懒得再去看了
解决方案五:
检查代码格式的规范性是否有明显的空指针异常等异常是否及时捕获,处理是否有魔鬼数字等项目很近的时候,赶进度,松一点的时候,搞代码质量进行代码检查,codereview
解决方案六:
实现一个功能后,开个会,把你思路讲解出来,判断是否思路有bug,根据思路讲解代码。如果都觉得没问题那就过
解决方案七:
还有一种方式就是结对编程
解决方案八:
引用2楼kensallay_2的回复:

Quote: 引用1楼coolbamboo2008的回复:
互查,但基本上也就是看看注释,大家都是写程序的,不好撕破脸说别人写的没效率或者有隐患吧

你意思是不是有bug也留着让做测试的人指出来?

如果真有bug是要提交给coder的。但一般复查这种方式看不出来的,如果团队成员水平相近的话。所以基本也是到测试才能知道bug在哪
解决方案九:
一般自己的代码自己管,经过自己测试之后,基本上不会有太大问题。
解决方案十:
§代码审查,应该做的几件事儿1)正确性是否满足客户需求是否和需求分析以及设计资料的内容保持一致一致的意思:不仅要求功能正确,而且要求完备极值(最大值、最小值、特殊值(比如0、负数、null、NaN)、异常值(字母、回车/换行等控制字符))等等特殊情况是否都已经被考虑到了,这些情况下程序的动作是否满足需求还有哪些情况没有被考虑?没有被实现?2)结构性现在的功能加入到系统后,对整个系统有什么好的影响,以及不好的影响(程序员一般都过于乐观,这点可能需要第三者帮着冷静的分析一下才行)以后再追加新的功能时,是否可以不大改结构就能够实现,千万别“将就”3)易读性换一个完全不懂这个系统的人,是否能通过代码立即理解原作者的意图(需要代码审查者把自己假想为一个完全的新人才行)推敲一下,是否有过多的不必要的注释:经年累月后,人们逐渐发现,只有代码本身才可以真正被信赖最小限度的注释,以及自说明的代码才是最好的方式1次书写N次阅读,多站在今后的阅读者的立场上考虑问题关心一下系统日志(log):当出现Bug时,可以很容易的分析出是哪里出了什么问题吗?如果写代码的人自己都不能分分秒知道问题出在哪里,还能指望谁?例:看系统日志知道是系统运行时发生异常造成系统崩溃了log应该分分秒告诉你:是谁的问题?什么异常?什么时候发生的?哪里出的?为什么会出?怎么解决?(5W1H)4)性能有没有更好的,更合理的实现方法性能等是否有问题、有没有内存泄露、资源泄露等用测试的手法也不易发现的问题§代码审查,不应该做的几件事儿1)通过工具能够自动检查的问题比如项目组的编码规范不允许使用TAB,而需要统一使用空格来进行缩进这样的检查如果人工来做的话,会花费大量不必要的时间还好有EclipseCheckstyle这样的自动工具代码审查时仅需要确认一下Checkstyle的检查是否实施所有的检查结果是否都是OK的如果有NG的地方,是否是被允许的是否需要更新Checkstyle的规则2)通过简单测试就能够发现的问题比如系统是否能启动起来,大体上的功能是否已经实现如果这些最基本的问题还没有解决的话,直接开代码审查就是在浪费时间3)过去经常发生,或者已经经常指出的问题网上有很多成型的东东,可以参考这些问题可以通过CheckList的形式,让开发人员做自检并把检查结果报告给代码审查的责任人可以每次考察CheckList中不同的一两项,来确认开发人员已经充分理解自检的目的比如:参数是否为null的判定,除数是否为零的判定,异常处理等最基本的需要注意的问题如果之后发现了Bug,一定要考虑是否需要更新CheckList以杜绝发生相似的问题另外,如果CheckList已经不能发现任何问题的话,可以考虑分类(新加入项目组的开发人员使用的,以及成手使用的),以节约成手的时间总之,这个东东最好小而强大,没用的东西要定期删除原创,转发请注明出处
解决方案十一:
现在这家公司有做,会先看看基本功能正常不,有没有符合需求文档。接着会看看代码逻辑有没有不合理的,速度慢的。
解决方案十二:
codereview很多公司都说要做,但都做得不好。其实真正做好codereview对提高品质是很有帮助的。我觉得应该一如既往的做下去,而且要保证做好。
解决方案十三:
一般是自己做~有BUG对谁都不好嘛~我主要是来接点分的~
解决方案十四:
引用6楼huxiweng的回复:

还有一种方式就是结对编程

我想说,结对编程,估计现在国内还木有实现,有也是那些搞互联网的大公司,和注重创意的公司。像我们公司巴不得一个人当两个人用。
解决方案十五:
老板才是codereview的最大敌人

时间: 2024-10-27 18:26:21

大家平时做code review吗?的相关文章

我们是怎么做Code Review的

前几天看了<Code Review 程序员的寄望与哀伤>,想到我们团队开展Code Review也有2年了,结果还算比较满意,有些经验应该可以和大家一起分享.探讨. 我们为什么要推行Code Review呢?我们当时面临着代码混乱.Bug频出的状况. 当时我觉得要有所改变,希望能提高产品的代码质量,改善开发团队面临的困境.并且我个人在开发上有很多经验,也希望这些知识能够在团队内传播. 各种考虑后,我们最后认为推行Code Review能改善或解决我们面临的很多问题. 这篇文章的目的不是告诉大家

[读后感]从Code Review 谈如何做技术

还有9个电,争取把这篇发出去,里面有太同共鸣,只不过之前没能写出来, 一是文笔有限,总结不够明确,本文至少总结出了我想总结的6个观点,看来总结能力还是要提高: 二是不确认这是对的,所以不敢贸然写出来,看来奔四的程序员都有这些共同的想法,并非我一人,还有许多人... 着实说,代码审查,以前想过,但没做过: 代码审查确实很不错,不懂开发的测试人员其实从某种角度是用于粗暴地替代代码审查, 结果可知,花在修复 Bug 上的时间要比编码时间多 N 倍, 我想我们以敏捷方式来对付它,逐层皮儿地扒着做,做完一

从 Code Review 谈如何做技术

编者注:本文来自酷壳-CoolShell.cn 的陈皓 这两天,在微博上表达了一下Code Review的重要性.因为翻看了阿里内部的Review Board上的记录,从上面发现Code Review做得好的是一些比较偏技术的团队,而偏业务的技术团队基本上没有看到Code Review的记录.当然,这并不能说没有记录他们就没有做Code Review,于是,我就问了一下以前在业务团队做过的同事有没有Code Review,他告诉我不但没有Code Review,而且他认为Code Review没

Code Review代码审查的思路

1.关于Code Review 1.1 Code Review的目的 Code Review主要用来在软件工程过程中改进代码质量,通过Code Review可以达到如下目的目的: (1)在项目早期就能够发现代码中的BUG (2)帮助初级开发人员学习高级开发人员的经验,达到知识共享 (3)避免开发人员犯一些很常见,很普通的错误 (4)保证项目组人员的良好沟通 (5)项目或产品的代码更容易维护 1.2 Code Review的前提 进入Code Review需要检查的条件如下: (1)Code Re

聊Code review(上)

篇前的话:本文主要关注互联网应用程序如何做Code review(代码审查)方面.上篇主要描述什么是code review, 为什么要去做,主要包含哪些内容:下篇,主要讲如何组织人员做代码review,对程序员,以及团队有什么影响,重点在下篇. 从事过几年程序开发的猿猿们(注1),听过.或抱怨过: "某某系统的代码太烂"或"某某人的代码太烂".本文着重说应用软件的code review,将从这些问题去探讨:为什么要做代码review?如何去做代码review,应该注

Code Review 理论与实战

一. Code Review 简介 1 Code Review 的目的 凡事知其然还要知其所以然 , 我们首先需要知道什么是 Code Review 和我们使用它的目的是什么. Code Review 是一种用来确认方案设计和代码实现的质量保证机制,通过这个机制我们可以对代码,测试过程和注释进行检查. Code Review 主要用来在软件工程过程中改进代码质量,通过 Code Review 可以达到如下目的: 在项目早期就能够发现代码中的BUG 帮助初级开发人员学习高级开发人员的经验,达到知识

7 个 code review 的技巧(转)

Code review,中文译为「代码审查」,是指对代码进行系统性的审查,通常是和其他开发者来共同进行.这里作者就讲了在 Asana 中他们是怎么来做代码审查的. 1.先确定 code review 的目标优先级 在 code review 之前先和你的团队成员明确 code review 中事项的优先级. 作者认为 code review 中应该做的事: 熟悉同事在编程时的思考方式,这样其余同事以后如果有需要就可以更轻松.快速的修改代码. 向同事介绍修改了哪些文件,增加了什么样的功能,这样在问

Code Review 程序员的寄望与哀伤

一个程序员,他写完了代码,在测试环境通过了测试,然后他把它发布到了线上生产环境,但很快就发现在生产环境上出了问题,有潜在的 bug. 事后分析,是生产环境的一些微妙差异,使得这种 bug 场景在线下测试中很难被发现.毕竟想要在测试环境完美的复制生产环境的所有情况也是不太可能的,导致出现了疏漏.对于这类情况,我们在想是否可以通过在线下做一些 Code Review(代码审查)假想线上的环境差异,通过在头脑中的假想上线运行来获得一些概念验证,这样是否能够减少上线后出现 bug 的概率呢? 感性 Co

同行代码审查(Peer Code Review)实战经验

同行代码审查(Peer Code Review)实战经验 我有时候会听到我们的团队成员这样议论: "项目的Code review 只是浪费时间." "我没有时间做Code review." "我的发布时间延迟了,因为我的同事还没有完成我代码的Code review." "你相信我的同事居然要求我对我的代码做修改吗?请跟他们说代码中的一些联系会被打断--如果在我原来代码的基础之上做修改的话." (LCTT 译注:Code Rev