在敏捷环境中，B 类（与所有类一样）属于团队。我们称之为共享代码所有权。您应该检查工作代码；如果这意味着您需要调整 B 类以符合您对 A 类所做的更改 - 调整！更好的是，配对。
In an agile environment, class B (like all classes) belongs to the team. We call this Shared Code Ownership. You should check in working code; if that means you need to adjust class B to conform to the changes you make to class A - adjust! Better yet, pair.
"Individuals and interactions over process and tools." Communicate the change upfront with the other people impacted. Unless the code is trivial, you may not understand the full impact of the change. Even if you do, you owe it to your other teammates to keep them informed.
"Don't break the build." Checking code in that you know will break the build is not a good idea. Once you have communicated with the others that are impacted, work with them to get the code changes completed. Attempt to get the code changes checked in so at least the nightly build is not broken.
who modifies class B whenever I want to check in my change? Me or the class' B owner?
With no disrespect, I think your question is so basic that it clearly suggests that you do not have even basic understanding of what being Agile means. Well, maybe that's why you asked this question.
Here are my suggestions:
In this kind of situation you really should walk up to the other developer who might be impacted by your change and have a quick face to face conversation about this, this quick conversation may lead to you guys pair programming to make sure the build does not break, and no one gets affected.
Please read all the Agile Principles again, and write down what you understand from each one of it. Implement those principles in your day to day development life. This is the only way to become Agile. There is no certification or book to refer to, to make someone Agile magically. Being Agile has to be self realized, hence practice them daily till they become a habit.
So the "Information" is conveyed using the most effective method i.e. f2f conversation. The problem is solved on the basis of the collective responsibility principle, most ideal way to fix it is pair programming.
Reference: Agile principle "The most efficient and effective method of conveying information to and within a development team is face-to-face conversation."
Also a general Agile Guideline from the manifesto: "Responding to change over following a plan"
正如@Carl Manaster所说，代码属于团队。正如 @rcravens 所说，敏捷就是沟通。与 B 的作者进行一次快速会面，让他们知道您提出的更改，以确保您了解您的影响。如果它很复杂，请与 B 的作者一起进行更改。更改完成后，如果您认为这可能会影响团队中的其他开发人员，请召开简短的团队会议并让他们知道更改。
顺便问一下，你的设计怎么样？
您的问题也可能揭示了一个设计问题 - A 和 B 可能耦合得太紧密。在测试工作并实施更改后，我建议您检查代码并查看是否需要重构。 （请记住，TDD 是 Red/Green/Refactor）特别是，如果更改类A 意味着您必须更改 B 类，那么您可能不遵循单一职责原则 (SRP)SOLID 实践的手臂。
Agile includes team code ownership, communication
As @Carl Manaster said, the code belongs to the team. And as @rcravens suggests, agile is about communication. Have a quick meeting with the author of B and let them know your proposed changed to be sure you understand your impact. If it's complex, pair with B's author on the change. When the change is complete, if you think it might affect other developers on the team, call a brief team meeting and let them know of the change.
By the way, how's your design?
Your question may aslo be revealing a design issue - A and B might be too tightly coupled. After your tests work and you've implemented the change, I suggest that you examine your code and see if something needs refactoring. (Remember, TDD is Red/Green/Refactor) In particular, if changing class A means you have to change class B, then you might not be following the Single Responsibility Principle (SRP) arm of SOLID practice.
发布评论
评论（4）
在敏捷环境中，B 类（与所有类一样）属于团队。我们称之为共享代码所有权。您应该检查工作代码；如果这意味着您需要调整 B 类以符合您对 A 类所做的更改 - 调整！更好的是，配对。
In an agile environment, class B (like all classes) belongs to the team. We call this Shared Code Ownership. You should check in working code; if that means you need to adjust class B to conform to the changes you make to class A - adjust! Better yet, pair.
“个人和交互胜过流程和工具。”预先与其他受影响的人沟通变更。除非代码很简单，否则您可能无法理解更改的全部影响。即使您这样做了，您也应该让其他队友随时了解情况。
“不要破坏构建。”检查您知道会破坏构建的代码并不是一个好主意。与受影响的其他人沟通后，与他们合作完成代码更改。尝试签入代码更改，这样至少夜间构建不会被破坏。
只是我的意见......
鲍勃
"Individuals and interactions over process and tools." Communicate the change upfront with the other people impacted. Unless the code is trivial, you may not understand the full impact of the change. Even if you do, you owe it to your other teammates to keep them informed.
"Don't break the build." Checking code in that you know will break the build is not a good idea. Once you have communicated with the others that are impacted, work with them to get the code changes completed. Attempt to get the code changes checked in so at least the nightly build is not broken.
Just my opinion....
Bob
无意冒犯，我认为你的问题是如此基本，以至于它清楚地表明你对敏捷的含义连基本的理解都没有。嗯，也许这就是你问这个问题的原因。
以下是我的建议：
在这种情况下，您确实应该走到可能受到您的更改影响的其他开发人员面前，并就此进行快速的面对面对话，这种快速的对话可能会导致你们结对编程确保构建不会中断，并且没有人受到影响。
请再次阅读所有敏捷原则，并写下您对每一项原则的理解。在您的日常开发生活中实施这些原则。这是变得敏捷的唯一途径。没有任何认证或书籍可供参考，可以让某人神奇地变得敏捷。敏捷必须是自我实现的，因此要每天练习，直到成为一种习惯。
因此，“信息”的传达采用最有效的方式，即面对面的对话。该问题是在集体责任原则的基础上解决的，最理想的解决方法是结对编程。
参考：
敏捷原则
“最有效、最有效的方法
在开发项目内传递信息
团队是面对面的对话。”
宣言中还有一条通用的敏捷指南：
“响应变化而不是遵循计划”
With no disrespect, I think your question is so basic that it clearly suggests that you do not have even basic understanding of what being Agile means. Well, maybe that's why you asked this question.
Here are my suggestions:
In this kind of situation you really should walk up to the other developer who might be impacted by your change and have a quick face to face conversation about this, this quick conversation may lead to you guys pair programming to make sure the build does not break, and no one gets affected.
Please read all the Agile Principles again, and write down what you understand from each one of it. Implement those principles in your day to day development life. This is the only way to become Agile. There is no certification or book to refer to, to make someone Agile magically. Being Agile has to be self realized, hence practice them daily till they become a habit.
So the "Information" is conveyed using the most effective method i.e. f2f conversation. The problem is solved on the basis of the collective responsibility principle, most ideal way to fix it is pair programming.
Reference:
Agile principle
"The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation."
Also a general Agile Guideline from the manifesto:
"Responding to change over following a plan"
敏捷包括团队代码所有权、沟通
正如@Carl Manaster所说，代码属于团队。正如 @rcravens 所说，敏捷就是沟通。与 B 的作者进行一次快速会面，让他们知道您提出的更改，以确保您了解您的影响。如果它很复杂，请与 B 的作者一起进行更改。更改完成后，如果您认为这可能会影响团队中的其他开发人员，请召开简短的团队会议并让他们知道更改。
顺便问一下，你的设计怎么样？
您的问题也可能揭示了一个设计问题 - A 和 B 可能耦合得太紧密。在测试工作并实施更改后，我建议您检查代码并查看是否需要重构。 （请记住，TDD 是 Red/Green/Refactor）特别是，如果更改类A 意味着您必须更改 B 类，那么您可能不遵循单一职责原则 (SRP) SOLID 实践的手臂。
Agile includes team code ownership, communication
As @Carl Manaster said, the code belongs to the team. And as @rcravens suggests, agile is about communication. Have a quick meeting with the author of B and let them know your proposed changed to be sure you understand your impact. If it's complex, pair with B's author on the change. When the change is complete, if you think it might affect other developers on the team, call a brief team meeting and let them know of the change.
By the way, how's your design?
Your question may aslo be revealing a design issue - A and B might be too tightly coupled. After your tests work and you've implemented the change, I suggest that you examine your code and see if something needs refactoring. (Remember, TDD is Red/Green/Refactor) In particular, if changing class A means you have to change class B, then you might not be following the Single Responsibility Principle (SRP) arm of SOLID practice.