实现邮储柜台模拟程序杂感（二）

实现邮储柜台模拟程序杂感（一）

4、事件机制

事件分为同步事件、异步事件，主要是用来实现项目的可伸缩性、降低模块之间的耦合。

J2EE中的标准为JMS，有很多的实现项目，核心技术：对象序列化+TCP/UDP通讯+线程管理。

具体内容：系统中何时上异步消息架构

5、系统开发

 

在编写代码的过程中,采用了分层开发和按照模块开发2种开发方式.

分层开发能够保证系统层次分明、职责清晰；强制性的使用面向接口开发：业务处理开发必须依赖Mock对象才能继续下去；在系统设计阶段就必须确认好每层之间的参数传递、接口依赖规则，在每层完成之后要同步更新文档，开发、集成测试的时候需要更好的协调、沟通。

 

分模块开发，开发人员从开始到结束负责功能模块的开发，减少了协调与沟通，开发人员有可能不会开发大量Mock来实现TDD。分模块开发减少了成员之间的依赖关系，在大型系统开发过程中，应该是分组件开发，由多个公司合作开发，对交流的有效性要求很靠，无论是分层开发、还是分模块开发都会陷入到交流、协调的困境吧？

 

分层开发的最重要的特征是层与层之间的松耦合。松耦合所带来的结果是，各层之间都可以有自己的基础模块，可以实现本层内部的重用，在底层发生变化的时候（变化协议、变化技术、甚至变化介质），上面的层是可以花费很小的成本进行适应的（比如操作系统和应用程序层）。同时如果有人员离职，在分层模式中，很快会有人填补这个空缺。在分模块模式中，如果负责一个模块的人离职，新负责人就需要重新熟悉这个模块的流程才能继续开发，项目风险较大，或许Pair-Programming可以解决。

模块化开发，估计每家做企业级应用的公司都必然会采用这个方式。拿用电系统来说，客户服务模块和电费管理模块业务差距非常大，非业务专精人员，很难在短时间内写出高效和高质量的代码（光是业内常识就有的学的，而且各处业务还都不大相同）。

 

层应该是从系统架构方面考虑的，是对系统的纵向切分。模块是从功能角度划分，是对系统的横向分解。在模拟设计过程中，使用的是分模块设计，分析出每个功能模块的处理流程和参数传递。在编码实现每个模块的过程中，不同的组内成员负责不同的代码层。

 

6、项目杂感

1、“项目和产品都需要有应对变化的部分，项目更在乎功能的实现以及对于需求的应变能力，产品更在乎的是通用性的高度抽象、开放性以及基础设施的建设上，产品比项目更依赖规划人员对于通用性需求的挖掘上，而项目则更依赖需求人员对于客户的需求的挖掘上。”

2、“产品研发和项目开发过程和资源投入是有本质上的区别。

相对来说，项目开发来的容易一些，因为需求收集来的容易，需求主要来自特定客户，最后开发的功能只要满足特定客户就可以了。但是产品研发就不一样，考虑的面要更广，它不是为了满足单一的客户，而是要满足一定量的客户群，高度跟项目不一样。配置性和扩展性方面考虑的会比项目多一些。我在这里抛砖引玉，主要是想听听大家的意见，一个产品或者平台的研发，什么样的过程才算合适和合理，还有就是应该配备什么样的资源。

之前我们是这么做的：

可行性分析、产品规划（做的不到位）、业务蓝图设计  

软件系统分析（为了满足一定的客户群，这块做起来很困难、跟业务蓝图衔接）

设计

编码

测试

主要在前期规划和需求分析特别费劲。

最后出来的产品的适用性不是很高，有时还需要大量的定制开发。”

3、“产品研发与项目研发的区别，业务目标与范围不一样，产品关注的是行业领域一类客户的需求的共同点与差异，需要长时间的业务调研，最终成为客户的一个业务顾问，系统除了可靠性，用户体验，稳定性，在扩展性，可配置性要优于项目，而项目是满足特定客户特定需求，是一个短期间的目标，当然大多数产品离不不开项目，或起源一个项目。计划和投入也不一样，产品是一个长期积累和不断进行业务提升和发掘新的业务，不断满足客户的需求，需要一个长期和长远的规划，投入的时间，人力可能需要长些，开发流程和管理也与项目部一样，可以参照IBM RUP的过程，是一个不断迭代优化的，分割成不阶段的项目目标来实现，管理方面需要长期的培养相关的人员和长期的质量风险控制。需要培养售前，投标，业务顾问，维护方面的人才。才能把产品做成一个品牌一个领域的专家。”

 

工时估计：

模拟器项目最终交付用时比原计划用时多了一倍.原计划评估工期的时候,评估的重心是放在功能需求的实现上,忽略了技术实现的难度上.如果在一个项目要使用一个新的技术,需要的是对这个技术有过深入的前期调研、熟悉技术在使用过程中应该注意的地方。在实现模拟器的编码过程中，项目初期3天时间是消耗在所有业务的数据访问层（DAO）的编写：bdbje事务的特征和管理、bdbje非线程安全变量的处理、关联数据库的管理，这些技术细节需要很仔细的测试才能防止编码过程出现错误。通过freemarker模板生成对账文件的过程中，因为有过以前的使用经验和前期测试，这个业务仅仅发费了0.5天的时间就完成编码了。

 

模拟器中有很多xls配置文件，每种配置文件的级别和作用都不相同，也消耗很多时间来了解以前的代码处理流程，同时要保证新技术（BeanShell）的数据源解析的办法与以前类似-在设计阶段低估了这个流程的困难。

 

项目的业务需求实现所使用时间与预先估计的时间相符合，但是解决使用新技术带来的困难的耗时估算过于乐观。

 

配置文件与业务流程：

这种可扩展性不是指close-open原则中的可扩展性，而是指同一类型交易中可以通过配置不同的交易电文、不同的处理条件来实现不同的交易流程-实际上这些流程都是类似的。根据用户使用后的反馈，模拟器的需要增加逻辑处理流程：

事件1：文件生成之后，自动通知交易（2020）；

       事件2：网汇通卡被使用后，更新卡状态；

业务逻辑：事件源、事件类型、事件处理器

每个事件处理器的动作不同，这时需要通过编码来解决每种事件类型对应的事件处理器的动作。

在模拟器中，配置文件主要作用是为同一类型交易提供数据源。当不同种类的交易发生联系后，如果使用配置文件来判断这种“联系”的性质，就需要提供类似于工作流的条件判断处理器。

 

编码规则：

       每个项目都有自己的公用变量、变量的命名规则、文件的命名规则。而Java项目一般遵从骆驼命名法。在编码开始的时候就应该和成员约定好这些规则，否则导致项目管理上的麻烦。