没头没尾--项目开发笔记：先开发UI层还是先开发BusinessRules层!!??

标题：没头没尾--项目开发笔记：先开发UI层还是先开发BusinessRules层!!??

关键词：分布式开发 C# 项目分工 DELPHI与C#的混合开发，开发过程，分模块开发，分层开发，RUP实施过程

11月26号：中午又听说朋友们买房子了，真为他们感到高兴

 

上一个笔记中longbow74朋友有以下的评论：（以下的讨论是建立在一个业务系统中，也就是带数据库连接的那种J）

我觉得UI该放在BusinessRules后面做，毕竟UI的可调整性和调整的可能性最大，注意力应该集中在BusinessRules上。当然你可以做个demo先，让客户和自己通过demo加深对需求了解的深度。

RUP的实施过程是与CODING过程相关最多的过程。可是我在网上查了一下资料，似乎它也没有关于如果你要是采用分层开发的方式来进行开发的话，你应该是作UI层百是先作 BusinessRules层？

其实对这个问题我们项目组也有一些讨论。也就是说当我们已经定下来采用分层方式开发之后，层次之间的开发的先后关系是什么？是不是可以并行与同时开发的几个层次？对于这是个应该说并没有答案的问题。我的选择是先开发UI，再开发BusinessRules层，这个选择我想我是根据下面所写的理由来做出的？

1.         客户需求（可以参考《没头没尾--项目开发笔记：对应开发方式的变化》中的那个契机J）

2.         对应我们需求的问题

我们的需求将会是我们的测试人员，并且领导给我们要求是一定要充分的让他们有事干，不可以让他们闲着。（简言之就是他们写完需求之后，就可以开始写测试计划，他们的测试计划写完了我们的项目就要有东东给他们测。L）

3.         我自己的问题

客户端的开发是采用Delphi，这一块我非常的不熟。并且我需要时间来准备Server端的框架以及代码的生成。所以这样的分配时间对开发有利。先充分的利用Delphi的牛人开发客户端。

4.         对应我们的开发队伍的问题

开发队伍是第一次去使用这种CODING方式。如果我们先开发BusinessRules，那么我们的开发过程一定是一开始就要把构件定义清楚。还有输入与输出分别是什么，并且开发的过程中可能我们要为开发时Debug的过程开发出一个专用的构件的Debug工具。还不如直接先做出来界面然后再做Rules。这样可以有东东看见你的运行结果，也就很直观的可以知道程序是不是按照开发人员所想的进行工作罗。

5.         一个理由

以下的胡思乱想，也算是对先开发UI层，后开发BusinessRules层的一个理由。

首先我想从从一个比较奇怪的角度来总结一下我们已经习惯了的开发方式：第一步是总结用户的需求（A提炼过程）；第二步根据用户的需求产生一个面向对象的设计（B提炼过程），第三步根据面向对象的设计生成关系数据库的设计（C提炼过程）。上面这几步是开始CODING的过程之前的准备工作。如果上面这三个过程都完成的非常好，那么我们一定要编程实现下面的几个过程：

1、  建立公用的对象；

2、  建立关系数据库，并编程实现与关系数据库的连接（传说中的DOJ）；

3、  建立对应对象设计的程序（传说中的BOJ）；

4、  建立对应面向用户的界面程序（传说中的Page ObjectJ）；

5、  建立关系数据库各表与对象设计之间的联系；

6、  建立面向用户的界面程序与各个对象之间的联系；

这个过程应该是CODING人员最为关心的过程了。这五个步骤是123456，还是432145，还是…………，这个其实都是在不同的项目中有可能出现的。

看见上面写的这几个过程，对应到我现在的开发过程中，我突然有点不明白我以前的软件是怎么开发出来的，这些步骤什么时候走的，还是根本就没有走L??上面这几点看起来虽然有点乱，可以真正你想要做出一个应用程序是缺一不可的（当然也可能直接会有人从面向用户的界面连接关系数据库的各个表。我们不推荐这种方法罗）。那可能朋友们会讲：“别给我玩这个，我开发程序时候可以不按照这些步骤来进行开发。”可是实际上很多项目（就好比我原来做的项目）在没有意识到上面的情况下就已经糊糊涂涂按一种方式来开发上面的几块东东。为什么我们可以去糊糊涂涂开发。那是因为我们具有经验，了解什么时候可能会出现问题。这样一个过程也就是从经验上的区别才可以得出开发一个项目。

如果只是从空想的角度，那上面六个过程应该是对一个公司，或者说是一种类型的项目是有一个固定的先后顺序关系。可是在真正开发项目时，谁也并不关心现在是做到什么步骤。老板并不会管你已经开发到什么步骤。只是会不断的去问你项目的milestone点在哪里？然后用你定好的milestone来搞你，查你的东东有没有在你定义好的时间里要搞出来。虽然这样子是有利于一个项目的成长，可以时间的打压下项目的质量也许得不到什么保障。

