读 Martin Fowler设计已死？总结

 1 Planned and Evolutionary Design

 Evolutionary :code and fix bug ,会陷入越修改bug越多的情况

 Planned:按照需求分析，概要设计，详细设计，编码，单元测试，集成测试，版本测试，版本发布的步骤进行开发软件 

 结论：喜欢 planned design。因为我了解 planned design 的缺点，而且正在寻找更好的方法。

2 The Enabling Practices of XP

XP是改进的演进式设计 (evolutionary design) 而不是 planned design。

改进之处是加入一些有效的实作技巧：Testing ， Continuous Integration，Refactoring 。

3 The Value of Simplicity

XP 大声疾呼的两个口号是 "Do The Simplest Thing that Could Possibly Work"(只做最简单可以正常运作的设计) 和 "You Aren't Going to Need It"(就是 YAGNI - 你将不会需要它)。两项都是XP实务中简单设计的表现形式。

结论：除非到了往后的阶段有所需要，否则你不会浪费精神去增加新的功能。即使不会多花成本，你也不会这样做，因为就算现在加入这些功能并不增加成本，但是却会增加将来做修改时的成本。总之，你可以在套用 XP 时明智的遵守这样的方法，或是采取一种能降低成本的类似的方法

4 What on Earth is Simplicity Anyway

Kent 对简单系统订了四个评量标准，依序是 (最重要排最前面)：

通过所有测试。

呈现所有的意图。－－－简单明了的程序代码

避免重复。

最少数量的类别或方法。

结论：Bob 大叔 (Robert Martin)的建议是不要太在意什么是最简单的设计。毕竟后来你可以，应该，也会再重构。愿意在最后重构，比知道如何做简单的设计重要得多。

5 Does Refactoring Violate YAGNI?

结论：YAGNI 的观点是不要增加一些现阶段不需要的复杂功能，这也是简单设计这项技巧的部份精神。重构也是为了满足尽可能保持系统的简单性这个需要，所以当你觉得可以让系统变得更简单的时候，就进行重构

6 Patterns and XP

我对于采用 XP 的人使用 patterns 的建议：

花点时间学习 patterns。

留意使用 patterns 的时机 (但是别太早)。

留意如何先以最简单的方式使用 patterns，然后再慢慢增加复杂度。

如果用了一种 pattern 却觉得没有多大帮助－不用怕，再次把它去掉。

我认为XP应该要更加强调学习 patterns。我不确定它要怎么和 XP 的实务技巧搭配，不过相信 Kent 会想出办法来的。

7 Growing an Architecture

结论：建议从评估架构可能的样子开始。假如你看到将会有多个使用者使用到大量的资料，一开始就直接使用数据库。若你看到很复杂的商业逻辑，就套用 domain model。你会怀疑是否偏离简单的特性，这当然不是 YAGNI 的精神。所以你要有所准备，在发现所使用的结构没有帮助时尽快简化你的结构。

8 UML and XP

结论：

蓝图的用途是在开始撰写程序代码之前探讨设计内容。印象中总是觉得这样的动作在 XP 是不合法的，但并不是这样。很多人都说如果你遇到棘手的问题，就值得先做些设计。但是当你进行设计时：

保持简短。

不要做得太详细(只挑重要的做)。

把结果当作是草图，而不是定案。

变更设计不代表一定要更改蓝图。画这些蓝图来帮助你了解设计，然后就把图扔开，这么做是非常合理的。这些图能够帮上忙就有它的价值了。它们不必永远存在，最有用的 UML 图形也不会是收藏品

9 On Metaphor (關於隱喻)

结论：人们常批评 XP 乃是基于觉得一个系统实在是至少需要一个大概的设计。XP 专家则以 "就是 metaphor 啊！" 来响应。但是我还是没有看到一个对于 metaphor 令人信服的解释。这是 XP 的缺憾，必须由 XP 专家来理出头绪。

10 Do you wanna be an Architect when you grow up?

设计本身的角色来说，我不觉得 XP 不重视经验或好的设计。事实上多位 XP 的提倡者 - Kent Back、Bob Martin、当然还有 Ward Cunningham - 都是我从而学习设计的对象。然而这也代表着他们的角色从大家既有的印象中开始转变成为技术领导者

知道 XP 的人就能够了解我描述的是 XP "教练" 的清楚角色。的确，在 XP 玩的文字游戏中提到领导技术就是在描绘 "教练" 这个角色。其意义是很清楚的：在 XP 技术的领导特质是透过教导程序员和帮助他们做决定而呈现。这是一种需要良好人际管理和技术并重的技巧。Jack Bolles 在 XP2000 说：孤单的大师有点机会了，合作和教导是成功的关键。

在XP的Architect 扮演者教练的角色。而不是纯粹的软件的设计。他指导team中的其他人，解决他人遇到的问题

11 Things that are difficult to refactor in

我们能用 refactoring 来处理所有设计方面的决定吗？或者，有些问题太普遍而且难以在将来加入设计中？此时，XP 的正统做法是所有需求都可以轻易的在需要的时候增加，所以 YAGNI 总是能够适用。我猜是不是有例外？有一个不错的，被讨论到的例子是软件的国际化。这是不是一种现在应该立即进行，否则以后再加入时会觉得痛苦的事情

结论作者与Kent有分歧

So is Design Dead?

当然不是了，没什么原因，只是设计的本质已经改变。XP 的设计追求以下的技巧：

持续保持清爽的程序代码，越简单越好。

重构的技巧，所以当你觉得必要的时候都可以有信心的动手。

具有 patterns 的知识：不只是照它的解法，更要感觉何时可以应用，或是如何导入 patterns。

知道如何将设计说给必要的人了解[译注8]，用程序代码、或是图形、或上述所有的工具：交谈。