Questions tagged «code-reviews»

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

7
内部代表，投票和徽章会鼓励良好的编程习惯吗？
只是大声思考-我们的程序员喜欢所有这些投票/徽章/代表的东西，因此可以将这样的方案引入公司代码审查流程中，以鼓励更好的编码。 就像是 您（或代表您的其他人）可以发布评论（可以是摘要，单次提交或一系列评论）以进行代码评论 其他人可以对此发表评论（类似于SE中的答案） 可以提供/建议使用徽章（有些会很不错，有些会很糟糕，例如“ Comment Desert”（评论沙漠）等等） 您可以对代码本身以及注释和徽章（例如，如果有人建议使用徽章而您同意/不同意），则可以上下投票。 这样的计划的目的是 引入一些乐趣以鼓励使用代码审查 提高质量（在此方案中，代码审阅者和审阅者都可以学习） 减少代码审查引发“自我战争”的机会 提供一些指标以帮助衡量个人表现 能行吗？有什么想法吗？
7
程序员处理代码审查的最佳方法是什么？
我对代码审查非常陌生，但是在博士学位期间我已经编码多年了-这并不总是使您成为一名优秀的程序员！ 如果审阅者更改了您的代码并逐行处理代码，如果您不同意该怎么办？有时，您做出了选择X，而审阅者将其更改为Y，您的脑海中就想到了Y，但由于不利因素而决定不这样做，但是审阅者断言那些不利因素并不重要。您应该说出您的分歧，还是只是不听对方的意见？ 如果您不善于接受批评，并且审稿人是组织中的高级人员，那么这将很困难。防守太大可能是不好的。
8
什么是常见的代码审查过程，什么被认为是不好的？
我的公司最近开始进行正式的代码审查。流程是这样的：您提交到github中，请求拉取请求，代码将由大约三个人审阅，然后，如果全部通过，则代码会进入。 这个过程看起来很公平，但是进行代码审查的三个人似乎并不公平。我注意到，当我将代码放入代码中进行审查时，我得到的注释介于100-200之间。对我来说，最高的一次是300条评论。当然，您会认为这是很大的更改，但是对于少于50行的代码（包括单元测试），这也可能是非常小的更改。所有评论都被认为是“必须做的”，并且没有争议。 考虑到这一点，我的主要问题是，这似乎有点过头了。我与该小组进行了交谈，他们基本上告诉我，仅仅因为我在php中拥有多年的开发经验并不意味着我是“开发人员”。当然，这似乎比没有伤害更大。我还注意到，在小组中，他们似乎没有产生太多评论，大多数时候，他们忽略或以其他方式忽略了其他评论或建议，即使有什么问题也很少接受它为有效。 所以我的问题是，这是否公平？还是普通的？
3
仅使用代码注释的代码审查是一个好主意吗？
前提条件 团队使用DVCS IDE支持注释解析（例如TODO等） 诸如CodeCollaborator之类的工具预算昂贵 诸如gerrit之类​​的工具过于复杂，无法安装或无法使用 工作流程 作者在中央回购功能分支上的某个位置发布 审阅者获取它并开始审阅 如果有任何问题/评论，请创建带有特殊标签的评论，例如“ REV”。此类标签不得在生产代码中-仅在审核阶段： $somevar = 123; // REV Why do echo this here? echo $somevar; 当审阅者完成评论后，它只会发送愚蠢的消息“ comments”并向后推送 作者将功能分支拉回并以类似方式回答评论或改进代码并将其推回 当“ REV”评论消失时，我们可以认为，该评论已成功完成。 作者以交互方式为功能分支重新设置基础，挤压功能分支以删除那些“注释”提交，现在可以合并功能以开发或进行任何成功的内部检查后通常可以采取的操作 IDE支持 我知道，自定义注释标签可以在Eclipse和Netbeans中使用。当然，它也应该属于blablaStorm家族。 问题 您认为这种方法可行吗？ 你知道类似的东西吗？ 有什么可以改进的吗？
7
我应该如何描述学习他人代码的过程？（在开发票的情况下。）
关闭。这个问题是题外话。它当前不接受答案。 想改善这个问题吗？ 更新问题，使它成为软件工程堆栈交换的主题。 4年前关闭。 编辑：贾斯汀·凯夫（Justin Cave）提出了一个很好的观点，即这种沟通应该在我的报价/估计中占上风。在这种情况下，我仍然很想知道人们使用哪种语言来描述“现有代码学习”活动。特别是对于以前从未与软件承包商打过交道的公司。 结束编辑 我有一份合同，为一家大公司升级一些内部软件。该公司已请求增加多个功能并修复了一些错误。这是我的第一份自由职业风格的工作。 首先，我需要熟悉该应用程序的工作方式-就像我是一个用户一样学习它。 接下来，我必须学习该软件的工作方式。我从广义的概念开始，然后在研究每个错误修复和功能之前将其范围缩小到必要的细节。 至少在项目开始时，我花了更多的时间来学习现有的代码，而不是编写附加功能。 如何描述学习发票上现有代码的过程？（公司的这一部分通常是在公司内部做事，因此与我这样的软件承包商打交道的经验不足，我担心他们可能不了解学习别人代码的开销）。我不想只是将学习时间花在实际的功能升级上，因为在某些情况下，这会使“简单任务”看起来花了我太多时间。我想将发票分解为相关步骤，并告知我要在能够添加自己的代码之前承担学习其他人代码的大量开销。 记帐工作时，有没有描述这种活动的标准方法？
4
拉取请求作者必须合并的代码审查工作流
我公司的几个团队在实践一个我从未见过的代码审查工作流。我试图理解其背后的想法，并认为使整个公司保持一致具有价值。（我为多个代码库做出了贡献，过去的差异让我感到震惊。） 代码作者提交请求请求 审阅者检查代码 如果审阅者批准，他们会按照“看起来不错，随时可以合并”的方式发表评论 如果审阅者有疑问，他们会留下诸如“请先解决X和Y的小问题，然后合并”之类的评论（有关重大更改，请返回步骤2）。 代码作者在必要时进行更改，然后合并自己的请求请求 我有以下担忧： 在第3步获得批准的情况下，此工作流程将为拉取请求作者创建一个看似不必要的往返。已经在查看代码的审阅者可以立即将其合并。 在第3步请求更改的情况下，合并拉取请求的代理机构现在仅由PR的作者负责。除了作者之外，没有人会在合并之前查看这些更改。 此工作流程还有哪些其他优点或缺点？此工作流程在其他工程团队中是否常见？
4
基于TimeZone存储DateTime的最佳实践
开发一个Web应用程序，该应用程序应允许用户根据其TimeZone安排约会。我将用户计划的日期时间作为服务器日期时间存储到数据库字段中。在显示计划信息时，将从数据库中检索值并转换为用户timzone。在代码库中进行处理我正在根据用户时区转换DateTime。请建议这是最佳做法还是存在任何简便方法？
5
何时进行代码审查
我们最近进入了Scrum流程，并且正在sprint中处理任务和用户故事。我们希望经常进行代码审查，以减轻他们的负担。我们正在考虑在用户故事级别上执行这些操作，但是不确定如何分支我们的代码来解决此问题。 我们使用的是VS和TFS 2010，我们由6人组成。 我们目前为功能分支，但正在努力更改为Scrum分支。 我们目前不使用架子集，如果有其他可用的技术，我们也不想真正实现。 您如何建议我们针对每个用户案例实施代码审查？
4
推进代码审查和单元测试实践
作为一个团队领导来管理一组没有代码审查和单元测试经验（并且不需要）的开发人员，您如何提高代码审查和单元测试的实践水平？ 您将如何创建一种方法，以使代码审查和单元测试自然地适合开发人员的流程？ 这两个方面的阻力之一是“我们总是紧迫日期，因此没有时间进行代码审查和单元测试”。 代码审查的另一个阻力是我们目前不知道该怎么做。我们应该在每次入住时检查代码，还是在指定日期检查代码？
5
代码审查落后于交付/测试周期
在我们的敏捷过程中，我们有2周的冲刺。每天（每天一次）交付任务，测试团队会在第二天甚至同一天立即完成测试。 我们也有开发人员代码审查，需要一些时间（1-2小时），因此每周安排3次：星期一至星期三至星期五。开发人员聚在一起，建议如何改进/重构代码。 我们的问题是，在代码审查后提出“行动项目”时，大多数任务已经过测试。测试人员不想重新测试已经通过测试的内容。他们不在乎内部开发人员的变更。 我们误解了敏捷过程吗？代码审查是否与每日发布/测试周期不兼容？我们无法每天进行代码审查，因为它们占用了每个人的时间。
1
配对编程是否消除了极限编程（XP）项目中的代码审查需求？
在一个极端的编程项目中，程序员大部分时间都会进行配对编程。 由于这些对也轮换使用，也就是说，您将程序与不同的人配对，并且具有集体所有权感，因此经常对源代码进行检查和更新。 这样的话，是否需要代码审查？我的意思是，停止编程，实际上只是进行代码审查。
5
如何选择要查看的代码？
我是一家小型软件公司的七个开发人员团队的一部分，我正在尝试介绍常规的组代码和设计评论。过去我们进行了一些审查，但它是零星的。我想使其变得更常规。 我已经阅读了Code Complete和其他类似的资源，他们谈论了如何进行代码审查的机制，但是我无法找到有关如何选择要审查的内容的最佳实践。我们的代码库已有八年的历史了，涵盖了多种语言，因此可以参考很多内容。 我想到了一些可能会影响选择的因素： 语言：C，Java，SQL，PL / SQL 代码年龄：新代码与旧代码 代码用法：常用代码与（有效）失效/很少使用的代码 代码重要性：关键代码与非关键代码 开发人员：初级开发人员代码与高级开发人员代码 我知道这不是绝对确定的问题，但是任何指导都是有用的。 一些与外围设备相关的问题： 代码审查方法（审查关键部分和新开发人员代码的想法） 我们应该尝试审查所有代码吗？
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.