本篇写于读<Code Complete>之后，面对实际设计中的问题时产生的一些感悟，在这里和大家一起分享。。

第一页

设计是个“鬼”命题。为什么呢？它又鬼在哪呢？

A wicked problem as one that could be clearly defined only by solving it or by solving part of it.

---Horst Rittel and Melvin Webber

这里是大师的定义。只有你解决了或者部分解决这个问题的时候，你才能清楚的定义它。

用白话讲，只有你做了，你才知道它是怎么回事，怎么才能做好这件事。

所以，我常常拿到一个开发功能而又无从下手时，除了寻找支援，询问别人，唯一剩下的路就是尝试着去做。虽然是胆颤心惊、如履薄冰，但是做着做着就明白了。

我想，大师告诉我们这是一个鬼命题，第一,是告诉我们第一次摸着石头过河是人类的认知规律,开始时做错了是正常的;第二,就是让我们勇敢的去尝试。

第二页

设计是一个迭代的过程。

大家先看这幅图。

这里典型的瀑布式设计“分析==>设计==>编码==>测试”。这个过程每一个阶段都有明确的输入/输出，每个阶段都有一个交付件。这对我们的管理者是个福音，因为这样子，项目的进展一目了然，项目就可控了。所以说，这个过程是为Mananger写的。所以，有了这句话“Oh, I write specs to keep managers happy and then code the thing the way I want “

因为，事实上，我们程序员感觉到的设计过程不是这样的。而是这样的：

同样，它也是基于瀑布模型的。只是增加了一个逆向过程，使得我们在下一阶段发现问题时，可以回过头来修正。

我们现在来想想这个问题，为什么大家会说 “设计文档没有用”？因为作为一个过程的输出结果，设计文档有个致命的问题：无法保证文档与代码同步。表现在两个方法：

1．无法保证设计文档的结果一定会反映在代码中（除了人去看，无法证实）。

2.设计的成果，要通过重复劳动在代码中来表现。

3．后期代码结构的变化，很难表现在设计文档中。

所以我说，设计阶段的输出应该是一份Rose文档和一份简要的设计补充说明。这样，我们用Rose的逆向工程能力来表现现有代码的实际结构/接口；用Rose的代码生成能力来表现接口的修改。我们现在来试一下。

(Rose使用展示)

这样，我们将模块、类、类接口等都表现在Rose中，而将伪码以注释方式写在代码中。

我们少了多少事啊~~

这里附带着强调一点，里程碑很重要。没有了里程碑,迭代的设计很就成了死循环。不可控的项目也不会是好项目。

第三页

分而治之

这是人类解决复杂问题的通用解决方法。

对应于我们软件设计过程，就是“产品模块类方法”的逐层分解过程。

其中，模块确定了与其它模块之间、与用户之间的契约（模块间公共接口）；类确定了类之间的契约(包内公共接口)；方法确定了私有方法。下一层总是服务于上一次。

这个过程通过Rose完全能够完成。所以，设计阶段不等于写设计文档。设计文档仅仅是输出结果。

第四页

自上而下和自下而上

这是两种不同的思考过程。自上而上是由抽象到具体，自下而上则相反，由具体到抽象。上面提到的，分而治之，逐层分解就是一种自上而下的过程。

一般来讲，自上而下比较容易点，也是软件设计中比较提畅的一点。我们经常强调的“依赖反转”，依赖于抽象，而不是依赖于具体。都是自上而下的抽象分解过程。

那么， 在设计中还有一个关注点“分离变化点”。是我们隔离变化，将变更的影响降低的一种方法。这里就有个问题，如果你不再往下看，找出具体是什么会变化，你怎么将变化隔离封装？这个时候，要的就是“自下而上”的分析。

佛教有一句“法无定法”，意思是说做好一件事，不一定有一个固定的法则。当你用一种方法直不下去时，不妨试试其它方法。所以，自上而下与自下而上并不矛盾。

第五页

原型。

设计的时候，经常有这样一个问题。以前没搞过，现在这么做行不行呢？心里没底。那怎么办？写个原型。

就在代码中写。需要的时候，在进入编码阶段时，重复利用。

(比如这次我要开发个向导，我发现有个现成的框架。但是不知道该怎么用，不知道能不能满足需要。所以，我按照现在规格，写了一点原型代码。发现可以用。)

但是这里有个分寸的问题，就是不要写的太多。能够证实你的想法就可以了。一是因为咱们还有里程碑计划，有时间点的压力。二是因为，这部分代码只是试验，并不可靠，写的越多，隐藏的问题就会越多。

第六页

设计到什么时候结束？

下列两个条件中满足任意一个结束：

1. 你觉的再设计就成了写代码了；

2. 你没有时间了；

第一个结束点，对各个人不一样，只要你感觉你能写出代码了就行。所以，对于经过多个版本的人可能会结束的早一些。

第二个结束点，没有办法的事,无论好坏，认命，赶快把文档搞的貌似结束，在编码阶段再尝试补救。

结束