认识达内从这里开始

当软件开发需求发生大量变化的时候，重构是解决问题的一个非常有效的方法，而今天我们就通过案例分析来了解一下，需求变化避免发生软件改变的方法都有哪些。

在任何时候，需求的变更总是对架构及软件有着大的伤害。而需求变更中大问题是需求蔓延。很多人都有这样的感觉，项目完成之后，发现初期的计划显得那么陌生。在项目早期对需求进行控制是重要的，但并不是该模式谈论的重点。我们更关注在项目中期的需求蔓延问题和晚期的需求控制问题。关于这方面的详细讨论，请参见稳定化模式。在项目中期，尤其是编码工作已经开始之后，要尽可能避免出现需求蔓延的情况。需求蔓延是经常发生的，可能是因为用户希望加入额外的功能，或是随着用户对软件了解的加深，发现原有的需求存在一定的不足。完全防止需求蔓延是无法做到的，但是需要对其进行必要的控制。例如，有效的估计变更对开发、测试、文档、管理、组织等各个方面带来的影响。

避免发生改变的另一个有效的办法是从软件过程着手。迭代法或渐进交付法都是可用的方法。一个软件的架构设计往往是相对复杂的，其中涉及到整体结构、具体技术等问题。一次性考虑全部的要素，就很容易发生考虑不周详的情况。人的脑容量并没有我们想象的那么大。将架构设计分为多个迭代周期来进展，可以减少单次迭代周期中需要建模的架构数量，因此可以减少错误的发生。另一方面，迭代次数的增多的直接结果是时间的延长，此外还有一个潜在的问题，如果由于设计师的失误，在后期的迭代中出现问题，必然会导致大量的返工。因为之前的模型已经实现了。在得与失之间，我们如何找到适当的平衡点呢?

迭代次数应该根据不同软件组织的特点来制定，对于初期的迭代周期而言，它的主要任务应该是制定总原则(使用架构愿景模式)、定义层结构和各层的职责(使用分层模式)、解决主要的技术问题上。在这个过程中，可以列出设计中可能会遇到的风险，并根据风险发生的可能性和危害性来排定优先级，指定专人按次序解决这些问题。除此之外，在初期参考前一个项目的经验，让团队进行设计，这些组织保证也是很重要。初期的迭代过程是防止改变的重要的活动。

请注意需求中的非功能需求。如果说功能需求定义了架构设计的目标的话，非功能需求就对如何到达这个目标做出了限制。例如，对于实现一个报表有着多种的操作方法，但是如果用户希望新系统和旧系统进行有效的融合，那么实现的方式就需要好好的规划了。请从初期的迭代过程就开始注意非功能需求，因为如果忽略它们，在后期需要花费很大的精力来调整架构模型。试想一下，如果在项目晚期的压力测试中，发现现有的数据库访问方法无法满足用户基本的速度要求，那对项目进行将会造成多么大的影响。

注意架构的稳定性。在精化和合并模式中，我们提到了一些模式，能够降低不同组件之间的耦合度。并向调用者隐藏具体的实现。接口和实现分离是设计模式大的特点，请善用这一点。

尽可能的推延正式文档的编写。在设计的初期，修饰模型和编写文档通常都没有太大的意义。因为此时的模型还不稳定，需要不断的修改。如果这时候开始投入精力开发文档，这就意味着后续的迭代周期中将会增加一项维护文档一致性的工作了。而这时候的文档却无法发挥出它真正的作用。但是，延迟文档的编写并不等于什么都不做，无论什么时候进行设计，都需要随手记录设计的思路。这样在需要的时候，我们就能够有充分的资料对设计进行文档化的工作。

【免责声明】本文系本网编辑部分转载，转载目的在于传递更多信息，并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题，请在30日内与管理员联系，我们会予以更改或删除相关文章，以保证您的权益!更多内容请在707945861群中学习了解。