在您的“企业”工作环境中，工程师如何对执行代码检查和单元测试负责？您遵循哪些流程（正式方法或自定义流程）来确保软件的质量？您是否尝试过实施开发人员“签收”表以获取可交付成果？
提前致谢！
更新：我忘了提及我们正在使用Code Collaborator来执行检查。问题是让人们“得到它”并购买在核心人群之外做这些事情。正如stalbot指出的那样，这是一种文化变革，但问题在于，您如何改变您的文化以推广质量计划，例如评论/单元测试？
答案 0 :(得分：5)
•我们公司使用同行代码审查。我们将其作为Over-The-Shoulder进行评审，并邀请团队的测试人员参加会议，以更好地了解变化。我们使用需要签入的源代码管理软件，签署代码审查规则。没什么大的，只是另一个开发人员的名字已经审查了代码。
•一些研究已经证明，代码审查有一定的好处。对于我们公司来说，很明显代码质量随着支持呼叫数量的减少而增加，报告的错误数量也减少了。注意：这里的一些好处是实现Scrum和放弃Waterfall的结果。更多关于Scrum的信息。
•代码审查的好处可以是更稳定的产品，更易于维护的代码，因为它适用于结构和编码标准，并且它允许开发人员更多地关注新功能而不是“消防”错误，以及其他生产的问题。如果代码审查是“正确的”，那么确实没有任何缺点。更多关于下面的“正确方法”。
•在实施代码审查时要克服的一些障碍是“大哥”正在关注我的想法以及没有完美代码意味着折磨和痛苦的想法。让开发人员彼此信任是很困难的，特别是当涉及“啄食顺序”或“比你更圣洁”的态度并将你的辛勤工作放在显微镜下时。信任是解决这些问题的关键。开发人员必须相信，对于代码中的错误，他们不会受到同事或管理层的惩罚。它发生在每个人身上。记下问题，解决问题并继续前进。
<强>的Scrum 使用Scrum方法的一个好处是开发周期（“sprint”）很短。 “冲刺”的时间范围取决于哪种方式最适合您的组织，需要一些试验和错误，但实际上不应超过四周的迭代次数。好处是它需要开发人员每天进行通信并在项目早期就沟通问题。这最初是由我们的开发部门采用的，并且已经扩展到我们公司的所有领域，因为scrum的好处是深远的。有关详细信息，请参阅：http://en.wikipedia.org/wiki/SCRUM或http://www.scrumalliance.org/。由于开发迭代较小，代码审查过程会审查较小的代码片段，使得审核更容易发现问题，而不是数小时或数天的正式审核。
“正确的方式” 完成“正确方式”的代码审查是完全主观的。但是，我个人认为他们应该是非正式的，过分的评论。审查中的所有参与者都应该避免使用诸如“你为什么这样做？”或“你在想什么？”等陈述来亲自攻击被审查人。这些类型的评论减少了同行之间的信任，导致仇恨，争论解决方案的最佳/正确方式的几个小时。请记住，开发人员不会考虑或编码完全相同，并且有许多解决方案可以解决问题。 稍微澄清一下肩负的评论;这些可以通过远程桌面共享（在这里选择风味）或亲自进行。但是，它们不应仅限于开发人员。我们通常邀请我们的整个Scrum团队，每个团队包括两名开发人员，一名测试人员，一名文档人员和产品负责人。所有非开发人员都可以更好地了解所做的更改或新功能。他们可以自由提问或提供意见，但不能做出编码决定或评论。这是有效的，因为某些问题可能会改变项目的方向，因为最初的要求可能已经错过了一个场景，但这就是敏捷的全部，改变。
<强>建议 在强制要求之前，我强烈建议研究Scrum和代码审查。为每个项目创建基本规则，并将其作为您文化的一部分来实施，以获得更高质量的产品。它必须成为您文化的一部分，以便它成为自然过程的一部分并融入各个层面，因为它是从质量差，错过最后期限和挫折到更高质量的产品，更少的挫折和更多准时交付的范式转变
答案 1 :(得分：3)
如果您想确保每个更改列表都经过审核，签入之前，那么您可以让源控制工具拒绝未审核的签入。例如，触发器可以在签入注释中拒绝没有“CodeReview：”的签名。虽然人们仍然可以撒谎，但他们也可能被追究责任。
如果您想确保每个更改列表都经过审核，在签入后，那么您可以看到Code Collaborator是否可以很好地与源控制系统配合使用并自动生成每次签到后审查任务（推或拉;无论什么工作）。之后，使用Code Collaborator所具有的“礼貌烦恼”功能，以确保评论实际上已完成。
如果您希望人们仅查看部分签到，而不是所有签到，那么祝你好运。
答案 2 :(得分：2)
我们有一个非常酷的设置。编码器应该在签入之前测试他们的代码，以确保它不会破坏构建并在有意义的地方编写测试，但不需要高覆盖率。
预计会对复杂方法进行评论。
在阶段结束时，整个团队都会审核代码。
答案 3 :(得分：2)
结对编程。工作项目具有必需的协作者字段，即您与工作配对的人员
答案 4 :(得分：1)
我们非常依赖ITIL概念。虽然我们不需要ITIL提供的全面ITSM，但我们已经实施了从ITIL中的一些最佳实践中获取的流程，特别是在变更管理和发布管理领域。
代码审核是我们RM策略的一部分。随着更改或新代码通过我们的RM流程，很多人都会关注它。最终，发布管理器会对批准或返工进行调用，所有这些都会记录在案（我们使用TFS和SharePoint）。正式代码审查由发布经理和他选择的技术团队进行。候选版本的主要开发人员要对遵守标准，功能和完整测试计划的验证负责。如果不符合质量标准，则拒绝交付物并更新项目进度表以反映返工。
是的，这一切都非常沉重。我在政府工作，我们有复杂的法律，特别是在税收，ADA合规等方面。
答案 5 :(得分：0)
我们使用三个基本规则
1）当单元测试不存在时，开发人员负责修复代码中的错误。在有测试的情况下，违反测试的人有责任进行测试。
2）代码审查。有一些代码审查气味是一个很好的警示标志，防御性和责备重定向是最常见的两种。
3）没有电子邮件代码，JAR或配置文件。一切都在scm中。
答案 6 :(得分：0)
创建文化第一次尝试定义您的标准和价值观，最重要的是让它们为人所知。
然后聘请相信他们或能够适应他们的人。不要聘请与您的公司价值观完全无关的人。
确保那些尊重这些价值并表现出改进的人得到“奖励”和“正确”认可并被视为模特。不要忘记，对许多人而言，不仅仅是钱。
不要犹豫，对那些不履行职责但确保他们了解责任的人采取适当措施。让他们对自己的行为负责。 允许人们使用任何新的责任。
答案 7 :(得分：0)
改变文化是很重要的。还有一些方法可以改变。
创建代码审核意识和代码审核工具的重要性。可以使用培训课程来完成。
激励员工：为代码审核提供一些奖励。
流程变更：确保代码审核应该正确进行。可以使用清单和部分发布流程来完成。
不要试图完全改变。慢慢引入新的变化。创建小组以观察和讨论代码审查过程中的变化。