需求的频繁变化是否导致意大利面代码？

Question

如果需求经常变化，并且您希望及时交付代码，那么用于克服意大利面的最佳解决方案或方法是什么？

Answer 1

你对意大利面代码的定义是什么？对我来说，意大利面代码是一个太长，非结构化和混乱的方法/功能。这并不是由于需求的变化而发生的，而是由于开发者的懒惰。如果你必须重写一个方法，因为事情已经改变了，你也可以直接清理它，而不需要太多的开销。

如果您的意思是设计不好的对象结构，那么您可以对。如果需求变化太快，那么您将很容易就会遇到不再按照他们的意图实现的类，不良对象层次结构等等。

有一些的窍门，以避免这种情况：

• 在开始的时候，不要过度设计。尽量保持您的方法，类和类层次结构尽可能简单，以减少更改难度。

• 的要求改变后，不要开始实施它的权利的话，但后退一步，看看是否需要改变你的代码结构中的新功能可以适应了。

• 沟通，你的客户端，这种改变需要一些时间。如果您知道他们知道更改需求也意味着您的代码结构发生了变化，那么将代码压入现有结构的压力会更小。

• 编码时总是重构。根据我的经验，将冗余代码从多个地方移动到单个方法或类中的小重构对于保持代码清洁最有效。始终注意代码气味，并尽可能快地移除它们，以使您的工作更轻松。这需要一些经验，但现在是开始训练的合适时间:-)

• 就像krosenvold说的那样，通过在代码中添加测试用例来安全地发挥它的作用，以消除对重大变化的恐惧。我自己在一个大型遗留系统上工作，我知道这种恐惧感和没有安全网的感觉。当你首先在你的安全网上工作时，变得不那么冒险去做必要的改变。

Answer 2

我认为其中一个关键点是编写易于改变的代码。这通常有利于具体而不是摘要。还有一些设计模式倾向于通过代码构建非常大的支柱。这些支柱倾向于在错误的地方发生变化，因为您害怕改变代码中那些重要的核心部分，您应该改变。

测试覆盖率是一个真正的好帮手，可以让你做无畏的重构。这是降低疯狂和理智的测试飞行员之间的差异的降落伞。

Answer 3

良好的测试覆盖率是防止频繁更改的最佳防御措施。

Answer 4

餐饮频繁的需求变更是以下的目的：

• 面向对象的设计（抽象业务领域，并拆分为可管理的宗旨面向概念）
• 设计模式（再利用建立的编码方案）基于MVC的开发（数据分离，业务逻辑和视图/演示）
• 基于体系结构的开发（在提交任何特定项目之前先设计一个体系结构框架设计和开发）

所以，如果你想避免意大利面，学习和应用上述概念。

Answer 5

对于任何需求，请设计您的代码以获得最大可能的更改。这可以通过将可变部分与可变部分分开来完成。这在开发之前不会花费太多时间。意大利面代码大多数时间出现，因为需求发生变化，您的设计和编程应该能够承受。

http://www.dreamsongs.org/Files/DesignBeyondHumanAbilitiesSimp.pdf将是有帮助的。

Answer 6

1. 预期的变化，如果/当你可以了，更重要的是推广，如果可能的
2. 的要求，预期变化的工作/功能/迭代之间
3. 大块的时间，使他们能够在完成更改时间
4. 瞧！你现在正在做敏捷的飞行和不断变化似乎正常8-P
5. 服用阿司匹林，在哀鸣老板，循环回＃1 ;-)

Answer 7

频繁更改项目的要求，包括增加或删除功能，不必必然导致意大利面代码，但它可能会，如果你不写模块化软件（见Modular Programming）。争取的东西包括以下内容：

• 每个模块（无论它是一个函数，类，库或完整的应用程序）具有良好限定的目的。
• 理想情况下，每个模块不大于它需要为以服务其定义的目的。
• 模块是松散耦合，这意味着它们可以替代其他模块而不会导致软件中断。
• 模块可以是单独测试验证他们为他们的目的没有错误。
• 模块是有组织的方式，有助于使问题域直观的其他程序员。

给定组织良好的模块（同样，这些模块可以是函数，类，库和完整应用程序），它们在松散耦合的情况下一起工作，处理需求变化的方法是编写新模块，展开在现有的模块上，并以新的方式连接模块。

至于你如何到达首先有这些好软件模块的情况，refactoring是关键。其他做法如unit testing和开发方法（如Scrum）也很有帮助，但重构是您的面包和黄油 - 而许多商业环境都没有足够的时间来完成重构。

对于编写松散耦合代码的好建议，请在dependency injection上进行一些研究。

Answer 8

范围蔓延/坏的需求分析（千变万化）：

避免像瘟疫是一个可以给你保证任何质量（代码或其他方式）的最好的建议，它总是会产生负面影响（在所有无论您尝试计划您的开发项目的程度如何。

最好的解决方案是设置里程碑并知道何时向谁显示this link谁不断变化的要求。

你可以在你的方法中超人类思维，尽可能容易地改变代码，但是如果你只是对所有的功能说yes而不理解应该如何影响项目的质量 - 时间范围金字塔。

Answer 9

经常变化的需求是一个敏捷方法需要处理的问题 - 它们的创建至少部分是因为需要更改的需求，通常是因为很好的原因。

如果需求发生变化，但尚未实现，那么如果不在前期设计中投入太多精力，而是通过小型迭代，持续测试和重构来管理设计演变，则影响应该很小。

如果已经实施的要求发生变化，并且无法移动完成日期，那么您有三种选择：工作时间更长以恢复丢失的时间，降低要求（缩小范围）以支付额外的工作，或降低产品的质量（这可能是“意大利面条”选项“）

Answer 10

如果您正在使用一个忠告离开。！重构，重构，重构通常

其他的都是关于细节使重构更容易