前期在一个项目会议上经过大家一起讨论，按照BossJ的建议，将整个升级大致分成了3个部分：准备升级程序、准备数据、综合测试。看起来这个是一个不错的升级步骤。我大致做了个Project的，绝对粗粒度滴。

接下来的事情就是按着Project按部就班滴开始干活，由自己负责总控各个部分的进度。

第一阶段程序部分升级：80%的程序是使用原系统的一个新版本，在新版本上增加原来针对该客户定制的部分功能，及已有功能中业务上的小调整；剩下的20%是一个新系统中压根就没有的功能，需要从老版本上加到新版本上，而在老版本中这个功能模板跟其他模块还有很高的耦合。在我跌跌撞撞滴摸索+加班下，终于按时掐着Project上时间按时完成了。 这一部分的工作全是自己一个人来完成，很累！

第二个阶段数据部分升级：数据可以大致分成基础数据和业务数据。原系统中数据跟新系统的数据的组织方式整个不一样，整个数据库都重新设计过。基础数据还好办，在经过简单的加工后能很好的升级到现有的系统；业务数据就头大了，一开始我使用Excel修修补补的来进行迁移，后来发现Oracle的跨用户的操作，就改成了视图更新方式。这个过程中由于公司对Project上的时间要求比较严格，自己稍微有些压力，犯了一些错误，差点把数据跟新错误，一个很难发现的错误，最后还是在Debug下找到了源头，将数据更新回来。

客户提出需要修改一部分业务数据，期望这次更新能够一起给他们装进去。在Project里面对这部分的工作也是分成两快滴，能升级滴由我负责在数据层面操作，客户新增的信息我分配给了一个负责编写新版本业务代码的工程师A。首先我将客户提交的数据标准化，并就这些标准化后的结果更客户沟通，达成了一致，交给你该工程师。该工程师将这些标准化的数据录入系统中。这一阶段还算比较轻松，也是按照Project的时间安排来走滴。

第三个阶段整体测试：这里不是说前两个阶段没有进行测试，而是指的在整个程序和数据都准备完成后对系统进行一个测试。主要目的是测试业务数据的装入是否正确、客户定制要求是否满足。

在Project里面我安排了两名工程师G和A来协助我完成，分别给他们细分了下测试的内容。考虑到客户定制的模块功能相对简单，我安排了新进入团队的G来完成，给了IPMSG上发了一些简单的说明如何测试的文字。A就是前文提及的添加业务数据的工程师，他负责由我升级的数据。不过这个任务比较重，我只给他分配了测试业务部分的数据，而基础部分的数据是为业务部分服务的在数据升级阶段我也做过一些测试，基本上问题不大。而我负责测试有A完成的新的业务数据和负责调配资源修改程序的BUG。

说到测试，前期写过一片叫 我的测试观 的文字。

所有的问题都在第三个阶段爆发出来了，G发现了一些问题，并记录反馈给我了，得到这些记录（我们没有bug管理系统）后，我开始跟G进行沟通，确定了问题的所在，于是我放下手里的测试开始修改这些Bug。

A也发现了新版本程序的一些Bug，发现测试无法往下进行，在给我进行反馈后，他开始修改这些Bug，前文提及了A就是负责写这些业务的工程师（我们没有专门的测试）。

G现在在干吗？空闲？资源不能空闲，他被其他的工作占据了，并且暂时无法释放出来供我使用。好吧我要Review我的Project，把G这天的时间排除出去。

我继续改我的Bug，发现问题不少（一开始的时候我只是从原来的系统中将这部分功能拿过来，并植入到相关耦合模块中），怎么办？好吧！重写ing。

问题来了A又需要去一个优先级别更高的项目中工作2天。好吧，那我继续Review我的Project，A也派出去了。

终于我的Bug改完了，我还需要一些资源来帮我进行测试，在周一的项目会上，BossJ给我分配了L，对系统的熟悉了解都很深，这下好了我有了更好的资源了。我给他安排了一些新的测试，避开了A已经发现的问题，可是L一会就发现了更致命的Bug，而不巧的是这个部分是A负责的？A所在项目的优先级比我高，怎么办，自己上咯。TroubleShooting可是我的强项，不出5分钟，原来A把业务逻辑编写错了。我一直比较坚持谁的Bug谁自己改（主要是认为这样时间成本会低很多），找到了错误，我通知了顶头上司S“我需要A来修改一个Bug，估计可能需要1个小时，不修改这个Bug我的测试无法进行。”S只好现将A的优先级别降降，给了我。

A开始修改他的Bug，修改完后，我取到了最新的code，building，pubulish，deployer，继续测试。

这期间L在干吗，对了他也发现了自己负责的一个Bug，改吧。

这回我总算明白了：原来我是在给新系统做测试来着。。。

“话说天下大势，分久必合，合久必分。“

—-《三国演义》里的卷首语

键盘上有两个键C和V，而Ctrl+C和Ctrl+V是用电脑的人几乎每天都要用到滴，从事软件开发的软件工程师每天用的最多就是键盘鼠标了，而对于软件开发来说CV式的开发早已在面向过程时代就已经被抛弃。

下午跟同事讨论了一些现在开发的一个项目中问题，涉及到如何对现存的CV式的开发模式做一个改进操作。

现阶段我们开发绩效管理软件，由于管理软件的特殊性，会有很多的雷同的表单在系统中流转，为了交互的友好性在这些表单呈现的时候会加上一些其他的信息。如考核过程中最常见的部门和人员的考核表单，在系统看来几乎一样，而为了交互的友好性界面呈现就会有一些差距。就拿打分这环节来看，在打分环节，用户会用到两个页面，一个显示被考核对象的List页面，一个显示每个被考核人每条指标打分想的Detail页面。现在的模式是，现开发测试部门模块，等测试过了后，就会CV一份用到员工模块，添加一些员工模块的比如员工所在岗位所隶属的部门等信息。先不谈这种CV的方式是否符合面向对象的规则、是否丑陋等，单从代码的维护角度来看，比如List页面希望再添加或去除一列非控制字段，至少需要修改两处。更大的噩梦来了，在审核、审批的环境同样使用这个List页面，这样一来修改的地方久更多了。

针对这种CV方式带来的不便，我曾经尝试将这些共同的部分单独抽取成一个一个方法，以供调用（抽取成方法而不是类是由于框架对类的继承有很多的限制），可这种实现亦不是很优雅，将显示的逻辑放到了业务中。

今天讨论得出的结果基本跟我曾经尝试的方式雷同，某种程度上只是对原有的CV模式的一个规范而已。

想到前一阵子学习的ASP.net MVC的框架中，将数据绑定直接写在.ASPX页面上，给了我一些启示，虽然没用到MVC框架，是否也能将现有用于显示的Grid、Grid前的表头等信息做成一个一个控件（ascx），控件中会设定一些参数，根据这些参数来直接访问数据库，返回需要显示的信息，这样就将变化的源头控制在了这个ascx上，一来能已很少的成本来调整显示信息，二来可以将部分的显示逻辑从业务逻辑中分离，三来对以后的控件升级扩展也能更方便。

下阶段将尝试做一个Demo来实现这一想法。