当前位置：编程学习 > XML/UML >>
答案： 迭代是一种软件开发的生命周期模型，在设计中应用迭代设计，我们可以得到很多的好处。
在软件生命周期中，我们如何对待架构设计的发展？
架构设计往往发生在细节需求尚未完成的时候进行的。因此，随着项目的进行，需求还可能细化，可能变更。原先的架构肯定会有不足或错误的地方。那么，我们应该如何对待原先的设计呢？
我们在简单设计模式中简单提到了"Planned Design"和"Evolutionary Design"的区别。XP社团的人们推崇使用"Evolutionary Design"的方式，在外人看来，似乎拥护者们从来不需要架构的设计，他们采用的方式是一开始就进入代码的编写，然后用Refactoring来改进代码的质量，解决未经设计导致的代码质量低下的功能。
从一定程度上来说，这个观点并没有错，它强调了代码对软件的重要性，并通过一些技巧（如Refactoring）来解决缺乏设计的问题。但我并不认同"Evolutionary Design"的方式，在我看来，一定程度上的"Planned Design"是必须的，至少在中国的软件行业中，"Planned Design"还没有成为主要的设计方向。借用一句明言，"凡事预则立，不预则废"，在软件设计初期，投入精力进行架构的设计是很有必要的，这个架构是你在后续的设计、编码过程中依赖的基础。但是，一开始我们提到的设计改进的问题依然存在，我们如何解决它呢？
在简单设计模式中，我们提到了设计改进的必要性，但是，如果没有一种方法去控制设计的改进的话，那么设计改进本身就是一场噩梦。因此，何时改进，怎么改进， 如何控制，这都是我们需要面对的问题。
解决方法
为了实现不断的改进，我们将在开发流程中引入迭代的概念。迭代的概念在《需求的实践》中已经提到，这里我们假设读者已经有了基本的迭代的概念。
软件编码之前的工作大致可以分为这样一个工作流程：
上图中的流程隐含着一个信息的损失的过程。来自于用户的需求经过整理之后，开发人员就会从中去掉一些信息，同样的事情发生在后面的过程中，信息丢失或变形的情况不断的发生。这里发生了什么问题？应该说，需求信息的失真是非常普遍的，我们缺少的是一种有效的办法来抑止失真，换句话说，就是缺少反馈。
如果把眼睛蒙上，那我们肯定没有办法走出一条很长的直线。我们走路的时候都是针对目标不断的调整自己的方向的。同样的，漫长的软件开发过程如果没有一种反馈机制来调整方向，那最后的软件真是难以想象。
所以我们引入了迭代周期。
初始设计和迭代设计
在团队设计中，我们一直在强调，设计组最开始得到的设计一定只是一个原始架构，然后把这个原始架构传播到每一位开发者的手中，从而在开发团队中形成共同的愿景。（愿景（Vision）：源自于管理学，表示未来的愿望和景象。这里借用来表示软件在开发人员心中的样子。在后面的文章中我们会有一个章节专门的讨论架构愿景。）
迭代（Iterate）设计，或者我们称之为增量（Incremental）设计的思想和XP提倡的Evolutionary Design有异曲同工之妙。我们可以从XP、Crystal、RUP、ClearRoom等方法学中对比、体会迭代设计的精妙之处：每一次的迭代都是在上一次迭代的基础上进行的，迭代将致力于重用、修改、增强目前的架构，以使架构越来越强壮。在软件生命周期的最后，我们除了得到软件，还得到了一个非常稳定的架构。对于一个软件组织来说，这个架构很有可能就是下一个软件的投入或参考。
我们可以把早期的原始架构当作第一次迭代前的早期投入，也可以把它做为第一次迭代的重点，这些都是无所谓的。关键在于，原始架构对于后续的架构设计而言是非常重要的，我们讨论过架构是来源于需求的，但是原始架构应该来源于那些比较稳定的需求。
TIP：现实中迭代设计退化为"Code and Fix"的设计的情况屡见不鲜（"Code and Fix"参见简单设计）。从表面上看，两者的做法并没有太大的差别，都是针对原有的设计进行改进。但是，二者效果的差别是明显的："Code and Fix"是混沌的，毫无方向感可言，每一次的改进只是给原先就已摇摇欲坠的积木上再加一块积木而已。而迭代设计的每一次改进都朝着一个稳定的目标在前进，他给开发人员带来信心，而不是打击。在过程上，我们说迭代设计是在控制之下的。从实践的经验中，我们发现，把原该在目前就该解决的问题退后是造成这一问题的主要原因之一。因此，请严格的对待每一次的迭代，确保计划已经完成、确保软件的质量、确保用户的需求得到满足，这样才是正统的迭代之路。
单次的迭代
我们说，每一次的迭代其实是一个完整的小过程。也就是说，它同样要经历文章中讨论的这些过程模式。只不过，这些模式的工作量都不大，你甚至可以在很短的时间内做完所有的事情。因此，我们好像又回到了文章的开头，重新讨论架构设计的过程。
单次迭代最令我们兴奋的就是我们总是可以得到一个在当前迭代中相当稳定的结果，而不像普通的架构设计那样，我们深怕架构会出现问题，但又不得不依赖这个架构。从心理上来分析，我们是在持续的建设架构中，不需要回避需求的变更，因为我们相信，在需求相对应的迭代中，会继续对架构进行改进。大家不要认为这种心理的改变是无关紧要的，我起初并没有意识到这个问题，但是我很快发现新的架构设计过程仍然笼罩在原先的惧怕改变的阴影之下的时候，迭代设计很容易就退化为"Code and Fix"的情形。开发人员难以接受新方法的主要原因还是在心理上。因此，我不得不花了很多的时间来和开发人员进行沟通，这就是我现实的经验。
上一个：“简”话设计模式(3)
下一个：Flywheel：前进的马达在轰鸣
