我们是否有任何方法/系统可以激励开发团队成员编写"良好"代码并在其代码中添加注释？我认识到"好的"是一个主观术语，它与一个较早的问题有关，即将代码的可维护性作为一种好的代码来衡量。

解决方案

我认为正式的代码审查可以满足此目的。我要小心一点，不要提交糟糕的外观代码，因为我的团队中至少还有其他两个开发人员将对其进行审查。

良好的代码审查可能会产生很大的不同。没有人愿意成为提供导致所有人的眼睛流血的代码的家伙。

不幸的是，评论并非总是可以很好地扩展(无论是厨师太多还是如此)或者缩小(我们都太忙于编写代码以致无法查看代码)。值得庆幸的是，关于堆栈溢出有一些技巧。

嗯

也许开发团队应该对彼此的代码进行代码审查。这可能会激励他们编写更好的，带注释的代码。

这很困难，因为激励薪酬被认为是有害的。我最好的建议是选择几个必须同时实现的目标，而不是可以利用的目标。

就像波特·斯图尔特大法官的名言所说的那样，代码质量可能像色情，"我一看到它就知道"

因此，一种方法是询问其他人的代码质量。这样做的一些方法是...

同行评审的代码(以及他人评审的代码)，易于理解是评审清单中的标准之一(就个人而言，我认为这不一定意味着要发表评论；有时候没有他们，代码就可以很清晰)

要求在回顾中提出由代码质量引起的问题(我们确实要进行回顾，对吗？)

跟踪更改代码第一次生效的频率，或者是否需要多次尝试？

在annuak(或者其他时间)审阅时要求同行审阅，并提出一个问题，即使用审阅者的代码有多容易，这是一个问题。

进行激励时要非常小心："要衡量的事情就完成了"。如果我们奖励代码行，则会得到肿的代码。如果我们奖励评论，则会收到不必要的评论。如果我们奖励缺少代码中的错误，则开发人员将执行自己的质量检查工作，这些工作应由低薪质量检查专家完成。代替激励过程的一部分，为整个团队或者整个公司的成功提供奖金。

IMO，一个好的代码审查过程是确保高质量代码的最佳方法。根据团队的不同，结对编程也可以作为传播良好做法的一种方法。

这是针对我们而不是老板的建议。

始终提醒自己一个事实，那就是，如果我们付出更多的努力并尽可能多地编写出色的代码，那么当我们一周之内没有重构工作时，这将为我们带来回报。

我认为编写好的代码的最佳动机是在一起编写好的代码。在项目的相同区域中编写代码的人越多，代码约定，异常处理，注释，缩进和一般思考过程之间的联系就越可能发生。

并非所有代码都将统一，但是当人们一起编写大量工作时，通常可以更轻松地进行维护，因为我们可以选择样式并提出最佳实践。

公开标准，不要将激励措施与任何形式的自动化联系起来。公开我们正在寻找的示例。保持友善并鼓励人们宣传自己的不良榜样(以及如何纠正它们)。

团队文化的一部分是什么是"好的代码"；这对许多人来说都是主观的，但是一个运作良好的团队应该有一个明确的答案，团队中的每个人都应同意。任何不同意的人都会使团队垮台。

我认为钱不是一个好主意。原因是它是一种外在动力。人们将开始遵守规则，因为这样做有经济上的诱因，但这并不总能奏效。研究表明，随着人们年龄的增长，经济诱因也越来越少。话虽如此，在这种情况下的工作质量将仅等于我们设定的获得奖励的水平。这是短期的胜利。

激励人们做正确的事情的真正方法是说服他们，他们的工作将变得更加有意义。他们会在做事和效率方面做得更好。激励人们的唯一真实方法就是让他们愿意去做。

最后一个破坏了构建或者交付代码的人导致了技术支持电话，必须等到下一个人为止。麻烦的是，这个人可能不会给茶一个真正的好杯子所需的注意力。

我们摆脱那些编写不好代码的代码。

我是认真的

我通常不向我的团队提供金钱奖励，因为他们做的不多，而且我们确实负担不起，但是我通常会与每个团队成员坐下来，与他们逐一讨论代码，指出什么是可行的( "好"代码)和什么不做("坏"代码)。这似乎工作得很好，因为我得到的垃圾代码几乎不像开始此过程之前那样多。

我同意比尔·蜥蜴。但是我想补充一下比尔不得不说的话...

可以做的事情(假设有可用的资源)是让其他一些开发人员(也许1个对工作有所了解的人，1个对工作非常了解的人，以及1个对工作了解得很少的人)聚在一起，然后步行他们通过代码。我们可以使用投影仪并将它们放在房间里，然后进行所有更改。这样，我们会有各种各样的人群可以提供意见，提出问题，最重要的是使我们成为更好的开发人员。

无需仅提供负面反馈；但是，它有时会发生。重要的是要把否定性视为建设性的，并可能在提供反馈时尝试以建设性的方式表达反馈。

这里的想法是，如果我们有函数的注释块，或者解释一些棘手的数学运算的注释块，或者简单的注释行解释了为什么需要根据所选语言更改日期格式...那么我们将无需逐行指示组代码所执行的操作。这是一种注释我们所做的更改的方法，它使其他开发人员可以继续考虑我们先前功能中的模糊逻辑，因为他们可以读取注释并查看我们在其他地方所做的事情。

这些都是来自现实生活中的经验，我们将继续在工作中使用这种方法。

希望这会有所帮助，很好的问题！

尽管大多数人都认为代码审查是确保高质量代码的一种好方法，但是这样做对，对我而言，这似乎并不是直接推动实现这一目标的直接动机。但是，很难对好的代码提出积极的激励，因为好的代码的概念涉及的领域很大，几乎任何系统都可以玩。

在我所从事的所有工作中，优秀的开发人员具有内在的动力来编写优秀的代码。鸡和鸡蛋，反馈，赶上22，随便问问，获得好的代码的最好方法是雇用有积极性的开发人员。我能想到的最好的动机就是创造一个好的开发人员想要工作的环境。我不确定创建环境或者寻找开发人员会更难。两者都不容易，但从长远来看，两者都是值得的。

我发现创建良好的开发人员想要工作的环境的一部分包括确保开发人员谈论代码的情况。我不认识一个熟练的程序员，不喜欢他的代码。这可以帮助最喜欢的人变得更好。作为此工作的较小部分，因此是创建良好代码的间接诱因，我认为代码审查的工作非常出色。是的，代码质量也应该获得一些直接的好处。

我和我用来交流良好编码习惯的另一项技术是对代码进行小组审查。它不太正式，可以让人们炫耀新技术，工具，功能。进行了批判，公开赞扬，而且大多数开发人员似乎都不介意在一个认识所有人的小型开发人员小组面前讲话。如果管理人员看不到这样做的好处，那么就去寻找美味佳肴，并称其为棕色皮包。开发人员也将喜欢免费食物。

我们还努力使人们参加代码事件。当然，根据我们对本主题的熟悉程度，我们可能不会学到太多，但这会使人们思考代码一段时间，并使人们在更加轻松的环境中交谈。如果我们以后提出拿起一两杯饮料，大多数开发人员也会出现。

等一下，我注意到了另一个主题。免费食物！认真地说，关键是要创建一个环境，使已经在编写好的代码的人和渴望学习的人都想工作。