精华内容
下载资源
问答
  • 代码走查的目的
    2018-12-28 15:05:00

    代码检查与代码走查是基于人工测试的白盒测试方法。
    目的:找出错误,而不是改正错误,是测试而不是调试。
    优点:能够精确地定位的错误,降低调试成本。
    可以成批的发现错误,而计算机测试往往是逐个发现错误并改正。

    注意:代码检查、代码走查、基于计算机的测试三者是互补的

    代码检查:以组为单位阅读代码,是一系列规程和错误检查技术的集合。
    代码检查小组由小组主导者、代码编写者、设计人员、测试专家组成。
    代码编写者组逐条语句讲解程序的逻辑结构,小组参考代码检查错误列表分析程序。
    代码检查错误列表有:数据引用错误、数据声明错误、运算错误、比较错误、控制流错误、接口错误、输入/输出错误、其他错误。

    代码走查的概念和代码检查的概念相似,但是代码走查小组中指定的测试人员会携带书面的测试用例来参加会议。
    这些测试用例必须是结果简单数量少,在代码走查过程中,这是测试用例并不起到关键性作用,测试用例在小组成员脑袋中推演的过程,很多问题是在向程序员提问的过程中发现的,而不是有测试用例本身发现的。

    桌面检查是由单人进行的代码检查或代码走查,效率低,但是比没有检查好。

    转载于:https://www.cnblogs.com/huangxiaoj/p/10190649.html

    更多相关内容
  • 代码走查有几个目的,第一个是让新同学快速熟悉代码并了解系统。第二个是做咨询防控的事前检查,避免引发线上故障。第三个是通过一起讨论和审查,加强团队代码阅读和编写能力 目的 代码走查有几个目的,第一个是让新...
  • 代码走查??

    热门讨论 2019-02-17 22:42:33
    代码走查目的是交换有关代码是如何书写的思路,并建立一个对代码的标准集体阐述。 在代码走查的过程中,开发人员都应该有机会向其他人来阐述他们的代码。 通常地,即便是简单的代码阐述也会帮助开发人员识别出错误...

    代码走查(code walkthrough)是一个开发人员与架构师集中讨论代码的过程。代码走查的目的是交换有关代码是如何书写的思路,并建立一个对代码的标准集体阐述。 在代码走查的过程中,开发人员都应该有机会向其他人来阐述他们的代码。 通常地,即便是简单的代码阐述也会帮助开发人员识别出错误并预想出对以前麻烦问题的新的解决办法。
    前言编辑
    当团队成员对代码进行讨论的时候,他们的讨论应该集中到一些重要的话题上,比如算法,基于对象的编程,类设计。 然而,许多代码走查不会做这些事,通常代码走查是枯燥的,烦人的,机械的。 这就是为什么许多开发人员讨厌这些。要使得代码走查变得很有效,那么这个过程就必须是有趣的,有创造性的。 很经常地,代码走查退化成了仅是关注于强制代码标准--一个可以被自动执行的实践。当这种情形出现后,团队通常会觉得代码走查没有价值,然后将代码走查从他们开发过程中去除掉。这样便失去了他们可以从正确地执行代码走查的过程获益的机会。

    原因编辑
    代码可读性这个话题一直以来都是备受关注,但是可读性高与不高却没有统一的标准。毕竟各个公司,甚至于各个项目的规范都是不一样的。我们不能说一个抽象性极好,灵活度极高却让人十天半个月都难以搞清楚的代码的可读性高,也不能说一个长达几千行却从头至尾逻辑性比较好的代码的可读性差。那么怎样的代码才算是合理的,才算是可读性高的呢?我想不同之中必有共性,那就是经过走查的、能够被项目组其他成员接受并能尽快看懂的代码就是可读性好的。
    为什么要做代码走查呢?
    要对代码可读性做走查,这需要人力、物力、以及项目宝贵的时间。对于一个项目来说,成本是一个重要的考虑因素,然而走查无疑会增加项目的成本,那么为什么还要做走查呢?其实任何一个项目经理都清楚一个成功的项目都是难以一蹴而就的,开发过程必然会遇到各种各样的问题和阻力,这也验证了那句老话:“软件开发中唯一不会变的就是,需求永远会变化”。我们也清楚问题越早的被发现那么损失就会越小,补救花费的时间就会越少,自然成本就越低。但是我们有多大的机会可以尽早的发现问题呢?这不是我们说早发现问题,问题就会跟我们招手说:“看你态度不错,就让你早发现吧!”这么简单的。迭代开发为什么会出现,瀑布式开发为什么难以应对大型的商业、行业项目?思考一下我们不难发现,客户难以一次性的、整体的、详尽的把自己想要的东西表达清楚,只有当客户看见实实在在的东西之后,他才更明确自己想要什么。好比我们去买裤子,你告诉一个人说:“我要一条简约的牛仔裤”;然后那个人去帮你买,但是具体的颜色你确定么,是黑色还是蓝色?衣服的口袋你确定么,是有扣子的还是没扣子的?只有当你真真切切的到专卖店里面,看到了试过了你才能确定:我要的就是那条180的蓝色的口袋上没扣子的XXX牌的裤子。也就是说我们很少能够尽早的从客户口中获得问题,除非我们指着我们做出来的东西说:看看,这是不是你想要的。既然如此,要控制的不是尽早的去发现问题,而是如何在问题出现之后尽早的找出问题所在,并解决问题,进而降低项目的成本。
    其实软件开发的主要时间是花费在调试上,然而调试中花费的大部分时间又在于读代码。倘若之前开发该模块的人员已远在天边,面对几千行混乱无序的代码任谁都难以承受。因而花费成本在代码走查上是值得的,而且是必须的。可惜的是,现在很少有人去关注代码的规范性、可读性,甚至在大公司都是如此。项目管理者过于注重项目的进度,只要开发者把自己的任务做完了,很少有人去关注他写的代码,甚至开发者自己都不会再去看。
    代码走查有何好处呢?
    首先代码走查可以提高软件的质量,以及可维护性。这样就可以减少查找错误的时间,提高解决bug的效率,提高开发效率的同时降低后期的维护成本。
    其次,经过走查的代码是能够迅速被项目组其他成员看懂的,这样有利于项目其他成员更全面的了解业务,对于成员之间交流也有很好的促进作用,当其中负责某个模块的开发人员离职之后其他人员能够迅速的接手相关的开发,并能够尽快的培养新人弥补空缺。
    最后,代码走查的过程是总结提高的过程,也是交流的过程,可以有效的提高开发人员的技术水平以及业务素养,增强公司的竞争力,通过总结交流甚至可以从不同项目中提取共性,做出相关产品,从而形成公司自己的核心竞争力,做到行业领先。
    如何去做代码走查?
    从参加人员来说,应该是项目的整体参与者,如果项目太大,整体参加的成本很高,那么可以以模块为组进行走查。因为他们之间负责的业务是紧密相关的,使用的技术是接近程度比较大的,因而开发的规范应该是统一的。
    从走查内容来说,应该是代码的命名规范,以及组织结构。每个项目都有自己的规范,但是如果项目内部使用不同的规范必然会增加发现问题、解决问题的难度,同时增加后期的维护成本。
    从走查时间来说,应该在每个模块开发完成之后进行,便于开发人员之间交流问题以及体会,并且每个人的讲解时间不要超过30分钟,因为模块的业务复杂度不会那么复杂,30分钟都讲不清的业务逻辑如何保证代码是清晰的。
    从走查的结果来说,经过走查的代码应该是参加成员大部分能认同的,并且参加者每个人都能读懂的逻辑清晰的代码,并且通过交流提高项目成员的凝聚力,提高其业务认知度,最好能形成项目之间可以共同使用的产品。

    两者关系编辑
    代码走查与代码审查
    代码走查(code walkthrough)和代码审查(code inspection)是两种不同的代码评审方法,
    代码审查是一种正式的评审活动,而代码走查的讨论过程是非正式的。
    最近对项目组进行代码评审,发觉需要对代码评审中找到的问题进行一下分类,大概可以分成以下几类问题:

    1. Comment
      注释没写,或者格式不对,或者毫无意义
    2. Coding Standard
      没遵守代码规范
    3. Existing Wheel
      重复现成的代码,或者是开源项目,或者公司已有代码
    4. Better practice
      Java或者开源项目,有更好的写法
    5. Performance bottle and Improvement
      性能瓶颈和提高
    6. Code Logic Error
      代码逻辑错误
    7. Business Logic Error
      业务逻辑错误
      代码审查列出问题的类型,并有解决情况报告
    展开全文
  • 代码走查和代码审查Code reviewing is an engineering practice used by many high performing teams. And even though this software practice has many advantages, teams doing code reviews also encounter ...

    代码走查和代码审查

    Code reviewing is an engineering practice used by many high performing teams. And even though this software practice has many advantages, teams doing code reviews also encounter quite a few code review pitfalls.

    代码审查是许多高性能团队使用的一种工程实践。 尽管这种软件实践有很多优点,但是进行代码审查的团队也遇到了很多代码审查陷阱。

    In this article, I explain the main code review pitfalls you should be aware of to ensure code reviewing does not slow your team down. Knowing which pitfalls and problems arise can help you to ensure a productive and effective code review experience. Those findings are based on a survey we conducted at Microsoft with over 900 participants.

    在本文中,我将解释您应注意的主要代码审查陷阱,以确保代码审查不会使您的团队减速。 了解哪些陷阱和问题会帮助您确保产生高效的代码审查经验。 这些发现是基于我们在Microsoft进行一项针对900多名参与者调查得出的。

    典型的代码审查过程 (A typical code review process)

    A typical tool-based code review process looks roughly like this: Once the developer has finished a piece of code, they prepare the code for being submitted for review. Then, they select reviewers who are notified about the review. The reviewers then review the code and give comments. The author of the code works on those comments and improves and changes the code accordingly. Once everybody is satisfied, or an agreement is reached, the code can be checked into the code base.

    典型的基于工具的代码审查过程大致如下:开发人员完成一段代码后,便准备要提交以供审查的代码。 然后,他们选择被通知有关评论的评论者。 然后,审阅者审阅代码并发表评论。 代码的作者处理这些注释,并相应地改进和更改代码。 一旦每个人都满意或达成协议,就可以将代码检入代码库。

    In another post, I described how a typical code review process looks like at Microsoft.

    在另一篇文章中,我描述了典型的代码审查过程在Microsoft的情况。

    代码审查并不总是一个平稳的过程 (Code reviewing isn’t always a smooth process)

    These steps read like a smooth process. But, like everything, in practice, things tend to be more complicated than anticipated. During the code review process there a quite a few pitfalls that can reduce the positive experience with code reviews for the whole team. If not done correctly, code reviewing can also take its tolls on the whole team’s productivity. So, let’s have a look at the difficulties and pitfalls of code reviews.

    这些步骤读起来很顺利。 但是,实际上,就像一切一样,事情往往比预期的要复杂。 在代码审查过程中,有很多陷阱可以减少整个团队进行代码审查的积极经验。 如果执行不正确,代码审查也可能会损害整个团队的工作效率。 因此,让我们看一下代码审查的困难和陷阱。

    The two main types of code review pitfalls are about the time spent on code reviews, and the value code reviews provide.

    代码审查陷阱的两种主要类型是代码审查所花费的时间以及代码审查所提供的价值。

    Be aware of code review pitfalls. Otherwise, code reviews can slow your team down. Click To Tweet

    注意代码审查的陷阱。 否则,代码审查会拖慢您的团队。 点击鸣叫

    等待代码审查反馈很痛苦 (Waiting for code review feedback is a pain)

    One of the main pitfalls code authors face is to receive feedback in a timely manner. Waiting for the comments to come in and not being able to work on the code in the meanwhile can be a huge problem. Even though developers can pick up other tasks to work on, if the code review takes too long, it impacts the developer’s productivity and also the developer’s satisfaction.

    代码作者面临的主要陷阱之一是及时接收反馈。 等待注释进入而无法同时在代码上工作可能是一个巨大的问题。 即使开发人员可以承担其他工作,但如果代码审查花费的时间太长,则会影响开发人员的工作效率以及开发人员的满意度。

    But, why does the code review feedback take so long?

    但是,为什么代码审查反馈需要这么长时间?

    开发人员必须兼顾多项责任 (Developers have to juggle several responsibilities)

    Well, code reviewing is not the only task the code reviewer has to perform. On the contrary, code reviewing — even though it can take a significant amount of time of a developer’s day-to-day work — is only one part of the responsibilities and tasks of a developer. So, it is very likely that the code reviewer is engaged in other activities and has to stop or finish those first before looking at the code review.

    嗯,代码审查不是代码审查者必须执行的唯一任务。 相反,即使开发人员的日常工作可能要花费大量时间,代码审查也只是开发人员职责和任务的一部分。 因此,代码审查者很可能从事其他活动,并且必须先停止或完成那些活动,然后再查看代码审查。

    If the timing is not ideal, and especially if the code reviewer hasn’t anticipated this change coming along, chances are, it takes a while before they look at the review. Remote teams also have to be aware of time differences. Otherwise, code reviews might even take longer.

    如果时机不理想,特别是如果代码审阅者没有预料到会发生这种变化,那么很可能需要一段时间才能查看审阅。 远程团队还必须意识到时差。 否则,代码审查可能甚至需要更长的时间。

    如果不将代码审查视为实际工作,则开发人员将面临问题 (Developers face problems if code reviews are not counted as actual work)

    Time constraints are real, and they affect both, the code reviewer and the author of the code. Doing a proper code review takes time. If teams want developers to do code reviews but do not value or count the time developers spend on code reviews, this becomes a real problem.

    时间限制是真实的,并且会影响代码审阅者和代码作者。 进行正确的代码审查需要时间。 如果团队希望开发人员进行代码审查,但不重视或不考虑开发人员花费在代码审查上的时间,那么这将成为一个真正的问题。

    You can’t expect quality code reviews if you don’t value the time a developer spends on them. Click To Tweet

    如果您不重视开发人员在代码审查上花费的时间,就无法期望获得高质量的代码审查。 点击鸣叫

    不奖励代码审查工作和性能 (Not rewarding code reviewing efforts and performance)

    It does not help to claim to value code reviews if you do not reward the effort developers spend on this task. Many companies focus on rewarding developers for the amount of code they write or the features they develop. This decreases the motivation and the ability of developers to do a good job helping each other (which includes code reviewing). Code review effort and performance should be a cornerstone for performance evaluation or promotion decisions.

    如果您不奖励开发人员在此任务上花费的精力,那么声称对代码进行评估就无济于事。 许多公司专注于奖励开发人员编写的代码量或开发的功能。 这降低了开发人员做好彼此帮助的动力和能力(包括代码审查)。 代码审查工作和绩效应成为绩效评估或升级决策的基石。

    If you want your team to do code reviews well, reward them for their work. Click To Tweet

    如果您希望您的团队对代码进行良好的审查,则对他们的工作给予奖励。 点击鸣叫

    社会因素和团队动力 (Social factors and team dynamics)

    But waiting on a code review had not always to do with the lack of time or missing reward system. Due to its social character, delayed reviews can be due to insecurities or team dynamics. Especially if the code review is overwhelming, or if the reviewer is new to the code, doing a code review can be overwhelming:

    但是等待代码审查并不总是与缺少时间或缺少奖励系统有关。 由于其社交性质,延迟审核可能是由于不安全感或团队动态所致。 尤其是如果代码审查不胜枚举,或者如果审查者是新来的代码,那么进行代码审查可能会很麻烦:

    I’m expected to participate, but I’m not quite sure how. I’ll wait until someone else starts. — study participant

    我预计会参加,但是我不确定如何参加。 我将等到其他人开始。 -研究参与者

    大评论很难复习 (Large reviews are hard to review)

    Another significant code review pitfall is large reviews. Imagine you are the reviewer, and you just got this review. You think, well, I am quickly going to look at that, but once you open the review, you see this large code change. Several files have been changed, and all changes tangle throughout the code base. What’s your first reaction?

    另一个重要的代码审查陷阱是大型审查。 假设您是审阅者,而您刚刚获得了此审阅。 您认为很好,我很快就去研究一下,但是一旦您打开审阅,您就会看到这个巨大的代码更改。 几个文件已更改,所有更改在整个代码库中都缠在一起。 您的第一React是什么?

    Probably: holy cow!

    可能是:圣牛!

    That’s right. That is exactly what we saw when analyzing thousands of code reviews. Not only does review time increase with the size of the code change, but also feedback quality decreases. Well, that’s probably understandable.

    那就对了。 这正是我们在分析数千个代码审查时所看到的。 评审时间不仅随着代码大小的变化而增加,而且反馈质量也会下降。 好吧,这可能是可以理解的。

    10 lines of code = 10 issues.

    10行代码= 10个问题。

    500 lines of code = “looks fine.”

    500行代码=“看起来不错”。

    Code reviews.

    代码审查。

    — I Am Devloper (@iamdevloper) November 5, 2013

    — I Am Devloper(@iamdevloper) 2013年11月5日

    Large code changes are just incredibly difficult to review. If, in addition, the code reviewer is not that familiar with the part of the code base the change took place in, reviewing can quickly become a nightmare.

    大型代码更改非常难以审核。 此外,如果代码检查者对更改所基于的代码库部分不太熟悉,那么检查很快就会成为噩梦。

    Large code reviews are hard to review. The quality of the review decreases with the size of the change, thus limiting the value teams get out of from code reviews. Click To Tweet

    大代码审查很难审查。 评审的质量随着更改的大小而降低,从而限制了价值团队从代码评审中脱身的价值。 点击鸣叫

    了解代码更改需要一些指导 (Understanding code changes needs some guidance)

    Understanding code changes, and especially the motivation for a code change, is another code review pitfall many reviewers face. If there is no description explaining the purpose of the change, code reviewing becomes much harder. We saw in the study that if the code reviewer does not understand the code change, or if she is overwhelmed by the amount of change, she cannot give insightful feedback.

    了解代码更改,尤其是代码更改的动机,是许多审阅者面临的另一个代码审阅陷阱。 如果没有说明来说明更改的目的,则代码审查将变得更加困难。 我们在研究中看到,如果代码审阅者不理解代码更改,或者如果她对更改量感到不知所措,那么她将无法提供有见地的反馈。

    It’s just this big incomprehensible mess. Then you can’t add any value because they are just going to explain it to you and you’re going to parrot back what they say.

    就是这么大的不可理解的混乱。 然后,您将无法添加任何价值,因为他们只会向您解释它,而您会模仿他们的话。

    — interviewed developer13

    —采访了developer13

    没有获得有价值的反馈会降低开发人员从代码审查中获得的利益和动力 (Not getting valuable feedback decreases the developers’ benefit from and motivation for code reviews)

    Without doubt, spending the time on code reviews and not getting useful feedback back is a problem. Even though the team might still benefit from the knowledge transfer, the developer’s motivation to do code reviews and the benefits from code reviews decrease when they do not get valuable feedback.

    毫无疑问,将时间花在代码审查上并没有得到有用的反馈是一个问题。 即使团队仍然可以从知识转移中受益,但是当开发人员没有获得有价值的反馈时,他们进行代码审查的动机和代码审查的好处就会减少。

    There are several reasons why reviewers do not or can’t give insightful feedback. It can be that the code reviewer did not have the right expertise. Another common reason is that the reviewer did not have enough time to look thoroughly through the change.

    审稿人没有或无法提供有见地的反馈有多种原因。 可能是代码检查者没有适当的专业知识。 另一个常见原因是审阅者没有足够的时间来彻底了解更改。

    Maybe the code reviewer does not understand the code. It can also be that the code reviewer does not know what issues to look for. Understanding what makes for valuable code review feedback and implementing best practices mitigates this pitfall.

    也许代码审查者不理解代码。 也可能是代码审阅者不知道要查找什么问题。 了解什么能使有价值的代码审查反馈有效,并实施最佳实践可以减轻这种陷阱。

    一旦主要的讨论是关于样式,就需要采取行动 (Once the main discussion is about styling, you need to act)

    Another problem that can happen during a code review is called bikeshedding. Bikeshedding means that developers focus on smaller issues and start disputing minor issues and overlook the serious ones.

    在代码审查期间可能发生的另一个问题称为Bikeshedding。 Bikeshedding意味着开发人员专注于较小的问题,并开始争论较小的问题,而忽略了严重的问题。

    The reasons for that are manifold. Common behind the scenes challenges that lead to bikeshedding is that developers do not understand the code change or that they do not have enough time for the code reviews. Sometimes bikeshedding can be a sign that there are issues with the team dynamics.

    原因是多种多样的。 导致脱机的幕后常见挑战是,开发人员不了解代码更改,或者他们没有足够的时间进行代码审查。 有时,骑车流失可能表明团队动力存在问题。

    If people dispute about minor issues during code reviews, you have to take a look at the underlying issue. Time pressure, too large reviews, rivalry? Click To Tweet

    如果人们在代码审查期间对次要问题提出异议,则必须查看潜在问题。 时间压力,太大的评论,竞争? 点击鸣叫

    达成共识可能需要面对面的讨论 (Reaching consensus might need a face-to-face discussion)

    Sometimes it can happen that it is hard to reach a consensus. This can occur between code reviewer and code author, or also between several code reviewers directly. Such situations must be handled carefully as team dynamics are closely connected to these happenings. Communication via tools and in written form can aggravate this problem. If there seems to be any tension, or contentious issues to discuss, switching to face-to-face (either in person or via a video call) might be a good idea.

    有时可能很难达成共识。 这可以在代码审阅者和代码作者之间发生,也可以直接在多个代码审阅者之间发生。 由于团队动态与这些情况密切相关,因此必须谨慎处理这种情况。 通过工具和书面形式进行的交流会加剧这个问题。 如果似乎存在任何紧张关系或有待讨论的问题,那么(面对面或通过视频通话)面对面交流是一个好主意。

    代码审查的好处胜于努力 (The benefits of code review outweigh the effort)

    I hope this list of code review pitfalls did not change your mind about code reviews. Because, the good news is that if you are aware of the code review pitfalls and counteract them, code reviews are a very beneficial engineering technique. And, there are even more proven ways to work effectively with code reviews.

    我希望这份代码审查陷阱清单不会改变您对代码审查的看法。 因为,好消息是,如果您知道代码审查的陷阱并加以弥补,那么代码审查是一种非常有益的工程技术。 而且,还有更多行之有效的方式来与代码审查一起使用。

    代码审查最佳实践 (Code review best practices)

    In the next blog post in this code review series, I show best practices to help to minimize the code review pitfalls and challenges and ensure your team gets the best out of the code review practice. So keep on reading. To be notified when I publish the next post, follow me on twitter.

    此代码审查系列的下一篇博客文章中,我将展示最佳实践,以帮助最大程度地减少代码审查的陷阱和挑战,并确保您的团队从代码审查实践中获得最大的收益。 因此,请继续阅读。 要在我发布下一篇文章时得到通知,请在Twitter上关注我。

    I prepared an exclusive Code Review e-Book for my newsletter subscribers. So make sure you subscribe to my email list and secure your Code Review e-Book including a handy cheat sheet of code review best practices.

    我为通讯订阅者准备了独家的Code Review电子书。 因此,请确保您已订阅我的电子邮件列表,并确保您的《代码审查》电子书安全,其中包括一份方便的代码审查最佳实践速查表。

    Originally published at https://www.michaelagreiler.com on April 6, 2019.

    最初于2019年4月6日发布在https://www.michaelagreiler.com

    翻译自: https://www.freecodecamp.org/news/how-to-avoid-code-review-pitfalls-that-slow-your-productivity-down-b7a8536c4d3b/

    代码走查和代码审查

    展开全文
  • 代码走查具体考察点一、参数检验公共方法都要做参数的校验,参数校验不通过,需要明确抛出异常或对应响应码。在接口中也明确使用验证注解修饰参数和返回值,作为一种协议要求调用方按注解约束传参,返回值验证注解...

    代码走查具体考察点

    一、参数检验

    公共方法都要做参数的校验,参数校验不通过,需要明确抛出异常或对应响应码。

    在接口中也明确使用验证注解修饰参数和返回值,作为一种协议要求调用方按注解约束传参,返回值验证注解约束提供方按注解要求返回结果。

    二、魔法数字(幻数)

    在代码中要杜绝幻数,幻数可定义为枚举或常量以增强其可读性。

    三、空指针检验

    不确定返回集合是否可为空时,要先做非空判断,再做for循环。

    尽量返回空对象,或者空集合,而不是null。

    判断字符串为空时,先判断是否为空,再判断是否空串,最好将其提出公共方法。

    使用a.equal(b)时,把常量放在左边。

    四、下标越界

    如果方法传入数组下标作为参数,要在一开始就做下标越界的校验,避免下标越界异常。

    五、重复代码检验

    不允许写重复代码(四行左右重复计算重复代码),重复代码要使用重构工具提取重构。

    六、命名规范

    包、类、方法、字段、变量、常量的命名要遵循规范。

    命令要名副其实,一方面增加可读性,另一方面促使我们在起名的过程中思考方法、变量、类的职责是否合适。

    尽量不要在循环中调用服务,不要在循环中做数据库等跨网络操作。

    循环或者递归,要注意其是否一定包含了停止循环/递归的条件。

    尽量避免while(true),一定要写的话,循环开始要加一个sleep,这样避免一上来就异常,跑死CPU。

    七、注意循环

    八、关心频率

    写每一个方法时都要关心这个方法的调用频率,一天多少,一分多少,一秒多少,峰值可能达到多少,调用频率高的一定要考虑性能指标,考虑是否会打垮数据库、缓存等。

    九、差错控制

    避免过大的 try 块,不要把不会出现异常的代码放到 try 块里面,尽量保持一个 try 块对应一个或多个异常。

    细化异常的类型,不要不管什么类型的异常都写成 Excetpion。

    catch 块尽量保持一个块捕获一类异常,不要忽略捕获的异常,捕获到后要么处理,要么重新抛出新类型的异常。

    方法内部,不要把自己能处理的异常抛给别人。

    不要用 try...catch 参与控制程序流程,异常控制的根本目的是处理程序的非正常情况。

    十、关于长度

    如果一行代码过长,要分解开来;如果一个方法过长,要重构方法;如果一个类过长要考虑拆分类

    十一、外部依赖的性能

    如果调用了外部依赖,要搞清楚这个外部依赖可以提供的性能指标,考量其是否能够提供符合我们使用场景的服务。

    十二、避免重复造轮子

    不要重复造轮子,如果已经有成熟类库实现了类似功能,要优先使用成熟类库的方法,这是因为成熟类库中的方法都经过很多人的测试验证,已经非常可靠了。

    十三、注意多线程

    多线程环境中,要注意数据的原子性与可见性等线程安全问题,最典型的HashMap,SimpleDateFormat,ArrayList是非线程安全的,另外如果使用Spring自动扫描服务,那么这个服务默认是单例,其内部成员是多个线程共享的,如果直接用成员变量是有线程不安全的。

    十四、日志打印

    打印日志要设定合理的日志级别。

    生成长字符串的toString()时,通过日志级别和if语句达到控制打印量的目的。原因是,长字符传拼接会占用很多gc年轻代内存。

    要通过log4j打印日志而不是直接把日志打印到控制台。

    十五、方法实现的简洁

    这个无法说的太细,总之是不要啰里啰嗦的写代码,具体问题要具体分析。

    十六、正向依赖

    不能让底层模块依赖于上层模块;不能让数据层依赖于服务层;也不能让服务层依赖于UI层;更不能在模块之间形成循环依赖关系。

    十七、分治

    分而治之,复杂的问题要分解成几个相对简单的问题来解决,首先要分析出核心问题,然后分析出核心的入参是什么,结果是什么,入参通过几步变化可以得出结果。(该条与第十条:关于长度,有一定的重合)

    十八、代码健壮性意识

    该条是前面几条的整合,比较综合。考虑各种边界条件(例如第四条下标越界、用户输入数据超出最大值等)、处理失败或出异常的方法(参考第九条、差错控制)、校验入参和返回值(参考第一条参数校验)

    展开全文
  • 目的代码走查的好处非常多,第一个是让新同学快速熟悉代码并了解系统。第二个是做资损防控的事前检查,在事前规避引发线上故障。第三个是通过一起讨论和审查,加强团队代码阅读和编写能力,让大家编写出优秀的代码。...
  • 轰轰烈烈的代码质量竞赛结束了,各产品部陆陆续续开展了代码走查交流会,会上各位组长或代码走查负责人分享了优秀的实践,也提出了各式各样的问题,现把遇到的典型问题与优秀实践收集整理,与大家分享,感谢物资系统...
  • 人工测试代码检查,走查以及可用性测试是三种主要的人工测试方法。 这种人工测试方法有点像是若干个人员坐在一起开‘头脑风暴会’。。也就是说,目的是为了找出错误,而不是调试。 优点: 1.一旦发现错误,就能在...
  • 代码走查和代码审查 我们被告知我们应该组织代码审查,因为代码审查对我们的代码库有益。 我们遵循了这一建议,并设法建立了宏伟的外观。 我们正在进行代码审查并改善代码库。 从外部看,一切都很好,也许我们正在...
  • 桌前检查、代码评审、走查

    千次阅读 2020-08-27 11:56:36
    程序员在程序通过编译之后,进行单元测试之前,对源程序代码进行分析、检验,并补充相关的文档,目的是发现程序中的错误。检查项目有: 1)检查变量的交叉引用表:重点是检查未说明的变量和违反了类型规定的变量,还要...
  • 代码走查和代码审查 代码审查是个好主意的其他原因 (The Other Reasons Code Reviews are a Good Idea) 不仅仅是捕捉错误 (More than just catching bugs) 什么是代码审查? (What are Code Reviews?) A Code ...
  • 代码检查和走查都要求人们组成一个小组来阅读或只管检查特定的程序。通常是一组开发人员(三至四人为最佳),参与者当中只有一人是程序编写者,这也符合“软件编写者往往不能有效地测试自己编写的软件”的测试原则。...
  • 桌面检查可视为由单人进行的代码检查或代码走查:由一个... 代码走查的最主要的目的是为了发现程序中的逻辑错误,编程风格方面的错误可以通过风格检查的工具去检查。如下的检查单给代码走查的专家发现逻辑错误提供了...
  • 代码走查

    千次阅读 2014-09-02 09:13:19
    代码走查目的是交换有关代码是如何书写的思路,并建立一个对代码的标准集体阐述。 在代码走查的过程中,开发人员都应该有机会向其他人来阐述他们的代码。 通常地,即便是简单的代码阐述也会帮助开发人员识别出错误...
  • 今天为大家带来的课程是《代码检查规则背景及总体介绍》,将从代码检查的意义、代码检查场景及工具、代码检查规则分级三个方面来解读代码检查规则。 一、代码检查的意义 01 提高代码可读性,统一规范,方便他人维护...
  • 代码走查》杂记

    2013-01-21 22:09:00
    代码走查目的交换有关代码是如何书写的思路,并建立一个对代码的标准集体阐述。 在代码走查的过程中,开发人员都应该有机会向其他人来阐述他们的代码。 通常地,即便是简单的代码阐述也会帮助开发人员识别出错误并...
  • 代码走查和代码审查 如果管理人员只能绘制流程图解释代码审查的工作方式,那么对他们来说会更容易。 然后,经理将通过电子邮件向所有同事发送电子邮件,告知每个人都应遵循新流程。 有许多方法可以在组织中实施...
  • 代码走查的重要性

    2016-02-03 14:03:00
    在一个团队中, 如果没有code review, 直接允许开发提交代码到版本库并部署环境, 那么在正式开始测试之前的代码走查就非常有必要了。  这里说的走查不是使用工具在持续化集成之前进行代码规范的检查, 而是根据PRD...
  • 【颗粒归仓】(四)代码走查---开篇

    千次阅读 热门讨论 2016-05-22 15:37:48
    经历了ITOO5.0和组织部考核系统新旧两版代码的历练,前段时间也要过来考评和基础的代码晚上回家研究,着实通过看别人的代码可以扩展自己的眼界,也是由于在期间看到了一些“坏味道”,让我有了总结“代码走查”这样...
  • 人工测试之代码检查、走查与评审

    千次阅读 2020-05-28 18:28:56
    人工测试方法:代码检查、代码走查、桌面检查、同行评审。 代码检查与代码走查的联系: 1. 要求人们组成一个小组来完阅读或直观检查特定的程序,找出错误,但不必改正错误 2. 都是对过去桌面检查过程(在提交测试...
  • 为何要做代码走查

    2013-11-12 15:46:01
    代码可读性这个话题一直以来都是备受关注,但是可读性高与不高却没有统一的标准。毕竟各个公司,甚至于各个项目的规范都是不...我想不同之中必有共性,那就是经过走查的、能够被项目组其他成员接受并能尽快看懂的代码
  • 典型代码走查检查单

    千次阅读 2009-06-28 21:40:00
    【IT168技术文章】代码走查的最主要的目的是为了发现程序中的逻辑错误,编程风格方面的错误可以通过风格检查的工具去检查。如下的检查单给代码走查的专家发现逻辑错误提供了一个很好的帮助。序号检查项序号检查项1、...
  • SourceAnalysis (StyleCop)的终极目标是让所有人都能写出优雅和一致的代码,因此这些代码具有很高的可读性。 早就听说了微软内部的静态代码检查和代码强制格式美化工具 StyleCop , 2008-05-23微软在 MSDN Code...
  • 代码走查工具篇SytleCop与FxCop的引入

    千次阅读 2013-03-27 23:57:56
    写相关敏捷开发的博客还要追溯到2012年年初的...拿代码走查这一项来说,切身体会,这是一项比较耗时,但是效果很好的走查方式,即使是周末加个小班,自己也是喜欢去做一做这个工作的。对项目、对公司负责是官话,对写代

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 3,649
精华内容 1,459
关键字:

代码走查的目的