工程师问责制和代码审查流程

在您的“企业”工作环境中，工程师如何对执行代码检查和单元测试负责？您遵循什么过程（正式方法或自定义过程）来确保软件质量？您是否尝试过为可交付成果实施开发人员“签署”工作表？

提前致谢！

更新：我忘了提到我们正在使用Code Collaborator进行检查。问题在于让人们“得到它”并愿意在一群核心人之外去做。正如跟踪专家在下面指出的那样，这是文化的变化，但是问题就变成了，您如何改变自己的文化以促进诸如审查/单元测试之类的高质量计划？

•我们公司使用同行代码审查。我们将其作为“过度提示”进行审核，并邀请团队的测试人员参加会议以更好地了解更改。我们使用Source Control软件，该软件要求签入，代码审查规则进行签名。没什么大不了的，只是另一个审查了代码的开发人员的名字。

•几项研究已经证明，代码审查具有明显的好处。对于我们公司来说，很明显，随着支持电话数量的减少和报告错误的数量的减少，代码质量也得到了提高。注意：这里的一些好处是实施Scrum和放弃Waterfall的结果。有关Scrum的更多信息，请参见下文。

•代码审查的好处可能是产品更稳定，代码更易于维护，因为它适用于结构和编码标准，并且使开发人员可以将更多的精力放在新功能上，而不是“灭火”错误和其他生产问题上。如果“正确”进行代码审查，实际上没有任何缺点。更多关于下面的“正确方法”。

•实施代码审查时要克服的一些障碍是“老大哥”在注视着我，而没有完善的代码则意味着折磨和痛苦。有时很难使开发人员彼此信任，特别是在涉及“啄食顺序”或“比您更居高临下”的态度并将您的辛勤工作放在显微镜下时。信任是解决这些问题的关键。开发人员必须相信，他们不会因代码错误而受到同行或管理层的惩罚。它发生在每个人身上。记下该问题，使其解决并继续。

Scrum 使用Scrum方法的好处之一是开发周期（“冲刺”）很短。“冲刺”的时间范围由最适合您的组织的情况决定，需要进行反复试验，但实际上不应超过四个星期。好处是，它要求开发人员每天进行沟通，并在项目早期尽早沟通问题。此方法最初是由我们的开发部门采用的，并且随着scrum的好处深远地影响到了公司的所有领域。有关更多信息，请参见：http : //en.wikipedia.org/wiki/SCRUM或http://www.scrumalliance.org/。随着开发迭代次数的减少，代码审查过程将审查较小的代码段，与数小时或数天的正式审查相比，使审查更有可能发现问题。

“正确的方法” 完成“正确方法”的代码审查完全是主观的。但是，我个人认为，它们应该是非正式的，肩负重任的审查。审阅的所有参与者都应避免使用诸如“您为什么这样做？”或“您在想什么？”之类的言论来亲自攻击被审问的人。这些类型的评论会削弱同行之间的信任，导致令人厌恶的是，为解决方案编写最佳/正确方法的争论数小时。请记住，开发人员的想法或代码并不完全相同，并且有许多解决方案。只是对肩膀的评论做了一些澄清；这些可以通过远程桌面共享（在此处选择口味）进行，也可以亲自进行。但是，它们不应仅局限于开发人员。通常，我们邀请整个Scrum团队，每个团队由两个开发人员，一个测试人员，一个文档编制人员和产品所有者组成。所有非开发人员都可以在那里更好地了解所做的更改或进行的新功能。他们可以自由地提出问题或提供意见，但不能做出编码决定或评论。这是有效的，因为可能会问到某些问题，这些问题可能会改变项目的方向，因为最初的需求可能错过了一个方案，但这就是敏捷性的全部改变。

建议 我强烈建议在授权之前研究scrum和代码审查。为每个规则创建基本规则，并将其作为您文化的一部分加以实施，以获得更高质量的产品。它必须成为您的文化的一部分，以便成为自然过程的一部分，并在各个层面进行整合，因为这是从不良质量，错过了截止日期和沮丧的范式转变到了质量更高的产品，更少的沮丧和更多按时交付的产品。