在您的“企业”工作环境中，工程师如何对执行代码检查和单元测试负责？您遵循哪些流程（正式方法或自定义流程）来确保软件质量？您是否尝试过为可交付成果实施开发人员“签收”表？
提前致谢！
更新：我忘了提到我们正在使用 Code Collaborator 来执行我们的检查。问题是让人们“得到它”并接受在核心人群之外做这些事情。正如 stalbot 在下面指出的那样，这是一种文化变革，但问题变成了，您如何改变您的文化以促进质量计划，例如审查/单元测试？
Berkshire
问问题
1247 次
8 回答
5
于 2008-11-06T16:15:32.950 回答
3
如果您想确保在签入之前检查每个更改列表，那么您可以让您的源代码控制工具拒绝未经审查的签入。例如，触发器可以拒绝签入注释中没有“CodeReview：”的签入。尽管人们仍然可以撒谎，但他们也可以被追究责任。
如果您想确保在签入后对每个更改列表进行审查，那么您可以查看 Code Collaborator 是否可以很好地与您的源代码控制系统配合使用，并在每次签入后自动执行审查任务（推送或拉取；任何工作）。之后，使用 Code Collaborator 拥有的任何“礼貌的烦恼”功能，以确保真正完成审查。
如果您希望人们只查看一些签到，而不是所有签到，那么祝您好运。
于 2008-11-06T21:31:41.300 回答
2
我们有一个非常酷的设置。编码人员应该在签入之前测试他们的代码，以确保它不会破坏构建，并在有意义但不需要高覆盖率的地方编写测试。
复杂的方法预计会被评论。
在阶段结束时，整个团队都会审查代码。
于 2008-11-06T15:08:16.160 回答
2
结对编程。工作项的必填字段是合作者，即您与工作配对的人
于 2008-11-17T00:30:57.467 回答
1
我们严重依赖 ITIL 概念。虽然我们不需要 ITIL 提供的全面 ITSM，但我们已经实施了借鉴 ITIL 中一些最佳实践的流程，特别是在变更管理和发布管理领域。
代码审查是我们 RM 策略的一部分。当更改或新代码通过我们的 RM 流程时，很多人都会关注它。最终，发布经理发出批准或返工的呼吁，所有这些都记录在案（我们使用 TFS 和 SharePoint）。正式的代码审查由发布经理和他选择的技术团队进行。发布候选的主要开发人员负责遵守标准、功能和验证已完成的测试计划。如果未达到质量标准，则拒绝交付成果并更新项目进度表以反映返工。
是的，这一切都很沉重。我在政府工作，我们有复杂的法律要遵守，特别是在税收、ADA 合规等领域。
于 2008-11-06T15:07:08.660 回答
0
我们使用三个基本规则
1）当单元测试不存在时，开发人员负责修复代码中的错误。在有测试的情况下，打破测试的人负责修复它。
2) 代码审查。有一些代码审查气味是一个很好的警告信号，过度防御和责备重定向是最常见的两种。
3) 没有电子邮件代码、JAR 或配置文件。一切都在 scm 中。
于 2008-11-06T21:11:48.890 回答
0
创造文化首先尝试定义你的标准和价值观，最重要的是让他们知道。
然后雇用相信他们或能够适应他们的人。不要雇用与您的公司价值观完全没有任何联系的人。
确保那些尊重这些价值观并表现出改进的人得到“奖励”和“适当”的认可并被视为榜样。不要忘记，对许多人来说，钱并不全是。
不要犹豫，对那些不履行职责但确保他们了解他们的人采取适当的措施。并让他们为自己的行为负责。让人们习惯于承担任何新的责任。
于 2010-10-16T10:44:58.917 回答
0
改变文化是一件大事。仍然有一些方法可以改变。
提高对代码审查和代码审查工具重要性的认识。可以使用培训课程来完成。
激励人们：对代码审查给予一些奖励。
过程中的变化：确保应该正确地进行代码审查。它可以使用清单和发布过程的一部分来完成。
不要试图完全改变。慢慢引入更新的变化。创建小组来观察和讨论代码审查过程中的变化。
- 提供解决方案而不是制造问题。过程不应该是开销。它会自动出现。为人们与流程相关的问题提供解决方案。
于 2010-10-22T07:16:02.857 回答