标题：没头没尾--项目开发笔记：分模块开发!!?? 分层开发!!??
关键词：分布式开发 C# 项目分工 DELPHI与C#的混合开发，分模块开发，分层开发
11月23号：晚上，上完课、吃完饭、洗完澡、边看曼联的比褰边写项目开发笔记
今天回头看看上一个笔记。我想回忆一下产生这个想法的过程。与朋友们分享一下。
以前最为普通的方式是分模块开发。上一个笔记中写的分层开发过程可是说是一次尝试，其实是我从很少的以前的二三次开发实践中推想出一个方案。我想从我过去参与过的两个项目以及这个项目的区别来分析一下我所说的分模块开发与分层开发的区别。
从我的经验来看（我的经验虽然不多，不过分层的开发经验还有一点，这个下面会提及。），我希望可以进行分层开发。可是并没有在公司内部找到NET环境下分层的例子。上一篇笔记上提的三步开发过程是我理解分层开发过程的一种体现。每一步都会有专人负责（出现需要修改的问题，以及测试中测试的问题可以找到专人。）每一步开发时可以关注于本步开发过程中对应负责人所负责的层次内容。虽然我们是个小P公司，我也不可能找到真正意义上每一层都专用的人员来实现开发工作。我只可能去明确不同的阶段项目组的成员干不同的事情。也算是对分层分工中的一点均无奈的修改。
1、 一个系统保健的软件
l 产品开发的目的
这个产品与以下两个产品的开发公司并不是同一家公司。产品的目的是做出一个类似于诺顿的系统维护软件。用途是对安装本产品的电脑进行Overall的保护。卖点也非常明确，希望可以作出一个OEM的产品与公司出品电脑一起卖。
l 开发使用的工具与环境
VC++ 6.0；Win95与Win98
l 开发过程的简述
由于是一个系统级的软件。而且这是我所在公司自己要开发的项目（没有客户作为需求）。所以只是我们的项目根据公司同仁写出的需求与设计文档来进行开发。项目经理将项目分成了不同模块。分给我的是写一个分析目录结构以及分析目录中所有可执行文件所关联的文件列表的模块。我需要写几个类来实现这个模块。
l 从开发方式来分析
这种类型的开发方式是完全的分模块开发的。按照面向对象的方式进行设计。项目经理分解出各个模块应该完成的不同模块，并将这些模块分配到各个人的手中。每个人根据定出任务完成自己的部分。通过接口进行组织。这个项目是我工作以来的第一个项步，我只是被动的参与，并且当时P也不会，哪有可能去考虑开发过程的好坏，更谈不上对开发过程的改造。
现在我认为分模块开发的开发方式有很多的好处，但问题也会有：
1.客观上需要程序员在每个方面都比较精通，至少要可以看懂例程并根据例程来写出自己从界面到数据库连接的各种程序。
2.不是每个人都在做自己最为专长的事
3.可要会耍耍塞叩（SQL）:)
4.如果在已经定义出程度框架是分层的情况下，分模块开发方式会涉及到每个人对分层框架的理解，如果他的理解出现问题，就将会导致辞他开发的那个部分与其它人开发的部分不一样，与程序框架的具体想法不一样。（这里当然会有监督的关系。）
5.不利于人员的分工
6.不先进（这属于瞎扯J）
当然，对于高手做出项目都不会有问题。对于时候特别紧的工程有时候要完全依靠高手的经验来进行开发的话，这种方式也是一种很好的选择。
还有就是这种开发方员可能使每一个开发人员都学到很多方面的知识。这个可能对开发过程中人员的积极性会很有好处。
2、 一个java开发的软件
l 产品开发的目的
一个基于纯的B/S的进销存系统的基于互联网的应用。使用公司自己开发的Java的应用服务器。主要完成的业务是进行大量的查询，统计工作。小量的信息维护。
l 开发使用的工具与环境
公司JAVA应用服务器；服务器端：Win2000；客户端：IE5.0。
l 开发过程的简述
公司的JAVA应用服务器是一个层次结构比较清楚，并分层的有一点死板的层次结构:(。有UI层，Page层，Business Object层，Data Object层。其中UI层是带内嵌自定义标记的HTML或XML文档，Page层是对UI层中的自定义标记的数据填入。Business层的任务是数据的判断，Data层处理对数据库的连接。
需求定义本系统只一个相对封闭与简单的业务系统。没有普通的进销存中大量的单据录入之类功能。报表之类的数据来源是基于其它基于C/S结构的应用输入的。开发过程我们项目小组的成员虽然都有开发JAVA应用程序的经验。可是都是第一次使用公司从米国带回来的JAVA应用服务器。那么项目小组的成员在一起摸了摸这个java应用服务器的组成以及固定的程序开发模式之后。我们小组成员通过商量之后得出下面的开发过程。
i. 第一个步骤：准备过程
1.项目负责的同仁以他对业务的熟悉经验，开始设计整个系统的业务以及实现数据库。
2.我来负责总结出用户界面一共会有几种应用方式。针对总结的结果制作出对应的几种XML文档的格式，以及对应的客户端的XSL文档，对应的JS文件。
3.还有一个同仁开发一些我们的系统与上面所说的C/S的系统进行数据交互与同步的工具。
以上三个过程我们三个人是同步进行的。
ii. 第二个步骤：开发
以上过程准备好之后，我们的开发工作的重心转移到真正根据业务来进行开发。这个步骤中还是采用分模块的开发方式。每个人按照分给自己的模块来进行数据的提取与处理，并将数据生成我在第一个步骤中生成的XML文档的标准格式以显示给用户。在具体开发时我们掌握的原则是如果有数据库需要加入在第一个步骤中没有准备的存储过程或者对应需要修改数据库的话，那就直接提交给项目负责的那个同仁，他来统一处理。如果在页面显示上出现什么问题，或者有新的需要产生新的页面模板，都统一找我，我来想办法搞定，并可能去修改对应和XML模板，XSL的解释文件。
iii. 第三个步骤：测试过程
这个过程没什么好说的。只是出现测试的问题在修改的时候按模板找到我们开发人员，我们按照第二个步骤进行问题修改。
l 从开发方式来分析
我认为这个项目是属于半分模块开发，半分层开发的方式。当然我们在开发的时候根本是没有考虑什么分模块开发或什么分层开发的方式。可以在实际的开发中，由于我们应用了XML，以及具有框架的开发工具。那么在开发的准备过程（第一个步骤），我们实际上已经在分步的开发UI层与Data Object层。那么在正式的开发中，我们都参与的实际上是开发Business Object与Page Object（UI与Data Object还是一直以专人进行负责。）虽然这个项目CODE的人员只有三个人，不过开发起来分工使得开发过程中每个人的能力使用的非常充分，还是蛮爽的。
还有就是说，从这个开发过程总结中，制定人员的分工以到人员在项目进行过程中角色的转换的经验得到了一定的总结。
也许是这个项目的开发过程以及应用的结果使我在新项目的时候对进一步的使用分层开发的进行考虑。
3、 现在的项目
l 产品开发的目的
以前的笔记已经说过了。
l 开发使用的工具与环境
VS.NET，DELPHI；服务器端，Win2000 Server + Net.Framework + ASP.NET；客户端：无要求。
l 开发过程的简述
开发的设想也是有三个步骤（上一个笔记已经具体一点的描述。这里只从分层的角度简单的说一下。）
i. 第一个步骤：准备（数据库以及一个有名无实界面文件的准备）
1.指定二位同仁（对业务的经验一般，对数据库以及与需求沟通有很好的经验）进行业务提炼，以及设计数据库。数据库设计结构后使用VS.net的工具生成CommonData与DataAccess.Base层的文件。
2.我来负责搭建服务器端的工程，建立每一层开发时使用的文件例子，以及消化兄弟部门的代码生成的小工具的思路，为我们的项目制作一些代码文件自动生成工具。
3.还有一个同仁负责主管界面几个层次的开发。他必须提早来做出各个界面的模板，以及各个界面所用的控件的重新封装（第一步中他只需要将界面的控件进行一次重载就可以，在其它的同仁们用他重载的控件来搭一堆有名无实的界面时，他可以根据用户反馈的意见进行统一调整，如色彩，风格等）。写一个DEMO指导项目中其它的同仁来开发界面
以上三个过程我们几个人是同步进行的。这个过程已经结束。
ii. 第二个步骤：有名半有实的界面开发
分任务的时候是采用分模块的方式来分，但是实现上过程我们又抽出一个同仁来负责界面与服务器端的数据连接。那么还是大部分的同仁按模块的开发界面部分（UI层），需要数据的支持（如取数据与回传数据时）统一找那位同仁，他负责与我交互，我负责与数据库同仁进行沟通生成对应的WebService。看上去这些步骤非常的麻烦，可是每一步都会有专职的人员进行分工。并且我的要求是走通步骤，只实现最简单的数据查询与数据提交。（所以是有名半有实的界面开发。J）当然，具体的操作时有一些小技巧，我想以后再细说。
第二步的目的非常的明确，完成之后界面层的所有操作都完成（UI层）（以后的进行的调整不算）。为第三个步骤中所有的人集中在BusinessRules开发做好基础。
这个步骤还在开发过程中。
iii. 第三个步骤：开发BusinessRules
这个过程还没有开始。当第二个步骤已经结束时，我们应该已经得到所有的代码的框架，以及所有以及一个可以跑起来（数据不完全）的应用程序。那么所有的人（除了数据库支持人员）在这一步的开发中可以全部都集中来开发BusinessRules，去开发数据获取与提交时需要进行什么判断，以及一个业务事件将会对其它数据库表进行修改，增加操作的业务处理。
l 从开发方式来分析
现在还没办法可以完全知道会有什么开发的结果。但我想这种类型的开发步骤从相关几个项目过程有新的思路与帮助。比如对应测试的过程，从第二个步骤可以开始对界面的部分测试（比如定义出的输入不可以为字符的TEXTBOX是不是符合需求设计。）；又比如第二步可以得出一个有直接可视的工程。（这都是瞎想，项目做完以后写总结时说的才是结论，等到那一天再说吧。）
其中我想有很多的步骤可能都是开发人员通过经验去忽略了，一些软件工程中定义的过程的文档以及过程中一些合作与默契也是不好定义与把握。不过写到这里，我觉得对我自己也起了一个很好的总结作用。希望朋友可以多提提意见，并感谢各位朋友。我想我会在下一个笔记中与各位朋友讨论一下各位给我提出的宝贵意见以及本项目第一步中遇见的问题等等。
（哈！曼联5：3狂胜，看的超过瘾！）
