德克云技术联盟

标题: 使用DFMsg将项目合理切块，并行开发。 [打印本页]

作者: 李昭 时间: 2014-10-27 11:25
标题: 使用DFMsg将项目合理切块，并行开发。

      其实省编办项目完成后一直想将项目中的一些新的管理办法和新技术手段的使用情况做一个总结，为后续项目提供经验的分享和支持，但是一直没有时间来进行整理，拖的时间长了，就忘了。现在终于能在DFCO2.0框架初步完成的时候来做一个总结，一方面能让大家来看看我们在项目管理中采用的一些新的管理办法，以便后面的项目管理人员能够进行借鉴，另一方面也阐述一下新的框架对我们的开发反向回来的良好促进，以及在新框架下我们的工作方式的转变将面向服务进行，开发人员在新框架下的支持下将能够将更多精力投入到业务性服务的实现上，构建更为良好的云服务系统。以下将详细阐述这些内容。

1、DFMsg的核心作用。
   1）有人问，DFMsg在表现形式上就是JSON格式，那我在编程过程中直接用Json就行了，DFMsg好像没有什么特别之处，我为什么要用DFMsg？
         答：DFMsg基本格式用了Json，但是比Json多了关键字的概念，这些关键字不同于不同的key值，它能更好地标识数据的类别、格式，带有特定的意义，为DFMsg的接收、发送组件提供更为丰富的操作空间，为组件、服务之间的通讯提供协议标准，提高组件复用程度。
         例如：没有DFMsg2.1标准支持之前，我们对错误的传输可以定义为：{"error":"出错了！"}，也可以定义为：{"err":"出错了！"}，一千个人可能有一千种定义，这给客户端的解析带来很大困难。有了DFMsg2.1标准的支持，则所有接收方可以从{"errorcode":"1001","errormsg":"数据出错了"}这段报文里面读出来程序发生了编号为1001的错误，其内容为“数据出错了”。
         扩展：缺乏统一性的DFMsg使用起来过于随意，在单项目里面可能不会有太多体会，但是在面向云计算时就会造成语言障碍，所以必须首先对DFMsg的规范性进行确定，这就如同我们做一个项目是使用java还是.net一样重要。这就是DFMsg的数据标准性的第一个重要体现。

   2）现象和做法：在省编办项目中，我们在进行原型设计后，直接查看页面，确定页面交互点，然后根据这些点用了两天时间确定了交互所要使用的DFMsg，将这些DFMsg发布在虚拟服务中，这时候前台页面和后台数据的编码工作能够同时开始，这种做法使原本与需要一个月的工作时间立即得到了压缩，并且前后台的集成工作进行起来十分顺利。
      分析：在实际生活中，人与人之间的交互采用语言交互，同理，德克云的组件之间我们用DFMsg来进行交互，这种机类语言的机制使德克云组件、服务的建设可以分别建设，而在组件、服务之间通过DFMsg来进行通讯来进行配合，完成业务功能。这中架构方式已经超出了传统项目的项目管理方式，使开发向一个可持续、可积累的方向发展，更贴合云计算不断改进的需要，使项目开发周期能够缩短。
      这也是DFMsg作为数据标准的一个重要体现。

2、今后的项目将在项目初期划分服务块，这是重要的一环。

      项目在设计建设初期，我们通常需要建模，将项目划分成合理的功能模块来进行建设，在DFCO2.0的应用背景下，我们还需要在项目管理环节中加入服务建模这个环节，将功能模块组成成为合理的服务模块，来进行建设。一些功能与已有服务相同的功能，就可以重复使用以前的服务，提高代码的重用量。
   例如，在SFE1.2的建设过程中，项目被分割成为
1、DFAM2.0.0.0主体
2、AccessService1.0.0.0
3、DFAM本地管理端1.0.0.0
4、AccessService本地管理端1.0.0.0
5、SFEClientService1.2.0.0
6、SFEMgmtService1.2.0.0
7、SFEPC管理端1.2.0.0
8、SFEAndroid手机端1.2.0.0
八个部分。

3、项目开发过程中各个服务模块的测试版、开发版、虚拟版之间的互相配合。

      例如，在SFE1.2的开发过程中，我们测试了多人同时开发的项目开发模式，基于上面1、2两点，项目个服务模块之间的配合有这几种情况：
      1、当SFEClientService（SFE客户服务端）没有建设完毕时，手机端的开发需要后台数据支持，这时候我们建设了一个虚拟SFE客户服务端的“虚拟端”，它能够根据收到的报文返回固定格式的报文，以便手机端能够完成数据的请求、加载过程。
      2、当SFEMgmtService（SFE管理服务端）没有建设完毕时，  SFEPC管理端需要后台数据支持，他同样访问一个“管理服务虚拟端”来完成数据的请求、加载过程。
      3、预制的用户数据需要有地方输入数据库，我们用AccessService本地管理端、DFAM2.0.0.0主体、AccessService1.0.0.0三部分来进行操作，既完成了输入操作，也避免了一系列的动作在数据库中的直接操作，降低了人为操作数据库数据造成的错误和风险。

      可以说，这种开发模式在本次SFE的项目开发过程中的使用还是很成功的，开发过程中节省了大量时间进行任务分配、各模块之间的配合等工作，也将项目各模块之间的磨合过程在开发阶段内进行了消化，大大降低了通常在项目集成阶段出现的大量的Bug，从而尽可能地缩短开发周期、降低项目组成员的工作压力，提高工作效率。

4、测试人员的介入可分服务模块进行
   其实在SFE1.2开发之前，测试人员已经介入了DFAM的测试工作，也提出了相应的修改要求，开发组进行了部分的修改。也就是说，DECO2.0带来的这种开发模式不仅仅能使开发过程分服务模块并行开展，测试人员也可以在开发中及时切入服务模块的测试，而不是等到全部项目完成后再介入测试，测试工作提前也能够使项目开发周期缩短。

欢迎光临德克云技术联盟 (http://www.decoclouds.com/)