如果需求经常变化，并且您希望及时交付代码，那么用于克服意大利面的最佳解决方案或方法是什么？
Ahmed Said
问问题
939 次
10 回答
18
你对意大利面条代码的定义是什么？对我来说，意大利面条式代码是一种太长、非结构化和混乱的方法/功能。这不是由于需求的变化，而是由于开发人员的懒惰。如果你因为事情发生了变化而不得不重写一个方法，你也可以直接清理它而无需太多开销。
如果您的意思是设计不良的对象结构，那您可能是对的。如果需求变化太快，您将很容易得到不再执行其预期用途的类、错误的对象层次结构等。
有一些技巧可以避免这种情况：
一开始不要过度设计。尽量使您的方法、类和类层次结构尽可能简单，以降低更改难度。
在需求发生变化后，不要立即开始实施，而是退后一步，看看你的代码结构是否需要在新功能适应之前进行更改。
与您的客户沟通，更改需要一些时间。如果您知道他们知道更改需求也意味着更改代码结构，那么您将代码压缩到现有结构中的压力就会更小。
始终在编码时进行重构。以我的经验，像将冗余代码从几个地方移动到一个方法或类中这样的小重构最有效地保持你的代码干净。时刻注意代码异味并尽快消除它们，以使您的工作更轻松。这需要一些经验，但现在是开始训练的最佳时机 :-)
就像 krosenvold 所说，通过在代码中添加测试用例来消除您对重大更改的恐惧，从而确保安全。我自己曾在大型遗留系统上工作过，我知道这种恐惧以及在没有安全网的情况下工作的感觉。当您首先在安全网上工作时，进行必要的更改就不再是冒险了。
于 2009-01-27T07:10:21.127 回答
4
我认为关键点之一是编写易于更改的代码。这通常有利于具体而不是抽象。还有一些设计模式倾向于通过您的代码构建非常大的支柱。这样的支柱倾向于在错误的地方进行更改，因为您害怕更改您真正应该更改的那些重要的核心代码部分。
测试覆盖率是让您进行无畏重构的真正好帮手。降落伞使疯狂的试飞员和理智的试飞员区分开来。
于 2009-01-27T07:00:11.317 回答
2
良好的测试覆盖率是防止频繁更改的最佳方法。
于 2009-01-27T07:00:30.957 回答
2
- 预测变化，如果/当你可以，如果可能的话概括需求
- 更重要的是，预测更改之间的时间
- 将工作/功能/迭代分块，以便它们可以在更改之间的时间内完成
- 瞧！你现在正在做敏捷，不断变化似乎很正常 8-P
- 服用阿司匹林，对老板发牢骚，回到#1 ;-)
于 2009-01-27T07:22:17.967 回答
2
频繁更改项目需求，包括添加或删除功能，不一定会导致意大利面条式代码，但如果您不编写模块化软件，则可能会出现这种情况（请参阅模块化编程）。争取的事情包括以下几点：
- 每个模块（无论是函数、类、库还是完整的应用程序）都有明确定义的用途。
- 理想情况下，每个模块的大小不超过满足其定义目的所需的大小。
- 模块是松散耦合的，这意味着它们可以替换其他模块而不会导致软件中断。
- 模块可以单独进行测试，以验证它们是否可以无误地发挥作用。
- 模块的组织方式有助于使问题域对其他程序员来说是直观的。
给定组织良好的模块（同样，这些可以是函数、类、库和完整的应用程序）在松散耦合的同时协同工作，处理需求变化的方法是编写新模块、扩展现有模块并连接新方式的模块。
至于如何首先拥有这些优秀的软件模块，重构是关键。其他实践，例如单元测试和开发方法（例如Scrum）也很有帮助，但重构是你的生计——这是许多业务环境没有足够时间去做的一件事。
有关编写松散耦合代码的好建议，请对依赖注入进行一些研究。
于 2009-01-27T07:38:40.710 回答
0
满足频繁的需求变化是以下目的：
- 面向对象设计（抽象业务领域并将其拆分为可管理的面向目的的概念）
- 设计模式（重用已建立的编码解决方案）
- 基于MVC的开发（数据、业务逻辑和视图/表示分离）
- 基于架构框架的开发（在提交任何特定于项目的设计和开发之前，您首先设计一个架构框架）
因此，如果您想避免意大利面，请学习并应用上述概念。
于 2009-01-27T07:02:23.077 回答
0
对于任何要求，设计您的代码以实现最大可能的更改。这可以通过将不变部分与可变部分分开来完成。在开发之前这不会花费太多时间。意大利面条代码大部分时间是由于需求变化而出现的，您的设计和编程应该能够承受它。
http://www.dreamsongs.org/Files/DesignBeyondHumanAbilitiesSimp.pdf会有所帮助。
于 2009-01-27T07:10:36.477 回答
0
范围蔓延/不良需求分析（不断变化）：
像瘟疫一样避免它是人们可以提供的保证任何质量（代码或其他）的最佳建议，无论您尝试如何计划开发项目，它都会（在所有方面）产生负面影响。
最好的解决方案是设置里程碑并知道何时向不断更改需求的人显示此链接。
您可以在您的方法中成为超级人类，开箱即用地思考并使代码尽可能容易更改，但是如果您只是对所有功能说“是”而不了解这将如何影响项目的质量时间，您仍然会失败-范围金字塔。
于 2009-01-27T08:14:56.673 回答
0
频繁变化的需求是开发敏捷方法来处理的一个问题——它们的创建至少部分是为了认识到需求确实会改变的问题，通常是有很好的理由。
如果您尚未实施的需求更改，那么如果您不在前期设计上投入太多精力，而是通过小迭代、持续测试和重构来管理设计演变，那么影响应该是最小的。
如果已经实施的需求发生了变化，而您无法更改完成日期，那么您有三种选择：延长工作时间以弥补损失的时间、放弃需求（缩小范围）以支付额外工作的费用，或降低质量产品（可能是“意大利面条”选项）。
于 2009-01-27T08:51:43.463 回答
0
如果你带着一个建议离开：重构，重构，重构！经常！
其他一切都是关于使重构更容易的细节。
于 2009-01-27T11:25:37.007 回答