This is tough as incentive pay is considered harmful. My best suggestion would be to pick several goals that all have to be met simultaneously, rather than one that can be exploited.
While most people respond that code reviews are a good way to ensure high quality code, and rightfully so, they don't seem to me to be a direct incentive to getting there. However, coming up with a positive incentive for good code is difficult because the concept of good code has large areas that fall in the realm of opinion and almost any system can be gamed.
At all the jobs I have had, the good developers were intrinsically motivated to write good code. Chicken and egg, feedback, catch 22, call it what you will, the best way to get good code is to hire motivated developers. Creating an environment where good developers want to work is probably the best incentive I can think of. I'm not sure which is harder, creating the environment or finding the developers. Neither is easy, but both are worth it in the long term.
I have found that one part of creating an environment where good developers want to work includes ensuring situations where developers talk about code. I don't know a skilled programmer that doesn't appreciate a good critique of his code. This helps the people that like to be the best get better. As a smaller sub-part of this endeavor, and thus an indirect incentive to create good code, I think code reviews work wonderfully. And yes, your code quality should gain some direct benefit as well.
Another technique co-workers and I have used to communicate good coding habits is a group review in code. It was less formal and allowed people to show off new techniques, tools, features. Critiques were made, kudos were given publicly, and most developers didn't seem to mind speaking in front of a small developer group where they knew everyone. If management cannot see the benefit in this, spring for sammiches and call it a brown bag. Devs will like free food too.
We also made an effort to get people to go to code events. Granted, depending on how familiar you all are with the topic, you might not learn too much, but it keeps people thinking about code for a while and gets people talking in an even more relaxed environment. Most devs will also show up if you offer to pick up a round or two of drinks afterwards.
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.
Always remind yourself of the fact that if you go that extra mile and write as good code as you can now, that'll pay off later when you don't have refactor your stuff for a week.
I think the best incentive for writing good code is by writing good code together. The more people write code in the same areas of the project, the more likely it will be that code conventions, exception handling, commenting, indenting and general thought process will be closer to each other.
Not all code is going to be uniform, but upkeep usually gets easier when people have coded a lot of work together since you can pick up on styles and come up with best practice as a team.
I agree with Bill The Lizard. But I wanted to add onto what Bill had to say...
Something that can be done (assuming resources are available) is to get some of the other developers (maybe 1 who knows something about your work, 1 who knows your work intimately, and maybe 1 who knows very little about it) together and you walk them through your code. You can use a projector and sit them down in a room and you can drive through all of your changes. This way, you have a mixed crowd that can provide input, ask questions, and above all make you a better developer.
There is no need to have only negative feedback; however, it will happen at times. It is important to take negative as constructive, and perhaps try to couch your feedback in a constructive way when giving feedback.
The idea here is that, if you have comment blocks for your functions, or a comment block that explains some tricky math operations, or a simple commented line that explains why you are required to change the date format depending on the language selected...then you will not be required to instruct the group line by line what your code is doing. This is a way to annotate changes you have made and it allows for the other developers to keep thinking about the fuzzy logic you had in your previous function because they can read your comments and see what you did else-where.
This is all coming from a real life experience and we continue to use this approach at my job.
Make criteria public and do not connect incentives with any sort of automation. Publicize examples of what you are looking for. Be nice and encourage people to publicize their own bad examples (and how they corrected them).
Part of the culture of the team is what "good code" is; it's subjective to many people, but a functioning team should have a clear answer that everyone on the team agrees upon. Anyone who doesn't agree will bring the team down.
I don't think money is a good idea. The reason being is that it is an extrinsic motivator. People will begin to follow the rules, because there is a financial incentive to do so, and this doesn't always work. Studies have shown that as people age financial incentives are less of a motivator. That being said, the quality of work in this situation will only be equal to the level you set to receive the reward. It's a short term win nothing more.
The real way to incent people to do the right thing is to convince them their work will become more rewarding. They'll be better at what they do and how efficient they are. The only real way to incentivize people is to get them to want to do it.
I think formal code reviews fill this purpose. I'm a little more careful not to commit crappy looking code knowing that at least two other developers on my team are going to review it.
Code reviews, done well, can make a huge difference. No one wants to be the guy presenting code that causes everyone's eyes to bleed.
Unfortunately, reviews don't always scale well either up (too many cooks and so on) or down (we're way too busy coding to review code). Thankfully, there are some tips on Stack Overflow.
Code quality may be like pornography - as the famous quote from the Justice Potter Stewart goes, "I know it when I see it"
So one way is to ask others about the code quality. Some ways of doing that are...
Code reviews by their peers (and reviews of others code by them), with ease of comprehension being one of the criteria in the review checklist (personally, I don't think that necessarily means comments; sometimes code can be perfectly clear without them)
Request that issues caused by code quality are raised at retrospectives (you do hold retrospectives, right?)
Track how often changes to their code works first time, or whether it takes several attempts?
Ask for peer reviews at the annuak (or whatever) review time, and include a question about how easy it is to work with the reviewee's code as one of the questions.
The last person who broke the build or shipped code that caused a technical support call has to make the tea until somebody else does it next. The trouble is this person probably won't give the tea the attention it requires to make a real good cuppa.
I usually don't offer my team monetary awards, since they don't do much and we really can't afford them, but I usually sit down with each team member and go over the code with them individually, pointing out what works ("good" code) and what does not ("bad" code). This seems to work very well, since I don't get nearly as much junk code as I did before we started this process.
Be very careful with incentivizing: "What gets measured gets done". If you reward lines of code, you get bloated code. If you reward commenting, you get unnecessary comments. If you reward lack of bugs found in the code, your developers will do their own QA work which should be done by lower-paid QA specialists. Instead of incentivizing parts of the process, give bonuses for the whole team's success, or the whole company's.
IMO, a good code review process is the best way to ensure high code quality. Pair programming can work too, depending on the team, as a way of spreading good practices.
发布评论
评论（15）
这很难，因为激励性薪酬被认为是有害的。 我最好的建议是选择几个必须同时实现的目标，而不是一个可以被利用的目标。
This is tough as incentive pay is considered harmful. My best suggestion would be to pick several goals that all have to be met simultaneously, rather than one that can be exploited.
虽然大多数人认为代码审查是确保高质量代码的好方法，这是理所当然的，但在我看来，它们并不是实现这一目标的直接动力。 然而，对好代码提出积极的激励措施是很困难的，因为好代码的概念有很大一部分属于观点领域，而且几乎任何系统都可以被玩弄。
在我从事过的所有工作中，优秀的开发人员都有内在的动力去编写优秀的代码。 先有鸡还是先有蛋、反馈、第 22 条规则，无论你怎么称呼它，获得优秀代码的最佳方法就是雇用积极主动的开发人员。 创造一个优秀的开发人员愿意工作的环境可能是我能想到的最好的激励措施。 我不知道创建环境和寻找开发人员哪个更难。 两者都不容易，但从长远来看都是值得的。
我发现，创建优秀开发人员想要工作的环境的一部分包括确保开发人员谈论代码的情况。 我不知道哪个熟练的程序员不欣赏对其代码的良好批评。 这可以帮助那些想要成为最好的人变得更好。 作为这项工作的一个较小的子部分，以及创建优秀代码的间接激励，我认为代码审查非常有效。 是的，您的代码质量也应该获得一些直接的好处。
我和同事用来传达良好编码习惯的另一种技术是代码小组审查。 它不太正式，允许人们展示新技术、工具和功能。 人们提出了批评，公开给予了荣誉，大多数开发者似乎并不介意在一个他们认识每个人的小型开发者群体面前讲话。 如果管理层看不到这样做的好处，那就买三米饼并称之为棕色袋子。 开发人员也会喜欢免费食物。
我们还努力让人们参加代码活动。 当然，根据你们对这个主题的熟悉程度，您可能不会学到太多东西，但它会让人们思考代码一段时间，并让人们在更轻松的环境中进行讨论。 如果您随后提出喝一两杯饮料，大多数开发人员也会出现。
等一下，我注意到另一个主题。 免费食物！ 但说真的，关键是要创建一个环境，让那些已经写出好的代码的人和那些渴望学习的人都愿意工作。
While most people respond that code reviews are a good way to ensure high quality code, and rightfully so, they don't seem to me to be a direct incentive to getting there. However, coming up with a positive incentive for good code is difficult because the concept of good code has large areas that fall in the realm of opinion and almost any system can be gamed.
At all the jobs I have had, the good developers were intrinsically motivated to write good code. Chicken and egg, feedback, catch 22, call it what you will, the best way to get good code is to hire motivated developers. Creating an environment where good developers want to work is probably the best incentive I can think of. I'm not sure which is harder, creating the environment or finding the developers. Neither is easy, but both are worth it in the long term.
I have found that one part of creating an environment where good developers want to work includes ensuring situations where developers talk about code. I don't know a skilled programmer that doesn't appreciate a good critique of his code. This helps the people that like to be the best get better. As a smaller sub-part of this endeavor, and thus an indirect incentive to create good code, I think code reviews work wonderfully. And yes, your code quality should gain some direct benefit as well.
Another technique co-workers and I have used to communicate good coding habits is a group review in code. It was less formal and allowed people to show off new techniques, tools, features. Critiques were made, kudos were given publicly, and most developers didn't seem to mind speaking in front of a small developer group where they knew everyone. If management cannot see the benefit in this, spring for sammiches and call it a brown bag. Devs will like free food too.
We also made an effort to get people to go to code events. Granted, depending on how familiar you all are with the topic, you might not learn too much, but it keeps people thinking about code for a while and gets people talking in an even more relaxed environment. Most devs will also show up if you offer to pick up a round or two of drinks afterwards.
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.
这是针对您的建议，而不是针对您的老板。
永远提醒自己这样一个事实：如果你现在付出更多的努力并编写出尽可能好的代码，那么当你一周内没有重构你的东西时，这将会得到回报。
This is advice aimed at you, not your boss.
Always remind yourself of the fact that if you go that extra mile and write as good code as you can now, that'll pay off later when you don't have refactor your stuff for a week.
我认为编写好的代码的最佳激励是一起编写好的代码。 在项目的同一区域编写代码的人越多，代码约定、异常处理、注释、缩进和一般思维过程就越有可能相互接近。
并非所有代码都是统一的，但当人们一起编写大量工作时，维护通常会变得更容易，因为您可以作为一个团队学习风格并提出最佳实践。
I think the best incentive for writing good code is by writing good code together. The more people write code in the same areas of the project, the more likely it will be that code conventions, exception handling, commenting, indenting and general thought process will be closer to each other.
Not all code is going to be uniform, but upkeep usually gets easier when people have coded a lot of work together since you can pick up on styles and come up with best practice as a team.
你摆脱那些写不出好的代码的人。
我是认真的。
You get rid of the ones that don't write good code.
I'm completely serious.
我同意蜥蜴比尔的观点。 但我想补充比尔不得不说的话......
可以做的事情（假设有可用的资源）是让一些其他开发人员（也许1个对你的工作有所了解的人，1个非常了解你的工作的人，也许是 1 个对此知之甚少的人）一起，然后你引导他们完成你的代码。 你可以使用投影仪，让他们坐在房间里，然后你就可以完成所有的改变。 这样，您就有了一个可以提供意见、提出问题的混合人群，最重要的是让您成为更好的开发人员。
没有必要只有负面反馈； 然而，这种情况有时会发生。 将消极视为建设性非常重要，并且在提供反馈时尝试以建设性的方式表达您的反馈。
这里的想法是，如果您的函数有注释块，或者解释一些棘手的数学运算的注释块，或者解释为什么需要根据所选语言更改日期格式的简单注释行......那么你就不需要逐行指导小组你的代码在做什么。 这是一种注释您所做的更改的方法，它允许其他开发人员继续思考您在之前的函数中的模糊逻辑，因为他们可以阅读您的注释并查看您在其他地方做了什么。
这一切都来自现实生活的经历，我们在工作中继续使用这种方法。
希望这有帮助，好问题！
I agree with Bill The Lizard. But I wanted to add onto what Bill had to say...
Something that can be done (assuming resources are available) is to get some of the other developers (maybe 1 who knows something about your work, 1 who knows your work intimately, and maybe 1 who knows very little about it) together and you walk them through your code. You can use a projector and sit them down in a room and you can drive through all of your changes. This way, you have a mixed crowd that can provide input, ask questions, and above all make you a better developer.
There is no need to have only negative feedback; however, it will happen at times. It is important to take negative as constructive, and perhaps try to couch your feedback in a constructive way when giving feedback.
The idea here is that, if you have comment blocks for your functions, or a comment block that explains some tricky math operations, or a simple commented line that explains why you are required to change the date format depending on the language selected...then you will not be required to instruct the group line by line what your code is doing. This is a way to annotate changes you have made and it allows for the other developers to keep thinking about the fuzzy logic you had in your previous function because they can read your comments and see what you did else-where.
This is all coming from a real life experience and we continue to use this approach at my job.
Hope this helps, good question!
公开标准，并且不要将激励措施与任何类型的自动化联系起来。 公布您正在寻找的示例。 友善并鼓励人们公开他们自己的坏例子（以及他们如何纠正这些例子）。
团队文化的一部分就是“好的代码”； 这对很多人来说都是主观的，但一个正常运作的团队应该有一个明确的答案，并且团队中的每个人都同意。 任何不同意的人都会拖垮团队。
Make criteria public and do not connect incentives with any sort of automation. Publicize examples of what you are looking for. Be nice and encourage people to publicize their own bad examples (and how they corrected them).
Part of the culture of the team is what "good code" is; it's subjective to many people, but a functioning team should have a clear answer that everyone on the team agrees upon. Anyone who doesn't agree will bring the team down.
我不认为钱是个好主意。 原因是它是一种外在激励因素。 人们会开始遵守规则，因为这样做有经济激励，但这并不总是有效。 研究表明，随着人们年龄的增长，经济激励的激励作用逐渐减弱。 话虽这么说，在这种情况下，工作质量只会等于您设定的获得奖励的水平。 这只是短期的胜利而已。
激励人们做正确事情的真正方法是让他们相信他们的工作会变得更有价值。 他们会做得更好，效率也会更高。 激励人们的唯一真正方法是让他们愿意这样做。
I don't think money is a good idea. The reason being is that it is an extrinsic motivator. People will begin to follow the rules, because there is a financial incentive to do so, and this doesn't always work. Studies have shown that as people age financial incentives are less of a motivator. That being said, the quality of work in this situation will only be equal to the level you set to receive the reward. It's a short term win nothing more.
The real way to incent people to do the right thing is to convince them their work will become more rewarding. They'll be better at what they do and how efficient they are. The only real way to incentivize people is to get them to want to do it.
我认为正式的代码审查可以满足这个目的。 我更加小心，不要提交看起来很糟糕的代码，因为我知道我的团队中至少有另外两名开发人员会对其进行审查。
I think formal code reviews fill this purpose. I'm a little more careful not to commit crappy looking code knowing that at least two other developers on my team are going to review it.
代码审查如果做得好，可以产生巨大的影响。 没有人愿意成为那个提出让每个人都流血的代码的人。
不幸的是，审查并不总是能够很好地扩大规模（太多厨师等等）或缩小规模（我们太忙于编码而无法审查代码）。 值得庆幸的是，Stack Overflow 上有一些提示。
Code reviews, done well, can make a huge difference. No one wants to be the guy presenting code that causes everyone's eyes to bleed.
Unfortunately, reviews don't always scale well either up (too many cooks and so on) or down (we're way too busy coding to review code). Thankfully, there are some tips on Stack Overflow.
代码质量可能就像色情作品——正如大法官波特·斯图尔特（Potter Stewart）的名言所说，“当我看到它时我就知道了”
所以一种方法是向其他人询问代码质量。 这样做的一些方法是......
同行的代码审查（以及他们对其他代码的审查），易于理解是审查清单中的标准之一（就我个人而言，我认为这不一定意味着评论;有时，没有它们，代码也可以完全清晰）
要求在回顾中提出由代码质量引起的问题（你确实举行回顾，对吧？）
跟踪对其代码的更改第一次起作用的频率，或者是否需要多次尝试？
在年终审阅时间（或其他时间）请求同行评审，并提出一个关于使用被审阅者的代码是否容易的问题作为问题之一。
Code quality may be like pornography - as the famous quote from the Justice Potter Stewart goes, "I know it when I see it"
So one way is to ask others about the code quality. Some ways of doing that are...
Code reviews by their peers (and reviews of others code by them), with ease of comprehension being one of the criteria in the review checklist (personally, I don't think that necessarily means comments; sometimes code can be perfectly clear without them)
Request that issues caused by code quality are raised at retrospectives (you do hold retrospectives, right?)
Track how often changes to their code works first time, or whether it takes several attempts?
Ask for peer reviews at the annuak (or whatever) review time, and include a question about how easy it is to work with the reviewee's code as one of the questions.
嗯。
也许开发团队应该对彼此的代码进行代码审查。 这可以激励他们编写更好的带注释的代码。
Hm.
Maybe the development team should do code-reviews of each other codes. That could motivate them to write better, commented code.
最后一个破坏构建或发布代码并导致技术支持电话的人必须泡茶，直到其他人下一个这样做。 问题是这个人可能不会对茶给予足够的关注来泡一杯真正的好茶。
The last person who broke the build or shipped code that caused a technical support call has to make the tea until somebody else does it next. The trouble is this person probably won't give the tea the attention it requires to make a real good cuppa.
我通常不会向我的团队提供金钱奖励，因为他们做的不多，而且我们真的负担不起，但我通常会与每个团队成员坐下来，单独与他们一起检查代码，指出哪些有效（ “好”代码）和什么不（“坏”代码）。 这似乎工作得很好，因为我得到的垃圾代码几乎没有我们开始这个过程之前那么多。
I usually don't offer my team monetary awards, since they don't do much and we really can't afford them, but I usually sit down with each team member and go over the code with them individually, pointing out what works ("good" code) and what does not ("bad" code). This seems to work very well, since I don't get nearly as much junk code as I did before we started this process.
激励时要非常小心：“衡量的事情就会完成”。 如果你奖励代码行，你就会得到臃肿的代码。 如果你奖励评论，你就会得到不必要的评论。 如果你奖励代码中没有发现错误，那么你的开发人员将自己做质量检查工作，而这些工作应该由低薪的质量检查专家来完成。 不要激励流程的某些部分，而是为整个团队或整个公司的成功提供奖金。
IMO，良好的代码审查流程是确保高代码质量的最佳方式。 结对编程也可以作为传播良好实践的一种方式，具体取决于团队。
Be very careful with incentivizing: "What gets measured gets done". If you reward lines of code, you get bloated code. If you reward commenting, you get unnecessary comments. If you reward lack of bugs found in the code, your developers will do their own QA work which should be done by lower-paid QA specialists. Instead of incentivizing parts of the process, give bonuses for the whole team's success, or the whole company's.
IMO, a good code review process is the best way to ensure high code quality. Pair programming can work too, depending on the team, as a way of spreading good practices.