"It depends." How you answer depends largely on how disciplined your team is.
The situation you describe invites a very small step across the line toward a slippery slope that leads to code bloat. The step is so small that you don't notice the slope. Is it safe? Probably, because it's a trivial example. Many "doesn't it make sense to go ahead and..." cases are larger. And the larger the step, particularly if it crosses a sprint boundary, the greater the chance that you'll guess wrong, and end up with wasted work and extra, unused code. Working in a system with a lot of dead or unused code sucks.
If your team that has a problem with code bloat, I'd "set the anticipation knob at zero" for a while, until people have a feeling for what it's like to build a system in small pieces with no anticipatory design. Seeing a system evolve cleanly is something many developers have never seen. Then revisit the decision. The most productive team I worked with left the knob set to zero and kept it that way for years.
然而......像所有好问题一样，答案实际上是“这取决于”。 在某些方面，你的例子太微不足道，无法公正地进行讨论。 如果故事 A 是“更新客户名称”并且故事 B 添加了某种事务功能（也许 paramB 是 TX 上下文）会怎样？ 在这种情况下，你的故事可能需要一些改进。 没有B，A还有实际意义吗？ A是今天上午实施，B是今天下午实施，还是B下个月实施？
With a modern development tool, refactoring the method to have a second parameter is very low cost. So implementing the first story seems to make the most sense and then revisiting the method when it comes to the later story.
However... Like all good questions the answer is really "it depends". In some respects your example is too trivial to do justice to the discussion. What if story A was "update customer name" and story B added some sort of transactional feature (maybe paramB is the TX context). In which case maybe your stories need some work. Does A make any real sense without B? Is A implemented this morning and B this afternoon, or is B work for next month?
The project may be canned, new more important stories may appear that means story 2 is never needed, by the time you get to story 2 you may understand the problem better and need to refactor everything. There are endless reasons you mightn't need it.
On one end of the spectrum are the Agile purists that insist that everything can be accomplished by refactoring later. On the other end are the old-school Big-Design-Up-Front crowd that think you should build a complete architecture first and then snap features onto it. Your question is perfect because it exposes the failings of both philosophies if you mindlessly follow their processes. What you want is maximum efficiency. So you need to analyze what Story 1 and Story 2 are in your situation. Is your software shippable without S2 or did you just split up the stories to help with estimating and planning? If S1 is "Add to shopping cart" and S2 is "Check-out" it is silly to not build the interface to support S2 because your software is worthless without it. In every project there is a certain set of known "Have-to-have" features that make your software even worth shipping. If Both of your stories are from that set then I would say build the interface to support both now and don't waste time refactoring later (#3).
Usually if S1 and S2 are both in the must-have set they will be close together on the Backlog. If this is not the case then you either have a huge amount of must-haves and your project isn't going to gain that much advantage using Agile techniques or S2 really isn't a must have. So if you are expecting a large chuck of time (months?) to pass between the commitment to S1 and S2, then I would go with the 1 parameter interface. Time is always a huge contributer to uncertainty.
The purists will say option 1, but I'd listen to common sense and if you're absolutely 100% convinced that this is a requirement then I'd factor this in to your design.
HOWEVER Agile is also heavily based around refactoring, so as long as you aren't publicly releasing this interface then I would actually go with option 1 if changing this won't impact my design.
发布评论
评论（5）
“这取决于。” 你如何回答很大程度上取决于你的团队的纪律程度。
您所描述的情况会导致您向滑坡迈出一小步，从而导致代码膨胀。 台阶太小了，你不会注意到坡度。 安全吗？ 可能是，因为这是一个微不足道的例子。 许多“继续下去难道没有意义吗……”的案例规模更大。 步幅越大，特别是当它跨越冲刺边界时，您猜错的可能性就越大，最终导致浪费工作和额外的、未使用的代码。 在一个有大量死代码或未使用代码的系统中工作很糟糕。
如果你的团队有代码膨胀的问题，我会“将预期旋钮设置为零”一段时间，直到人们感受到以没有预期设计的小块构建系统的感觉。 看到一个系统干净利落地发展是许多开发人员从未见过的。 然后重新考虑这个决定。 与我合作的效率最高的团队将旋钮设置为零，并保持这种状态多年。
"It depends." How you answer depends largely on how disciplined your team is.
The situation you describe invites a very small step across the line toward a slippery slope that leads to code bloat. The step is so small that you don't notice the slope. Is it safe? Probably, because it's a trivial example. Many "doesn't it make sense to go ahead and..." cases are larger. And the larger the step, particularly if it crosses a sprint boundary, the greater the chance that you'll guess wrong, and end up with wasted work and extra, unused code. Working in a system with a lot of dead or unused code sucks.
If your team that has a problem with code bloat, I'd "set the anticipation knob at zero" for a while, until people have a feeling for what it's like to build a system in small pieces with no anticipatory design. Seeing a system evolve cleanly is something many developers have never seen. Then revisit the decision. The most productive team I worked with left the knob set to zero and kept it that way for years.
使用现代开发工具，重构方法以具有第二个参数的成本非常低。 因此，实现第一个故事似乎最有意义，然后在涉及后面的故事时重新审视该方法。
然而......像所有好问题一样，答案实际上是“这取决于”。 在某些方面，你的例子太微不足道，无法公正地进行讨论。 如果故事 A 是“更新客户名称”并且故事 B 添加了某种事务功能（也许 paramB 是 TX 上下文）会怎样？ 在这种情况下，你的故事可能需要一些改进。 没有B，A还有实际意义吗？ A是今天上午实施，B是今天下午实施，还是B下个月实施？
With a modern development tool, refactoring the method to have a second parameter is very low cost. So implementing the first story seems to make the most sense and then revisiting the method when it comes to the later story.
However... Like all good questions the answer is really "it depends". In some respects your example is too trivial to do justice to the discussion. What if story A was "update customer name" and story B added some sort of transactional feature (maybe paramB is the TX context). In which case maybe your stories need some work. Does A make any real sense without B? Is A implemented this morning and B this afternoon, or is B work for next month?
只需执行 1。
重构很容易，但预测未来却不容易。
该项目可能会被取消，可能会出现新的更重要的故事，这意味着永远不需要故事 2，当您到达故事 2 时，您可能会更好地理解问题并需要重构所有内容。 您可能不需要它的原因有无数。
Just do 1.
Refactoring is easy, predicting the future isn't.
The project may be canned, new more important stories may appear that means story 2 is never needed, by the time you get to story 2 you may understand the problem better and need to refactor everything. There are endless reasons you mightn't need it.
一方面是敏捷纯粹主义者，他们坚持认为一切都可以通过稍后的重构来完成。 另一端是老派的大前端设计人群，他们认为应该首先构建一个完整的架构，然后将功能添加到它上面。 你的问题是完美的，因为如果你盲目地遵循这两种哲学的过程，它就会暴露出这两种哲学的失败。 您想要的是最大效率。 因此，您需要分析您的情况中的故事 1 和故事 2。 您的软件是否可以在没有 S2 的情况下交付，或者您只是将故事分开以帮助估算和规划？ 如果 S1 是“添加到购物车”而 S2 是“结帐”，那么不构建支持 S2 的接口是愚蠢的，因为如果没有它，您的软件就毫无价值。 在每个项目中，都有一组已知的“必备”功能，使您的软件值得交付。 如果您的两个故事都来自该集合，那么我会说立即构建支持这两个故事的界面，并且稍后不要浪费时间重构（#3）。
通常，如果 S1 和 S2 都在必备集合中，那么它们在 Backlog 上的位置就会很接近。 如果情况并非如此，那么您要么有大量必须具备的东西，而您的项目将不会使用敏捷技术获得那么大的优势，要么 S2 确实不是必须具备的。 因此，如果您预计 S1 和 S2 的承诺之间需要花费大量时间（几个月？），那么我会使用 1 参数接口。 时间总是造成不确定性的一个巨大因素。
On one end of the spectrum are the Agile purists that insist that everything can be accomplished by refactoring later. On the other end are the old-school Big-Design-Up-Front crowd that think you should build a complete architecture first and then snap features onto it. Your question is perfect because it exposes the failings of both philosophies if you mindlessly follow their processes. What you want is maximum efficiency. So you need to analyze what Story 1 and Story 2 are in your situation. Is your software shippable without S2 or did you just split up the stories to help with estimating and planning? If S1 is "Add to shopping cart" and S2 is "Check-out" it is silly to not build the interface to support S2 because your software is worthless without it. In every project there is a certain set of known "Have-to-have" features that make your software even worth shipping. If Both of your stories are from that set then I would say build the interface to support both now and don't waste time refactoring later (#3).
Usually if S1 and S2 are both in the must-have set they will be close together on the Backlog. If this is not the case then you either have a huge amount of must-haves and your project isn't going to gain that much advantage using Agile techniques or S2 really isn't a must have. So if you are expecting a large chuck of time (months?) to pass between the commitment to S1 and S2, then I would go with the 1 parameter interface. Time is always a huge contributer to uncertainty.
纯粹主义者会说选项 1，但我会听取常识，如果您绝对 100% 确信这是一个要求，那么我会将其纳入您的设计中。
然而，敏捷也很大程度上基于重构，因此只要您不公开发布此接口，那么如果更改此接口不会影响我的设计，我实际上会选择选项 1。
The purists will say option 1, but I'd listen to common sense and if you're absolutely 100% convinced that this is a requirement then I'd factor this in to your design.
HOWEVER Agile is also heavily based around refactoring, so as long as you aren't publicly releasing this interface then I would actually go with option 1 if changing this won't impact my design.