谁在敏捷环境中修改受影响的组件？

Question

在持续集成，敏捷环境中，如果我在A类中进行了更改（例如更改属性名称），我已经创建并且一直在处理，这会影响B类，它“属于”其他人，他修改了B级，每当我想检查我的变化？我或班级'B老板？

我想如果我修改它会更敏捷，这样我就不必通知其他人，但同时，处理它的人更了解修改它的影响...

Answer 1

在敏捷环境中，B类（与所有类一样）属于团队。我们称之为Shared Code Ownership。你应该检查工作代码;如果这意味着您需要调整B类以符合您对A类所做的更改 - 调整！更好的是，配对。

Answer 2

1. “个人和流程与工具之间的互动。”事先与受影响的其他人沟通变更。除非代码是微不足道的，否则您可能无法理解更改的全部影响。即使你这样做，也应该向你的其他队友通知他们。

2. “不要破坏构建。”检查您知道的代码将破坏构建不是一个好主意。与受影响的其他人通信后，与他们合作以完成代码更改。尝试检查代码更改，以便至少每晚构建不会被破坏。

只是我的意见......

鲍勃

Answer 3

  

每当我想检查我的更改时，谁修改了B类？我或班级'B老板？

没有不尊重，我认为你的问题是如此基本，以至于它清楚地暗示你甚至没有对敏捷意味着什么的基本理解。好吧，也许这就是你问这个问题的原因。

以下是我的建议：

1. 在这种情况下，你真的应该走向可能会受到你的变化影响的其他开发人员并快速面对面谈论这个，这个快速的对话可能会导致你们对编程进行编程确保构建不会破坏，并且没有人受到影响。

2. 请再次阅读所有敏捷原则，并写下您对每个原则的理解。在日常开发生活中实施这些原则。这是成为敏捷的唯一途径。没有任何证明或书籍可供参考，以使某人敏捷地成为敏捷。敏捷必须自我实现，因此每天都要练习它们，直到它们成为一种习惯。

因此，使用最有效的方法即f2f会话传达“信息”。问题是在集体责任原则的基础上解决的，最理想的解决方法是结对编程。

参考： 敏捷原则 “最有效，最有效的方法 向开发中和开发内部传递信息 团队是面对面的对话。“

宣言中的一般敏捷指南： “响应遵循计划的变化”

Answer 4

敏捷包括团队代码所有权，沟通

正如@Carl Manaster所说，代码属于团队。正如@rcravens所说，敏捷就是沟通。与B的作者快速会面并让他们知道您的建议已更改，以确保您了解您的影响。如果它很复杂，请与B的作者配对。当更改完成后，如果您认为它可能会影响团队中的其他开发人员，请召开简短的团队会议并让他们知道更改。

顺便问一下，你的设计如何？

您的问题也可能揭示出设计问题 - A和B可能过于紧密耦合。在测试工作并且您已实现更改后，我建议您检查代码并查看是否需要重构。 （请记住，TDD是Red/Green/Refactor）特别是，如果更改A类意味着您必须更改B类，那么您可能不会遵循Single Responsibility Principle (SRP)练习的SOLID部分。