如果项目的数据层结构还没有确定，如果开发人员对项目还有不解，如果界面短期内还没办法确定，该怎么开发？

我目前就遇见了这样的情况。我对我们公司的项目还有很多不了解，数据库100多张表知道意思的也没几张，界面需要更换，但是还没有做出来，而且短期内公司的美工正在做其它的事情，项目的原先开发人员也在给原先的项目加新功能，因为新功能急用。我已经大致清楚了程序运行的流程，而且已经在原先开发人员的帮助下照原先的流程设计出来了新的。变动应该不会有或者不会很大，最多也就是往外扩展。分析员发给我一份子系统的简单需求，我在开发的时候发现，开发存在很大风险。很可能我开发的东西并不是美工想要的甚至数据库结构如果稍微变动的话，我的修改量将会非常大。

该怎么办？经过几天的思考，我认为可以忽略所有细节，而只关注设计。

那哪些部分是该忽略的而哪些方面不该忽略呢？那就看程序围绕的什么做了。从软件工程上说，所有的编码都是围绕前期的需求分析做的，那么不该被忽略的是需求，美工围绕着需求做，而数据库结构是为软件流程服务的。就是说，我们只要抓住系统的需求，就可以专注于设计了。

一、怎么进行设计？
怎么进行设计那就要先看为什么要进行设计了。设计的目的是什么？OOP的目的是什么？从软件历史可以知道，软件开发方式，程序语言的进化都是围绕着需求变动在发展的。需求要变动，那就要设计出能以不变应万变的流程来。

这样又回到原来的话题，既然需求会变动，那么围绕着需求的设计是否可行?

没有银弹，如果有银弹的话现在根本没有各种各样的开发方式了 ，早就变成一种模式了。我说这句话的意思是，需求变动是可以预计的。如果不能预计需求的变动，那么你如果开放出来的程序能满足变化，那不是成银弹了么 ？所以需求的发展是可以预计的！

既然可以预计，那么我们的设计就是围绕着需求和需求如何变动来策划的。

比如，我现在开发一个留言本。那么我需要收到用户发过来的数据，然后存进数据库。如果留言本的主人来了就可以观看，并且可以删除。这么一个简单的流程很容易设计。

那么如果我现在需要留言本的主人可以回复，用户可以发公开的留言，对我们原先的设计会造成多大的影响呢?

实际上如果你原先设计得很好，预期了这个需求就很容易设计了。你可以给留言赋予权限。有什么权限的人可以看，有什么权限的人可以编辑，有什么权限的人可以回复，有什么权限的人可以删除。添加了新功能，数据库结构并不需要更改，就能直接扩展了。

二、设计的具体方法

我们不关心数据库结构，不关心类会被在哪个页面用到，那关心什么？排除法得出，我们只关心类得 名称，命名空间的名称和他们之间的相互关系，以及如何把这些与设计出来的业务核心捆绑。我们只根据需求设计类的名字，思考类改完成的功能，类和其它类之间有什么样的关系，做好注释，其它的都不用理会了。设计完了，一切就都清晰了。

我们只需要专注于抽象。

三、专注设计的好处
从第一步，我们注意到，如果要设计出可扩展程序，必须清楚业务流程。而业务流程不可能凭空被设计出来，需要开发人员和分析员一起策划。

专注设计能让开发人员尽早遇见设计上的问题与分析员沟通，尽早解决设计上可能会存在的问题。从而把风险降低到不需要对设计做大手术的水平。

四、专注设计的缺点
如果设计完了，完成细节的时候发现设计上的大问题，那么项目将会崩溃。所以，设计一定要保证不能存在大问题。不过，其它任何设计方法似乎都有这个问题。

五、细节处理
设计完成，开始处理细节，和搭积木一样垒就可以了。如果遇见效率上的问题，可以用存储过程（数据层的逻辑 ）或者缓冲等方法解决。

以上是个人观点。目前正准备实践该观点。我还没有看到介绍这样开发的文章，所以阐述得可能不够深入，并且可能存在严重错误。如果大家看到过这类开发得书籍，还请介绍介绍，好让我能更好得把握设计。

http://www.cnblogs.com/birdshover/
2007年1月27日