We lean heavily on ITIL concepts. While we don't need the full scale ITSM that ITIL provides, we have implemented processes that draw from some of the best practices in ITIL, specifically in the areas of Change Management and Release Management.
Code reviews are part of our RM strategy. As a change or new piece of code makes its way through our RM process, a lot of eyes look at it. Ultimately the Release Manager makes the call on approval or rework, and all of this is documented (we use TFS and SharePoint). Formal code reviews are held by the Release Manager and the technical team he selects. The primary developer for a release candidate is held accountable for adherence to standards, functionality, and a verification of a completed test plan. If the quality standards aren't met, the deliverable is rejected and the project schedule is updated to reflect the rework.
Yes, this is all very heavy. I work in government and we have complex laws to follow, specifically in the areas of taxes, ADA compliance, and so on.
1) The developer is responsible for fixing bugs in code when unit tests don't exist. In cases where there is a test, the person breaking the test is responsible for fixing it.
2) Code reviews. There are some code review smells that are a good warning sign, over defensiveness and blame redirection being the two most common.
3) NO EMAILING CODE, JARs or config files. Everything is in the scm.
To create the culture 1st try define your standards and values and most of all make them known.
Then hire people who believe in them or who could be able to adapt to them. Don't hire someone who does not have any connection at all with your company values.
Make sure that those who respect these values and show improvements are "rewarded" and "properly" recognized and seen as models. Don't forget that for many is not all about the money.
Don't hesitate to take appropriate measures againts those who do not fulfill their responsibilities but make sure they know them. And have them accountable for their deeds. Allow people to become used with any new responsibility.
To make change in culture is big deal. Still there are some ways to change.
Create awareness about code review and importance of code review tool. It can be done using training session.
Motivate the people : Giving some reward for the code reviews.
Change in process : Make sure that code review should be happen and properly. It can be done using checklist and part of release process.
Do not try to change completely. Slowly introduce newer changes. Create small group to observe and discuss the change in code review process.
Provide the solution instead of create problem. Process should not be overhead. It comes automatically. Provide solutions to peoples problem related to the process.
• Our company uses peer code reviews. We conduct them as Over-The-Shoulder reviews and invite the team’s tester to participate in the meeting to gain a better understanding of the changes. We use Source Control software that requires check-in, code-review rules to be signed off. Nothing big, just another developer's name that has reviewed the code.
• There are definite benefits to code review as several studies have been able to demonstrate. For our company, it was evident that code quality increased as the number of support calls decreased and the number of reported bugs decreased as well. NOTE: Some of the benefits here were the result of implementing Scrum and abandoning Waterfall. More on Scrum below.
• The benefits of code review can be a more stable product, more maintainable code as it applies to structure and coding standards, and it allows developers to focus more on new features rather than “fire-fighting” bugs, and other production issues. There really aren’t any drawbacks if code reviews are conducted “right”. More on the “right way” below.
• Some of the hurdles to overcome while implementing code reviews are the idea that “big brother” is watching me and the idea that not having perfect code means torture and pain. Getting developers to trust each other is difficult sometimes, especially when it involves “pecking order” or the “holier than thou” attitudes and putting your hard work under a microscope. Trust is the key to resolving these issues. A developer must trust that they will not be punished by peers or management for mistakes in code. It happens to everyone. Make a note of the issue, get it resolved and move on.
Scrum One of the benefits of using the Scrum methodology is that a development cycle (”sprint”) is short. The time-frame of the “sprint” is determined by what works best for your organization and will need some trial and error, but really shouldn’t be longer than four week iterations. The benefit is that it requires the developers communicate daily and communicate problems early on in the project. This was initially adopted by our development department and has spread to all areas of our company as the benefits of scrum are far reaching. For more information, see: http://en.wikipedia.org/wiki/SCRUM or http://www.scrumalliance.org/ . As the development iterations are smaller, the code review process reviews smaller pieces of code, making the review more likely to find problems than hours or days of formal reviews.
“Right Way” Code Reviews done the “right way” is completely subjective. However, I personally believe that they should be informal, over-the-shoulder reviews. All of the participants in a review should avoid personally attacking the person being reviewed with statements such as “why did you do it that way?” or “what were you thinking?” etc. These types of comments diminish the trust between peers, leading to animosity, hours of arguing over the best/right way to code a solution. Keep in mind that developers do not think or code exactly the same, and there are many solutions to a problem. Just a little clarification on over-the-shoulder reviews; these can be conducted via remote desktop sharing (pick flavor here), or in person. However, they shouldn’t be limited to the developers only. We typically invite our entire scrum team which consists of two developers per team, a tester, a documentation person, and product owner. All non-developers are there to gain a better understanding of the changes or new functionality being made. They are free to ask questions or provide input, but not to make coding decisions or comments. This has been effective as certain questions will be asked that may change the direction of the project as the initial requirements may have missed a scenario, but that is what agile is all about, change.
Suggestion I would highly recommend researching scrum and code reviews, before mandating them. Create the basic rules for each and implement them as part of your culture to achieve a better quality product. It must become part of your culture so that it is part of a natural process and integrated at all levels, as it is a paradigm shift from poor quality, missed deadlines and frustration to better quality products, less frustration, and more on-time deliverables.
If you want to ensure that every changelist gets reviewed, before checkin, then you could have your source control tool reject unreviewed checkins. For example, a trigger could reject checkins without "CodeReview: " in the checkin comment. Although people could still lie, they could also be held accountable.
If you want to ensure that every changelist gets reviewed, after checkin, then you could see if Code Collaborator will play nicely with your source control system and automatically make a review task after each checkin (push or pull; whatever works). After that, use whatever "polite annoyance" features Code Collaborator has, to make sure reviews actually get done.
If you want people to review only some checkins, not all checkins, then good luck with that.
We have a pretty cool setup. Coders are expected to test their code before check-ins to ensure that it doesn't break the build and to write tests where they make sense to have but high coverage isn't required.
Complex methods are expected to be commented.
At the end of phases code is reviewed by the whole team.
发布评论
评论（8）
结对编程。 工作项目具有必填的协作者字段，即与您配对完成工作的人员
Pair programming. Work items have a required field of collaborator, the person that you paired with for the work
我们严重依赖 ITIL 概念。 虽然我们不需要 ITIL 提供的全面 ITSM，但我们已经实施了借鉴 ITIL 中一些最佳实践的流程，特别是在变更管理和发布管理领域。
代码审查是我们 RM 策略的一部分。 当更改或新代码通过我们的 RM 流程时，很多人都会关注它。 最终，发布经理决定批准或返工，所有这些都记录在案（我们使用 TFS 和 SharePoint）。 正式的代码审查由发布经理和他选择的技术团队进行。 候选版本的主要开发人员负责遵守标准、功能以及对已完成的测试计划的验证。 如果不符合质量标准，则交付成果将被拒绝，项目进度表将更新以反映返工情况。
是的，这一切都很沉重。 我在政府工作，我们需要遵守复杂的法律，特别是在税收、ADA 合规性等领域。
We lean heavily on ITIL concepts. While we don't need the full scale ITSM that ITIL provides, we have implemented processes that draw from some of the best practices in ITIL, specifically in the areas of Change Management and Release Management.
Code reviews are part of our RM strategy. As a change or new piece of code makes its way through our RM process, a lot of eyes look at it. Ultimately the Release Manager makes the call on approval or rework, and all of this is documented (we use TFS and SharePoint). Formal code reviews are held by the Release Manager and the technical team he selects. The primary developer for a release candidate is held accountable for adherence to standards, functionality, and a verification of a completed test plan. If the quality standards aren't met, the deliverable is rejected and the project schedule is updated to reflect the rework.
Yes, this is all very heavy. I work in government and we have complex laws to follow, specifically in the areas of taxes, ADA compliance, and so on.
我们使用三个基本规则
1) 当单元测试不存在时，开发人员负责修复代码中的错误。 如果有测试，破坏测试的人有责任修复它。
2）代码审查。 有一些代码审查气味是一个很好的警告信号，过度防御和指责重定向是最常见的两种。
3) 无需通过电子邮件发送代码、JAR 或配置文件。 一切都在scm中。
We use three basic rules
1) The developer is responsible for fixing bugs in code when unit tests don't exist. In cases where there is a test, the person breaking the test is responsible for fixing it.
2) Code reviews. There are some code review smells that are a good warning sign, over defensiveness and blame redirection being the two most common.
3) NO EMAILING CODE, JARs or config files. Everything is in the scm.
要创造这种文化，首先要尝试定义您的标准和价值观，最重要的是让它们为人所知。
然后雇用相信它们或能够适应它们的人。 不要雇用与你的公司价值观没有任何关系的人。
确保那些尊重这些价值观并表现出进步的人得到“奖励”和“适当”认可并被视为榜样。 不要忘记，对许多人来说，这并不全是为了钱。
对于那些不履行职责的人，要毫不犹豫地采取适当措施，但要确保他们了解这些情况。 并让他们对自己的行为负责。
允许人们承担任何新的责任。
To create the culture 1st try define your standards and values and most of all make them known.
Then hire people who believe in them or who could be able to adapt to them. Don't hire someone who does not have any connection at all with your company values.
Make sure that those who respect these values and show improvements are "rewarded" and "properly" recognized and seen as models. Don't forget that for many is not all about the money.
Don't hesitate to take appropriate measures againts those who do not fulfill their responsibilities but make sure they know them. And have them accountable for their deeds.
Allow people to become used with any new responsibility.
改变文化是一件大事。 仍然有一些方法可以改变。
提高对代码审查和代码审查工具重要性的认识。 这可以通过培训课程来完成。
激励人们：对代码审查给予一些奖励。
流程中的更改：确保代码审查应该进行且正确。 可以使用清单和发布过程的一部分来完成。
不要尝试完全改变。 慢慢引入新的变化。 创建小组来观察和讨论代码审查过程中的变化。
To make change in culture is big deal. Still there are some ways to change.
Create awareness about code review and importance of code review tool. It can be done using training session.
Motivate the people : Giving some reward for the code reviews.
Change in process : Make sure that code review should be happen and properly. It can be done using checklist and part of release process.
Do not try to change completely. Slowly introduce newer changes. Create small group to observe and discuss the change in code review process.
• 我们公司使用同行代码审查。 我们以过肩审查的方式进行，并邀请团队的测试人员参加会议，以更好地了解变更。 我们使用需要签入、代码审查规则才能签署的源代码控制软件。 没什么大不了的，只是另一个审查过代码的开发人员的名字。
• 多项研究已经证明，代码审查确实有好处。 对于我们公司来说，随着支持电话数量的减少和报告的错误数量的减少，代码质量明显提高。 注意：这里的一些好处是实施 Scrum 和放弃瀑布的结果。 更多关于 Scrum 的内容请参见下文。
• 代码审查的好处是可以提供更稳定的产品、更易于维护的代码，因为它适用于结构和编码标准，并且它允许开发人员更多地关注新功能，而不是“救火”错误和其他生产问题。 如果代码审查“正确”进行，那么确实没有任何缺点。 下面详细介绍“正确的方法”。
• 实施代码审查时需要克服的一些障碍是“老大哥”在监视我的想法以及没有完美代码意味着折磨和痛苦的想法。 让开发人员相互信任有时很困难，特别是当它涉及“啄食顺序”或“比你更神圣”的态度以及将你的辛勤工作放在显微镜下时。 信任是解决这些问题的关键。 开发人员必须相信他们不会因为代码错误而受到同事或管理层的惩罚。 每个人都会遇到这种情况。 记下问题，解决它并继续。
Scrum
使用 Scrum 方法的好处之一是开发周期（“冲刺”）很短。 “冲刺”的时间框架取决于最适合您的组织的方式，并且需要一些尝试和错误，但实际上不应超过四个星期的迭代。 好处是，它需要开发人员每天进行沟通，并在项目早期就问题进行沟通。 这最初由我们的开发部门采用，并扩展到我们公司的所有领域，因为 Scrum 的好处是深远的。 有关详细信息，请参阅：http://en.wikipedia.org/wiki/SCRUM 或 < a href="http://www.scrumalliance.org/" rel="noreferrer">http://www.scrumalliance.org/ 。 由于开发迭代较小，代码审查过程会审查较小的代码片段，从而使审查比数小时或数天的正式审查更有可能发现问题。
“正确的方式”
以“正确的方式”完成代码审查完全是主观的。 然而，我个人认为它们应该是非正式的、实时的评论。 审查的所有参与者都应避免使用诸如“你为什么这样做？”之类的言论对接受审查的人进行人身攻击。 或“你在想什么？” 这些类型的评论削弱了同行之间的信任，导致敌意，导致人们为了编写解决方案的最佳/正确方法而争论数小时。 请记住，开发人员的思维或代码并不完全相同，而且问题的解决方案有多种。
只是对过肩评论做一点澄清； 这些可以通过远程桌面共享（在此处选择风格）或亲自进行。 但是，它们不应仅限于开发人员。 我们通常会邀请整个 Scrum 团队，每个团队由两名开发人员、一名测试人员、一名文档人员和产品负责人组成。 所有非开发人员都可以更好地了解所做的更改或新功能。 他们可以自由提出问题或提供意见，但不能做出编码决策或评论。 这是有效的，因为会提出某些问题，这些问题可能会改变项目的方向，因为最初的需求可能错过了某个场景，但这就是敏捷的全部内容，即改变。
建议
我强烈建议在强制执行之前研究一下 Scrum 和代码审查。 为每个规则创建基本规则并将其作为您的文化的一部分实施，以实现更高质量的产品。 它必须成为你的文化的一部分，这样它就成为一个自然过程的一部分，并在各个层面上进行整合，因为它是一种范式转变，从质量差、错过最后期限和挫折到更高质量的产品、更少的挫折和更多的按时交付。
• Our company uses peer code reviews. We conduct them as Over-The-Shoulder reviews and invite the team’s tester to participate in the meeting to gain a better understanding of the changes. We use Source Control software that requires check-in, code-review rules to be signed off. Nothing big, just another developer's name that has reviewed the code.
• There are definite benefits to code review as several studies have been able to demonstrate. For our company, it was evident that code quality increased as the number of support calls decreased and the number of reported bugs decreased as well. NOTE: Some of the benefits here were the result of implementing Scrum and abandoning Waterfall. More on Scrum below.
• The benefits of code review can be a more stable product, more maintainable code as it applies to structure and coding standards, and it allows developers to focus more on new features rather than “fire-fighting” bugs, and other production issues. There really aren’t any drawbacks if code reviews are conducted “right”. More on the “right way” below.
• Some of the hurdles to overcome while implementing code reviews are the idea that “big brother” is watching me and the idea that not having perfect code means torture and pain. Getting developers to trust each other is difficult sometimes, especially when it involves “pecking order” or the “holier than thou” attitudes and putting your hard work under a microscope. Trust is the key to resolving these issues. A developer must trust that they will not be punished by peers or management for mistakes in code. It happens to everyone. Make a note of the issue, get it resolved and move on.
Scrum
One of the benefits of using the Scrum methodology is that a development cycle (”sprint”) is short. The time-frame of the “sprint” is determined by what works best for your organization and will need some trial and error, but really shouldn’t be longer than four week iterations. The benefit is that it requires the developers communicate daily and communicate problems early on in the project. This was initially adopted by our development department and has spread to all areas of our company as the benefits of scrum are far reaching. For more information, see: http://en.wikipedia.org/wiki/SCRUM or http://www.scrumalliance.org/ . As the development iterations are smaller, the code review process reviews smaller pieces of code, making the review more likely to find problems than hours or days of formal reviews.
“Right Way”
Code Reviews done the “right way” is completely subjective. However, I personally believe that they should be informal, over-the-shoulder reviews. All of the participants in a review should avoid personally attacking the person being reviewed with statements such as “why did you do it that way?” or “what were you thinking?” etc. These types of comments diminish the trust between peers, leading to animosity, hours of arguing over the best/right way to code a solution. Keep in mind that developers do not think or code exactly the same, and there are many solutions to a problem.
Just a little clarification on over-the-shoulder reviews; these can be conducted via remote desktop sharing (pick flavor here), or in person. However, they shouldn’t be limited to the developers only. We typically invite our entire scrum team which consists of two developers per team, a tester, a documentation person, and product owner. All non-developers are there to gain a better understanding of the changes or new functionality being made. They are free to ask questions or provide input, but not to make coding decisions or comments. This has been effective as certain questions will be asked that may change the direction of the project as the initial requirements may have missed a scenario, but that is what agile is all about, change.
Suggestion
I would highly recommend researching scrum and code reviews, before mandating them. Create the basic rules for each and implement them as part of your culture to achieve a better quality product. It must become part of your culture so that it is part of a natural process and integrated at all levels, as it is a paradigm shift from poor quality, missed deadlines and frustration to better quality products, less frustration, and more on-time deliverables.
如果您想确保每个变更列表在签入之前都经过审核，那么您可以让源代码管理工具拒绝未经审核的签入。 例如，触发器可以拒绝签入注释中没有“CodeReview：”的签入。 尽管人们仍然可以撒谎，但他们也可以承担责任。
如果您想确保每个变更列表在签入后都得到审核，那么您可以看看 Code Collaborator 是否能与您的源代码控制系统很好地配合，并在签入后自动执行审核任务每次签入（推或拉；无论有效）。 之后，使用 Code Collaborator 具有的任何“礼貌烦恼”功能，以确保审核真正完成。完成。
如果您希望人们只查看部分签到，而不是全部签到，那么祝你好运。
If you want to ensure that every changelist gets reviewed, before checkin, then you could have your source control tool reject unreviewed checkins. For example, a trigger could reject checkins without "CodeReview: " in the checkin comment. Although people could still lie, they could also be held accountable.
If you want to ensure that every changelist gets reviewed, after checkin, then you could see if Code Collaborator will play nicely with your source control system and automatically make a review task after each checkin (push or pull; whatever works). After that, use whatever "polite annoyance" features Code Collaborator has, to make sure reviews actually get done.
If you want people to review only some checkins, not all checkins, then good luck with that.
我们有一个非常酷的设置。 编码人员应该在签入之前测试他们的代码，以确保它不会破坏构建，并在有意义但不需要高覆盖率的地方编写测试。
复杂的方法预计会被注释。
在阶段结束时，整个团队都会审查代码。
We have a pretty cool setup. Coders are expected to test their code before check-ins to ensure that it doesn't break the build and to write tests where they make sense to have but high coverage isn't required.
Complex methods are expected to be commented.
At the end of phases code is reviewed by the whole team.