Questions tagged «code-reviews»

该标签用于有关代码审查和代码演练的问题。有关现有有效代码的评论，请访问http://codereview.stackexchange.com

13
进行代码审查的最有效方法是什么？[关闭]
我从来没有找到执行代码审查的理想方法，但是我的客户经常需要它们。每个客户似乎都以不同的方式来做他们，而我从未对其中的任何一个感到满意。 您执行代码审查的最有效方法是什么？ 例如： 是一个人被认为是质量的守门员并审查代码，还是团队拥有该标准？ 您是否使用投影仪作为团队练习来检查代码？ 是亲自完成，通过电子邮件还是使用工具完成的？ 您是否避免使用代码编程和集体代码所有权等评论来确保代码质量？
12
有一个标志来指示是否应该抛出错误
我最近开始在一个与一些年龄较大的开发人员（大约50岁以上）一起工作的地方。他们致力于处理无法解决系统故障的航空关键应用。结果，较老的程序员倾向于以这种方式进行编码。 他倾向于在对象中放入一个布尔值，以指示是否应该引发异常。 例 public class AreaCalculator { AreaCalculator(bool shouldThrowExceptions) { ... } CalculateArea(int x, int y) { if(x < 0 || y < 0) { if(shouldThrowExceptions) throwException; else return 0; } } } （在我们的项目中，该方法可能会失败，因为我们正在尝试使用当时无法使用的网络设备。区域示例仅是异常标志的示例） 对我来说，这似乎是一种代码气味。编写单元测试变得有些复杂，因为每次都必须测试异常标志。另外，如果出现问题，您是否想立即知道？确定如何继续是呼叫者的责任吗？ 他的逻辑/理由是我们的程序需要做一件事，向用户显示数据。任何其他不会阻止我们这样做的异常都应忽略。我同意不应忽视它们，而应该冒泡并由适当的人员来处理，而不必为此处理标志。 这是处理异常的好方法吗？ 编辑：只是为了提供更多有关设计决策的信息，我怀疑这是因为如果该组件失败，程序仍可以运行并完成其主要任务。因此，当用户可以正常工作时，我们不想抛出异常（不处理它？）并让它删除程序。 编辑2：为了提供更多上下文，在本例中，该方法被调用来重置网卡。当网卡断开连接并重新连接时，会出现问题，它被分配了另一个IP地址，因此Reset将引发异常，因为我们将尝试使用旧的IP重置硬件。
16
我们有责任改进旧代码吗？
我正在查看我编写的一些旧代码。它可以工作，但不是很好的代码。我现在比那时知道的更多，所以我可以改善它。这不是当前的项目，而是当前的，有效的生产代码。我们是否有责任退一步来改进我们过去编写的代码，还是正确的态度“如果没有破裂，就不要修复”？几年前，我公司赞助了一次代码审查课程，其中一项主要收获是，有时它已经足够了。继续。 因此，在某个时候您应该只称其足够好并继续前进，还是应该在认为可能更好的情况下尝试推动项目以改进旧代码？
12
通过代码审查调和童子军规则和机会主义重构
我坚信童子军规则： 始终要比在检出时检查模块中的清洁剂。”不管原始作者是谁，如果我们总是花点力气，不管大小如何，以改进模块。结果是什么？我想所有人都遵循这个简单的规则，我们将会看到软件系统不断恶化的终结，相反，随着系统的发展，我们的系统将逐渐变得越来越好。我们还将看到团队关心整个系统，而不是整个系统。不仅仅是个人照顾自己的一小部分。 我也是机会重构相关思想的坚定信奉者： 尽管在某些地方可以进行一些计划内的重构工作，但我还是鼓励将重构作为一种机会主义活动，它需要在任何时候，任何地方需要清理代码的人（无论谁）进行。这意味着在任何时候，只要有人看到一些不尽如人意的代码，他们都应趁此机会立即将其修复，或者至少在几分钟内 特别注意以下来自重构文章的摘录： 我对任何可能导致机会重构产生冲突的开发实践都保持警惕。我的感觉是，大多数团队都没有进行足够的重构，因此，请注意任何阻碍人们进行重构的事情，这一点很重要。为了避免这种情况的发生，请注意任何时候您都不愿意进行小规模的重构，您肯定只需要一两分钟。任何此类障碍都是应该引起对话的气味。因此，请记下该挫折并与团队联系。至少应该在下一次回顾中讨论它。 在我工作的地方，有一种开发实践会引起严重的摩擦-代码审查（CR）。每当我更改不在“任务”范围内的任何内容时，我的审核员都会对我感到bu异，因为我正在使更改难以审核。当涉及到重构时，尤其如此，因为这使得“逐行”差异比较变得困难。这种方法是这里的标准，这意味着很少进行机会性重构，并且只会进行“计划的”重构（通常太少，太晚）。 我声称这样做的好处是值得的，并且3名审阅者会更加努力（实际上要前后理解代码，而不是仅仅关注变更范围的狭窄范围，因此，审阅本身会更好一些） ），以便接下来的100个阅读和维护代码的开发人员将受益。当我向审阅者提出这个论点时，他们说只要我不在同一CR中，他们的重构就不会有问题。但是我声称这是一个神话： （1）大多数时候，您只有在从事作业时才意识到要重构的内容和方式。正如马丁·福勒（Martin Fowler）所说： 在添加功能时，您意识到要添加的某些代码与某些现有代码包含某些重复项，因此您需要重构现有代码以清理问题……您可能会工作，但意识到如果更改了与现有类的交互，则更好。在您认为自己已完成之前，抓住这个机会。 （2）没有人会喜欢您发布您不应该做的“重构” CR。CR有一定的开销，您的经理不希望您在重构上“浪费时间”。当它与您应做的更改捆绑在一起时，此问题被最小化。 Resharper加剧了这个问题，因为我添加到更改中的每个新文件（而且我事先无法确切知道哪些文件最终会更改），通常充满错误和建议-其中大多数都是应有的且应有的定影。 最终结果是我看到了可怕的代码，然后就把它留在那里了。具有讽刺意味的是，我觉得修复这样的代码不仅不会提高我的声誉，而且实际上降低了我的声誉，并将我描绘成一个“无专心的”家伙，他浪费时间去修复那些没人关心的事情而不是去干他的工作。我对此感到难过，因为我确实鄙视错误的代码，无法忍受观看，更不用说从我的方法中调用它了！ 关于如何纠正这种情况有什么想法？
17
代码审查是主观的还是客观的（可量化的）？
我正在整理一些代码审查指南。我们还没有一个正式的流程，并且正在尝试使其正式化。而且我们的团队分布在各地。 我们使用TFS进行源代码控制（我们也使用TFS进行任务/错误跟踪/项目管理，但将其迁移到JIRA）与Visual Studio 2008一起进行开发。 您在进行代码审查时会寻找什么？ 这些是我想出的东西 强制执行FxCop规则（我们是Microsoft商店） 检查性能（是否使用任何工具？）和安全性（考虑使用 OWASP-代码搜寻器）和线程安全性 遵守命名约定 该代码应涵盖边缘情况和边界条件 应该正确处理异常（不要吞下异常） 检查功能是否在其他地方重复 方法主体应该很小（20-30行），并且方法只能做一件事情和一件事情（无副作用，避免时间耦合-） 不要在方法中传递/返回空值 避免死代码 记录公共和受保护的方法/属性/变量 我们通常还要注意什么？ 我正在尝试看看我们是否可以量化审核过程（当由不同人员审核时，它会产生相同的输出）示例：说“方法主体应不超过20-30行代码”，而不是说“方法”身体应该很小”。 还是代码审查非常主观（一个审查者与另一个审查者会有所不同）？ 目的是要有一个标记系统（例如，对于每个违反FxCop的规则，得分为-1分；对于不遵循命名约定的得分为-2分；对于重构，则得分为2分，等等），以便开发人员在检入代码时会更加小心。这样，我们可以识别出始终在编写好/不好代码的开发人员。目标是让审阅者最多花费30分钟左右的时间进行审阅（考虑到变更集/修订版可能包含多个文件/对现有体系结构的巨大更改等事实，我知道这是主观的，但是您得到了总体而言，审阅者不应花几天时间审查某人的代码）。 您遵循什么其他目标/可量化系统来识别开发人员编写的好/坏代码？ 参考书：清洁代码：Robert Martin撰写的敏捷软件工艺手册。
11
敏捷实践：代码审查-审查失败或引发问题？
在为期2周的冲刺结束时，一个任务进行了代码审查，在审查中我们发现了一个功能正常，可读性强的功能，但它相当长且有一些代码异味。轻松的重构工作。 否则，该任务将符合完成的定义。 我们有两个选择。 代码审查失败，因此该票证不会在此Sprint中关闭，并且我们在士气上受到了一些打击，因为我们无法通过该票证。 重构只是一小部分工作，并且将在下一个冲刺（甚至在开始之前）中完成，只是一个很小的半点故事。 我的问题是：从审阅的背后提出票证而不是通过失败有任何内在的问题或考虑吗？ 我可以找到并已阅读详细代码评论的资源通常为100％或什么都没有，但是我发现这通常是不现实的。
2
什么是“功能嫉妒”代码，为什么将其视为代码气味？
关于SO的这个问题是关于纠正OP认为是功能嫉妒代码的问题。我看到这个漂亮短语被引用的另一个示例是在developer.SE中最近给出的答案中。尽管我确实在该答案的注释中要求提供信息，但我认为这对遵循Q＆A的程序员理解“ 特性嫉妒 ”一词有帮助。如果您认为合适，请随时编辑其他标签。
12
公开开源项目而不会感到尴尬[关闭]
我一直在一个相当大的开源项目上工作了一段时间，现在已经接近要发布它的地步了。但是，我是自学成才的，我真的不认识任何可以充分审查我的项目的人。 几年前，我发布了一些代码，这些代码在我发布它的论坛上几乎被撕碎（在某种意义上）。尽管该代码有效，但批评是准确而残酷的。它促使我开始寻找所有事物的最佳实践，最终我觉得这使我成为了一个更好的开发人员。我已经遍历了项目中的所有内容，试图使它变得完美，以至于我数不清。 我相信我的项目，并认为它有潜力帮助很多人，而且我觉得我已经用有趣的方式做了一些很酷的事情。不过，由于我是自学成才，所以我不禁要问自己的自我教育存在哪些差距。我上次撕开我的代码的方式并不是我想重复的。我认为释放我的项目花了无数小时，这让我最大的两个恐惧是绝对尴尬的，因为我由于自我教育而错过了一些明显显而易见的事情，或者更糟糕的是，将其释放到of的声音中。 有没有遇到过类似情况的人？我不害怕建设性的批评，只要它具有建设性，而不仅仅是我如何搞砸的话。我知道StackExchange上有一个代码审查站点，但它并不是真正为大型项目设置的，而且我不觉得那里的社区足够大，如果我要零散发布项目的一部分，我也不会得到很好的反馈（我尝试了一个文件）。我该怎么做才能使我的项目至少取得一定程度的成功，而又不会在此过程中感到尴尬或沮丧？
14
在代码审查中，积极反馈的重要性如何？
重要的是在代码审查期间指出代码的好部分以及它为什么好？积极的反馈对于正在审核的开发人员以及参与审核的其他人员可能同样有用。 我们正在使用在线工具进行评论，因此开发人员可以在给定的时间段（例如1周）内打开其已提交代码的评论，其他人可以评论其代码。其他人可以评论该代码或其他评论者的评论。 正反馈和负反馈之间是否应该保持平衡？
7
一致的代码样式的实际价值是什么
我是顾问团队的成员，该团队为客户实施新的解决方案。我负责客户端代码库（React和javascript）上的大多数代码审查。 我注意到一些团队成员使用独特的编码模式，以至于我可以从一个样式中随机选择一个文件，以告诉谁是作者。 示例1（一次性内联函数） React.createClass({ render: function () { var someFunc = function () { ... return someValue; }; return <div>{someFunc()}</div> } }); 作者认为，通过为someFunc分配有意义的名称，代码将更易于阅读。我相信，通过内联函数并添加注释，可以达到相同的效果。 示例2（未绑定函数） function renderSomePart(props, state) { return ( <div> <p>{props.myProp}</p> <p>{state.myState}</p> </div> ); } React.createClass({ render: function () { return <div>{renderSomePart(this.props, this.state)}</div>; } }); 这是我们通常的做法（避免通过状态和道具）： React.createClass({ renderSomePart: function …
4
git-flow和github进行代码审查
使用常规的git和github，我可以通过简单地创建我正在处理的功能分支到master分支的拉取请求来进行代码审查。我将如何使用git-flow进行代码审查？使用“ git flow功能完成”之类的工作流程，我对代码审查实际上发生在何处以及git-flow或git如何促进该审查感到困惑。
9
作为唯一开发人员工作：查看代码
我别无选择，只能独自工作，无法找到适当的解决方案来检查我的工作，进行理智检查，找人集思广益，讨论最佳做法等。 我以为我会通过Jeff Atwood的文章得到答案：在《编程》中，“一个是最孤独的数字”，这是我在该主题上能找到的最好的答案，但事实只是重申了我的问题。 我知道像这样的Stack Exchange网站和Code Review是一个明显的潜在答案，但正如许多人所欣赏的那样，这是理想的FAR： 虽然我无法列出所有陷阱，但经常提出一个问题并将其装箱成一个独立的问题通常需要花费大量的工作，以至于在您充分准备好它之后，您已经在更大程度上回答了自己的问题。时间比其他时间要多。同样，隐藏细节以提出明确的问题，也消除了有人发现您未曾想到的问题的可能性。另外，尽管我不能完全动手，但我能想到的任何形式的文本互联网讨论都无法与自由对话的响应能力相提并论。最后但并非最不重要的一点是，出于明显的原因，我不想将我的整个项目发布给全世界，让人们永生不衰。 除了付钱给顾问查看我的代码之外，还有其他答案吗？
16
初级开发人员是否需要进行代码审查？
我曾在两家公司工作过，在进行代码审查时，每个公司都有不同的方法： 在第一家公司中，团队负责人进行了代码审查，并且在完成每个模块后都需要进行代码审查。 但是，在第二家公司中，不需要团队负责人进行任何代码审查，而只是检查功能和设计问题。 所以我很困惑。确实需要代码审查过程吗？如果是，为什么？如果不是，为什么不呢？
9
在什么时候对代码进行“建设性”批评会变得毫无用处？
我最近开始是一名初级开发人员。作为团队中经验最少的人之一，我也是一名女性，在男性主导的环境中工作时会遇到各种挑战。我最近遇到了麻烦，因为我觉得自己的工作受到了太多不必要的学问批评。让我给你举一个最近发生的事的例子。 团队负责人太忙了，无法推动我开设的某些分支机构，因此他直到周末才加入他们。我检查了我的邮件，但实际上并没有做任何工作的意思，发现我的两个分支已根据变量名被拒绝，使错误消息更具描述性，并将一些值移至配置文件。 我不认为在此基础上拒绝我的分支是没有用的。周末有很多人在工作，我从未说过我会工作。实际上，有些人可能因为我没有时间进行更改并重新提交而被阻止。我们正在开发一个对时间非常敏感的项目，在我看来，完全基于对客户透明的事物完全拒绝代码是没有帮助的。我可能是错的，但似乎我有时间时应在补丁类型提交中处理这类事情。 现在，我可以看到在某些环境中这是正常的。但是，批评似乎分布不均，这就是导致我遇到下一个问题的原因。这些问题中大多数的基础是由于我处于别人编写的代码库中并且试图做到微创的事实。我在模仿文件中其他地方使用的变量名。当我这样说时，我直言不讳地告诉我：“不要模仿别人，做对的事。” 这也许是我本该被告知的最没有用的东西。如果已经签入的代码是不可接受的，那么我该如何判断对与错呢？如果混淆的基础来自底层代码，我认为不是 在这种情况下，我感到非常单调和沮丧。我对遵循预期的标准有了更好的了解，例如，当我将一段代码重构为以前缺少的ADD错误检查时，我感到沮丧，我只是被告知我没有使错误足够详细（并且在此基础上分支被拒绝）。如果我从未添加过该怎么办？如果它是如此错误，它是如何进入代码的呢？这就是为什么我这么单调的原因：我经常遇到这个现有的有问题的代码，以至于我要么模仿要么重构。当我模仿它时，这是“错误的”，并且如果我重构它，我会因为没有做足够的事情而受到指责（如果我一直走下去，引入错误，等等）。再说一次，如果这是一个问题，我不明白任何代码如何进入代码库， 无论如何，我该如何处理？请记住，我在最上面说的是我是女人，并且我确定这些人在查看其他人的代码时通常不必担心礼节，但是老实说这对我不起作用，这使我的工作效率降低。我担心如果我和经理谈这件事，他会认为我无法处理环境等。
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.