那么我的第一个想要实现的就从头到尾都要有可以看见的，可以沟通的东东存在我们的项目中（文档当然是可以起到这个作用，不过文档写的出来不一定开发的出来，客户喜欢可以执行的东东，如果这个东东是和以后他要去使用的界面完全一样的，那就更好了！）

回到上面那个朋友说的，其中我想有一句是很有代表性的。那就是毕竟UI的可调整性和调整的可能性最大！！这个观点说出来我想90%开发过业务系统的人都会点头的。可以有没有人去仔细想过为什么是这样子！？

回头去看看RUP的过程吧，RUP的过程是很强调迭代过程，不过从我的理解中，RUP的迭代过程为了保证流程的完整性，它的规定是整个的开发过程进行迭代。而并没有对应提到开发过程中每一个细的过程可以因为分工开发的关系，在本环节内自己独立的进行迭代。（我看见的一篇RUP有关有上级系统与下级系统的不同RUP过程中有一点点提到了，不过并不明显。）如果一个开发过程时间较长，那么开发出来的产品在每一次迭代中一定会遇到客户对UI的不满意的现象。如果我们有办法将UI的开发独立于开发过程之中，使之形成单独的迭代过程，那么对于这个问题我觉得的可以解决一部分。

然后朋友提问问题的第二个方面是，为什么UI的可调整性以及调整的可能性最大。那是因为用户只能看见界面。也不是说别的没有问题，只是用户不可能一次性看出那么多的问题而使我们逃脱对BO之类的修改。

我正在做的这个项目的客户非常的了不起。他们已经通过自己对软件行业的理解为我们定义基本的思路，而不我们只是理解他的想法之后告诉他我们可能会采用什么样的方式来实现而已。我想以前的软件行业中，基本的运作模式是我们有一个新技术，那么我们去了解客户要什么，我们去想什么可能可以提高客户的生产力，给客户赚钱。可是基本是从我们（非专业人事，不直接从中获利）的角度出发来考虑问题。但是时代真的是已经在进步。客户自已可以知道信息系统可以给用户带来什么，他们真正的去开动脑子想问题……这个就是发展。从让我们这种外行去帮助他们设计软件到他们可以真正去提出自己想法来设计软件。这个事情的本身就已经是进步，但是这种进步却没有本质上的改变我们的开发方式。也就是说，经验这种具有社会属性的因素，并没有进入到开发过程的理论中。RUP并没有告诉我们如果有经验应该如何来开发，没有经验应该如何来开发。当然也就更没有办法去告诉我们如果客户的要求用一个带有所有的界面的应用程序来进行演示的话应该如何去做。J

我想我对RUP并不了解。看了一些RUP的书，但是总是觉得和我想像当中的开发模式并不相同。看上去最短一个过程要是五脏齐全的话三四个星期也完不成。而且至少从需求到设计到开发都要是比较专业的人事。可是一直以来我都有一个想法是在现在的开发过程中的发展一定是要以用户为导向的。也就是说时时刻刻的以用户，是彻底的面向用户的开发。如果新的技术可以帮我们在开发的过程中第一步就给客户一个可以迭代的界面，以及在迭代的过程中给用户一点点的完美，这才是真正去为用户来考虑问题。

其实我罗罗嗦嗦的一大堆，并不是说我已经找到了好的解决方案。我只是想提醒朋友们一定要注意，用户不在是以前所说的那种只会把需求变来变去的那种笨蛋了。而是进步到真正的即了解计算机还精通业务需求的人员。那么我们对应的开发过程要根据用户水平的变化产生变化。Coding过程中，我想我们已经可以通过框架技术实现分层次的开发方法。那么分层次的开发方法就要一定是以用户为导向，一定要先让他们可以了解到你们现在在干什么？最快的速度去拿出东东来和他们沟通。这种过程当然在现在情况下是几乎不可能的。不过我还是要去找到这种可能。

没有，我想现在的分层结构是向这个方向发展的第一步（是发展，不是变革），出现了分层结构（也算是硬件条件成熟了），那么分层的开发模式一定要发展起来。分层的开发模式充其量也只是一个变化。分层的开发模式将会去加大程序开发者内部的分工，一定会将一部分的UI开发人员与需求人员整合在一起。提炼出好的工具，将得需求可以很方便的建立出可以合适于给用户看的需求的程序。（其实我一直想直接把我们已经封装好了界面层都直接给我们公司的需求人员，希望他们可以直接帮我们把开发过程中的第一步的界面封装的部分直接作出来。那么我们可以去想办法去帮他们生成与数据库的连接部分[其实这里又不自觉的忽略了好几个开发中都必须经过的步骤 。]，让他们只用界面来就可以生成一个可以跑的直观的应用程序。可以直接与客户进行交流，以及可以直接得到客户的反馈。那么真正的CODING人员可以干的也就是复杂的业务逻辑。也就是在一个或几个层次中进行迭代开发。）

不行了，思路有点混乱了，回头再写吧，回头写写有关代码生成的东东，好象有的朋友比较关心这些问题。