面向界面编程模式

首先我申明这个词没有官方论证，只是我个人的一个命名。到现在是不是有点纳闷，有面向对象编程，面向接口编程，面向方面编程，怎么又忽然多了一个面向界面编程，不用着急听我慢慢道来。

叫 做开发模式好像不确定，实际上主要的目的就是更快更准的了解用户需求，让需求更改几率尽量降低，提高开发效率。我一直在思索这个问题，到底叫做方法论还是 模式，但是我又想如果这个叫做模式的话，就应该有一套辅助的设计框架，因为这个也是一个尝试，还需要进一步的论证和完善，这本书中我主要就是以PHP开发 SaaS应用为例，演练一下这个模式，顺便会提供一个简单辅助开发框架，方便界面设计，就先叫做模式吧！

下边是我个人认为值得一起的口号（原则）：

1、 精确界面描述，胜过大量用户看不懂的需求规格说明书；

当 我们做一个系统的时候，做用户的需求是最难的事情，这个就不用说明理由，尤其在中国这个问题让人头疼，没有行业的标准，老板的喜爱很重要，在国外有专业的 咨询公司，能写出一份详细完善的需求说明书，但是在中国可以说是天方夜谭，因为用户本身就不知道他自己需求是什么样子的？我们做系统的设计的人，想真正了 解用户的需求那是难上加难。

我在研究模式设计的时候，也发现很多系统架构师在做“符合中国的开发模式”的命题研究，但是这个宏伟的目标什么时候才能实现，我希望他能早点把理论建立起来，我们再想办法实现。

以 前做项目的时候，用户总会告诉我，你们先设计一个大概能操作的东西，我再看看需要什么，那里不对，这样会让很多设计人员哭笑不得，还没有理清需求，也就是 说还没有评估项目的风险就要开动工，这样对软件企业的风险很大。最近在为一个软件公司做IT咨询的时候，发现该公司遇见的这样的问题更是恼火，用户更本就 不考虑系统的安全性和程序的健壮性，做验收的时候只看界面的操作流程，是不是符合自己的流程和习惯？

于是我就再想，如果我们工程师在做需求的时候，放弃过去报表，文档的整理，而让我们的UI工程师和界面编程人员在了解大概的需求之上做出可操作的界面，让用户在可见的界面上提出需求，我们不断的修改界面，以达到用户的需求，这样就可以避免用户需求不明的问题。

2、 详细界面输入设计，胜过要求用户提供数据字典；

以 前我们在做需求的时候，就要整理用户的各种单据，但是往往单据上表现的数据并不能完全呈现完输入的数据，比如一个产品订单的时候，他不会呈现出这个订单相 关的合同信息，但是在输入订单的时候就会有相关的合同编号，甚至还会录入一些合同的必要信息，比如金额。这样我们再整理数据字典的时候就会出现麻烦，我们 要把能收集的单据全部整理再一起，再进行数据分析，整理数据字典，就在用户完全紧密配合的情况下我们做到100%的正确也是相当有难度的。

如 果我们把这些都做在界面上，让用户在界面上实现自己的工作流程，他就会很清楚的告诉我们单据上的东西还会有合同上的那些必要信息，不要问他为什么会知道？ 这个是他的工作流程。这样我们的界面上就是完整的用户需求数据字典，我们在根据这些表象的数据输入界面来分析数据字典是不是容易了很多。甚至清楚的描述了 各个实体对象之间的关系。

就上边的例子，我们详细分析这个案例：

订单样例（纸张）【Order】

订单 产品列表	数量	质量	时间	标准
厚度 (cm)	氧化	I	II	III	IV
铝A	20	2 .5	不需要	08-08		是
铝合金B	50	1	需要	08-08				是

合同样例（纸张）【Contract】

甲方：A公司	乙方：B公司
合同内容； 合同责任； 合同金额； 付款条件； 2008年8月26日16:49:55

具 体的工作流程是市场部门签订合同，开始下单要生产部门，但是下单的时候合同的金额保密，所以单据上就没有金额，每个订单有一个编号，市场部门的签单人员和 老板会根据合同找到订单的编码，再询问生产部门，控制整个生产的进度。这里就有一个问题，合同怎么找到订单呢？他们目前的操作是在每个合同中增加一个扉 页，专门记录生产的跟进记录。因为还有一种情况，就是合同追加产品，比如我刚签订了20个产品的合同，送给我的时候，我觉得很不错，还需要200个，就不 需要在重新签订合同了，在上次合同上追加200个产品，这样合同只是增加了附件，而订单都要重新下到生产部门。

还隐含这样一个问题，根据合同跟踪订单生产只是一个工作，假如公司的业务非常繁忙，老板就决定先做大单，后做小单，这样就需要及时告诉生产部门进行调整单子生产计划。

