【IT168 技术文章】

    XP非常强调简单的设计原则：能够用数组实现的功能决不用链表。在其它Agile方法中，简单的原则也被反复的强调。在这一章，我们就对简单性做一个全面的了解。

    Context

    架构应该设计到什么程度？

    Problem

    软件的架构都是非常的复杂的，带有大量的文档和图表。开发人员花在理解架构本身上的时间甚至超出了实现架构的时间。在前面的文章中，我们提到了一些反对象牙塔式架构的一个原因，而其中的一个原因就是象牙塔式架构的设计者往往在设计时参杂进过多的自身经验，而不是严格的按照需求来进行设计。

    在软件开发领域，最为常见的设计就是"Code and Fix"方式的设计，设计随着软件开发过程而增长。或者，我们可以认为这种方式根本就不能算是设计，它抱着一种船到桥头自然直的态度，可是在设计不断改动之后，代码变得臃肿且难以理解，到处充满着重复的代码。这样的情形下，架构的设计也就无从谈起，软件就像是在风雨中的破屋，濒临倒塌。

    针对于这种情形，新的设计方式又出现了，Martin Fowler称这种方式为"Planned Design"。和建筑的设计类似，它强调在编码之前进行严格的设计。这也就是我们在团队设计中谈到的架构设计师的典型做法。设计师们通常不会去编程，理由是在土木工程中，你不可能看到一位设计师还要砌砖头。

    "Planned Design"较之"Code and Fix"进步了许多，但是还是会存在很多问题。除了在团队设计中我们谈的问题之外，需求变更将会导致更大的麻烦。因此，我们理所当然的想到进行"弹性设计"：弹性的设计能够满足需求的变更。而弹性的设计所付出的代价就是复杂的设计。

    题外话：

    这里我们谈论"Planned Design"引出的一些问题，并没有任何排斥这种方式的意思。"Planned Design"还是有很多可取之处的，但也有很多需要改进的地方。事实上，本文中我们讨论的架构设计方式，本质上也是属于"Planned Design"方式。和"Planned Design"相对应的方式是XP所主张的"Evolutionary Design"方式，但是这种方式还有待于实践的检验，并不能简单的说他就一定要比"Planned Design"先进或落后。但可以肯定的一点是："Evolutionary Design"方式中有很多的思想和技巧是值得"Planned Design"借鉴的。

    Solution

    XP中有两个非常响亮的口号："Do The Simplest Thing that Could Possibly Work"和"You Aren't Going to Need It"（通常称之为YAGNI）。他们的核心思想就是不要为了考虑将来，把目前并不需要的功能加到软件中来。

    粗看之下，会有很多开发人员认为这是不切实际的口号。我能理解这种想法，其实，在我热衷于模式、可重用组件技术的时候，我对XP提倡的简单的口号嗤之以鼻。但在实际中，我的一些软件因为复杂设计导致开发成本上升的时候，我重新思考这个问题，发现简单的设计是有道理的。