您是否有任何方法/系统来激励您的开发团队成员编写“好”代码并向他们的代码添加注释？我认识到“好”是一个主观术语，它与一个较早的问题有关，即衡量代码的可维护性作为衡量好代码的一种方法。
Guy
问问题
1016 次
15 回答
6
这很难，因为奖励性薪酬被认为是有害的。我最好的建议是选择几个必须同时实现的目标，而不是一个可以利用的目标。
于 2008-09-24T17:44:42.037 回答
5
虽然大多数人回应说代码审查是确保高质量代码的好方法，而且理所当然，但在我看来，它们似乎不是实现目标的直接动力。然而，为好的代码提出积极的激励是很困难的，因为好的代码的概念有很大的范围属于意见领域，几乎任何系统都可以被博弈。
在我从事的所有工作中，优秀的开发人员都有编写优秀代码的内在动力。先有鸡还是先有蛋，反馈，抓到 22 条，随便你怎么称呼它，获得好代码的最好方法是雇佣有动力的开发人员。创造一个优秀的开发人员想要工作的环境可能是我能想到的最好的激励措施。我不确定哪个更难，创建环境或寻找开发人员。两者都不容易，但从长远来看，两者都是值得的。
我发现创建优秀开发人员想要工作的环境的一部分包括确保开发人员谈论代码的情况。我不认识一个熟练的程序员不欣赏对他的代码的良好批评。这有助于那些喜欢成为最好的人变得更好。作为这项工作的一个较小的子部分，因此是创建好代码的间接激励，我认为代码审查工作得很好。是的，您的代码质量也应该获得一些直接的好处。
我和同事用来传达良好编码习惯的另一种技术是对代码进行小组审查。它不那么正式，允许人们展示新技术、工具和功能。提出了批评，公开给予了赞誉，大多数开发人员似乎并不介意在他们认识每个人的小型开发人员小组面前发言。如果管理层看不到这方面的好处，那就去买小面包，称其为棕色袋子。开发人员也会喜欢免费食物。
我们还努力让人们参加编码活动。诚然，根据你们对这个主题的熟悉程度，你可能不会学到太多东西，但它会让人们思考代码一段时间，让人们在更轻松的环境中交谈。如果您在之后提供一两杯饮料，大多数开发人员也会出现。
Wait a second, I noticed another theme. Free food! Seriously though, the point is to create an environment where people that already write good code and those that are eager to learn want to work.
于 2008-09-24T18:31:06.030 回答
4
代码审查做得好，可以产生巨大的影响。没有人愿意成为那个提出让每个人都流血的代码的人。
不幸的是，审查并不总是很好地扩大（太多厨师等）或缩小（我们太忙于编码而无法审查代码）。值得庆幸的是，在 Stack Overflow 上有一些提示。
于 2008-09-24T17:43:09.623 回答
3
我认为正式的代码审查满足了这个目的。我知道我的团队中至少有两个其他开发人员将审查它，所以我更加小心不要提交看起来很糟糕的代码。
于 2008-09-24T17:42:22.277 回答
2
公开标准，不要将激励措施与任何类型的自动化联系起来。宣传您正在寻找的示例。善待并鼓励人们公开他们自己的坏例子（以及他们如何纠正这些例子）。
团队文化的一部分是什么是“好代码”；这对许多人来说是主观的，但是一个正常运作的团队应该有一个团队中每个人都同意的明确答案。任何不同意的人都会让团队失望。
于 2008-09-24T17:49:50.577 回答
1
这是针对您的建议，而不是您的老板。
总是提醒自己一个事实，如果你加倍努力，写出尽可能好的代码，那么当你一周没有重构你的东西时，这将得到回报。
于 2008-09-24T17:47:47.383 回答
1
我认为编写好代码的最佳动机是一起编写好代码。在项目的同一领域编写代码的人越多，代码约定、异常处理、注释、缩进和一般思维过程就越可能相互接近。
并不是所有的代码都是统一的，但是当人们一起编写大量代码时，维护通常会变得更容易，因为您可以掌握样式并作为一个团队提出最佳实践。
于 2008-09-24T17:49:28.110 回答
1
我不认为钱是个好主意。原因是它是一种外在的动力。人们将开始遵守规则，因为这样做有经济上的激励，但这并不总是奏效。研究表明，随着人们年龄的增长，经济激励不再是激励因素。话虽如此，在这种情况下的工作质量只会等于您为获得奖励而设定的水平。这是一个短期的胜利，仅此而已。
激励人们做正确事情的真正方法是让他们相信他们的工作会变得更有价值。他们会在他们的工作和效率方面做得更好。激励人们的唯一真正方法是让他们愿意去做。
于 2008-09-24T17:52:44.000 回答
1
你摆脱了那些不写好的代码的人。
我是认真的。
于 2008-09-24T17:59:39.867 回答
1
我同意比尔蜥蜴。但我想补充比尔不得不说的话......
可以做的事情（假设资源可用）是让其他一些开发人员（可能 1 个对您的工作有所了解，1 个对您的工作非常了解，也许 1 个对它知之甚少）一起走他们通过你的代码。您可以使用投影仪并将它们放在房间里，然后您可以完成所有更改。这样，您就有了一个混合的人群，可以提供输入、提出问题，最重要的是让您成为更好的开发人员。
不需要只有负面反馈；但是，它有时会发生。重要的是，将消极视为建设性的，并在提供反馈时尝试以建设性的方式表达您的反馈。
这里的想法是，如果您的函数有注释块，或者解释一些棘手的数学运算的注释块，或者解释为什么需要根据所选语言更改日期格式的简单注释行...那么您将不需要逐行指示该组您的代码在做什么。这是一种注释您所做更改的方法，它允许其他开发人员继续思考您在之前的函数中的模糊逻辑，因为他们可以阅读您的评论并查看您在其他地方做了什么。
这一切都来自真实的生活经历，我们在我的工作中继续使用这种方法。
希望这会有所帮助，好问题！
于 2008-09-24T18:14:00.737 回答
0
嗯。
也许开发团队应该对彼此的代码进行代码审查。这可以激励他们编写更好的注释代码。
于 2008-09-24T17:43:26.580 回答
0
代码质量可能就像色情 - 正如波特斯图尔特大法官的名言所说，“我一看到就知道了”
所以一种方法是向其他人询问代码质量。这样做的一些方法是......
他们的同行的代码审查（以及他们对其他代码的审查），易于理解是审查清单中的标准之一（我个人认为这并不一定意味着评论；有时没有它们，代码可以非常清晰）
要求在回顾会上提出由代码质量引起的问题（你确实举行回顾，对吧？）
跟踪他们的代码第一次更改的频率，或者是否需要多次尝试？
在 annuak（或其他）评审时间要求同行评审，并包括一个关于使用被评审者的代码有多容易的问题作为问题之一。
于 2008-09-24T17:47:18.053 回答
0
激励时要非常小心：“得到衡量就会完成”。如果你奖励代码行，你会得到臃肿的代码。如果你奖励评论，你会得到不必要的评论。如果您奖励在代码中没有发现错误，您的开发人员将做他们自己的 QA 工作，而这些工作应该由收入较低的 QA 专家完成。与其对流程的某些部分进行激励，不如为整个团队或整个公司的成功提供奖金。
IMO，良好的代码审查流程是确保高代码质量的最佳方式。根据团队的不同，结对编程也可以作为传播良好实践的一种方式。
于 2008-09-24T17:47:24.950 回答
0
最后一个破坏构建或交付代码并导致技术支持呼叫的人必须先泡茶，直到其他人下一个这样做。问题是这个人可能不会给予茶制作真正好的茶所需的关注。
于 2008-09-24T17:58:16.500 回答
0
我通常不为我的团队提供金钱奖励，因为他们做的不多而且我们真的负担不起，但我通常会和每个团队成员坐下来，单独和他们一起检查代码，指出什么是有效的（ “好”代码）和什么不是（“坏”代码）。这似乎工作得很好，因为在我们开始这个过程之前，我得到的垃圾代码几乎没有。
于 2008-09-24T18:03:21.057 回答