如果我们做需求就分为三步：

第一步：收集这两个单据；

第二步：整理出两个实体对象（Order和Contract）

第三步：分析上边所讲的工作流程，建立E-R关系模型，难度就在这里，用户能不能清晰的描述出自己的需求？

如果我们用界面输入设计，也是三步：

第一步：收集这两个单据；

第二步：做4个界面，Contract输入、Order输入、Contract显示和Order显示；

第三步：让用户操作，就能清楚的告诉你，显示的时候少那些元素，输入的时候少那些元素，也就是让用户需求表象化。这样就容易很多了，目的一样能达到，而且用户接受度更高。

3、 不同分工的界面，胜过用户提供业务逻辑；

要 分析用户的业务逻辑实际上就是做use case，当然我们在需求很明确的情况下都非常好办，有很多优秀的工具能协助我们完成，但是问题恰恰出在我们不 懂，需要和用户不停的交流，甚至要去参加用户的具体工作中，为了解决这个问题，就出了一个新的办法user story，就是系统分析人员假设很多卡片 （令牌），用户按照自己的工作流程一步一步的拿走自己想要的卡片，系统分析人员都记录下来，用这样的办法来完成use case。

上 边的这个方法是现在比较常用的方法，但是在实际操作过程又会遇见很多客观的因素，用户能不能很好的配合系统分析人员的工作？而且用户有可能出差，开会等等 耽搁。我们在做系统分析的时候更需要企业的管理层参与，但是企业的管理层都是“忙人”，所以这个方法在系统分析的时候也会遇见很多不可预知的难度。

下边就讲讲我的一个案例，做一个网络企业的项目管理系统。说是项目管理系统，但是这个系统比较复杂，包含了人事的很多功能，还包含了CRM的部分功能以及合同管理。

大 概的需求是这样的：市场人员谈项目，在项目差不多的时候会从财务部领取合同，当时项目敲定的时候就会签订合同（当然有合同签订不了），财务审合同和客户资 料。合同一旦确定，单子就会下放到技术部门，项目经理根据合同建立项目，设立项目监督，分配工作建立任务，系统生成甘特图。被分配到实施任务的技术人员就 会看到自己的任务，以及计划工期，每天完成任务的时候进行跟进和反馈，项目经理进行进度监督，项目监督进行质量监督。

就 这点功能来说不算是复杂的系统，这个是多人协作的办公系统，我们采用了B/S架构，但是我和我们的工程师进行交流的时候，就希望这个系统能有扩展性和通用 性在权限这块就做了很大改变，准备做成自定义权限，再基于角色分配这些权限。具体的实现到后边再详细做说明，这个系统的核心是客户和合同，大家都是围绕这 个工作展开。和几位工程师沟通之后就决定尝试下我们的逆向设计思维。

人员安排：

UI一位：此角色的工作就是做用户的输入界面了，把我们设想的界面都做了，实际上工作量很小，因为这个是一个软件，不需要很多华丽的图片和动画做装饰，基本都是html。

前端开发工程师一位：此角色的主要工作是重构页面和整理js框架，这里的重构的主要工作就是为了配合js工作，比如要给某写元素加上id方便控制，js采用jQuery框架，编写了适合自己操作的插件。

php工程师一位：此角色的工作量很小，因为前端用了很多ajax实现，配合做ajax的简单响应。

系统分析师一位：分析系统结构和用户需求。

由于这个项目实施的时候并没有想到要写此书，很多原始的资料很难找到，就些截图，主要是方便大家理解。

只是想讨论一下。

1.你所提的想法跟“原型方法”有什么不同
2.软件的复杂性就在于其不断在变化，这也是现在“敏捷”方式得以倡导的原因；界面是最最具体的形式，而所谓的思想是需要某种抽象的
3.界面就其本身的设计也是有时间的，比如字段的摆放，button的摆放，一旦陷入这种无尽的修改中，UI工程师离辞职也就不远了。。

我们的情况,Project Manager团队负责产品需求,输出界面原型图+文档描述.
每个原型图都有一个page_id,便于交流时引用和QA验证.
这种方式确实很生动形象,也很务实.尤其适用于使用动态语言,开发方法敏捷灵活的团队.
apple上的omnigraph做出来的图很漂亮, firefox插件pencil sketching和传统的visio等工具也不错.

表面上看起来和原型设计非常的相似，原型设计的目的是进行产品规划，面对的工程师和项目实施成员，甚至是boss，是产品经理一个很重要的工作。但是面向界面设计的目的是为了摸清用户的需求，用户不会去看更多的解释和文档。所以就会遇见上边的兄弟说的ui设计很大的难度，但是从项目整个风险来说降低了。