紧张而有序的一年马上又要过去了,忙碌的一年给个人的经历又增添了浓重的一笔。
2012主要参与处理的任务
- N9系统业务模块安装盘
- N9系统结算系统的维护和二次开发
- N9系统结算系统与信贷整合
- N6-N9数据迁移工具的开发
- N6-N9数据迁移Kettle程序的开发
- N9鞍钢项目现场技术开发和支持任务
- N9鞍钢项目数据迁移任务
- 中电投性能优化任务
- 辅助浙能项目数据迁移任务
- N9鞍钢项目攀钢迁移任务
工作经验和成果
- N9系统工作
从11年入职以来所负责和参与的工作一直都是基于N9系统,最初负责N9系统环境的部署安装并协助鞍钢N9项目构建鞍钢N9系统环境,后来是N9柜面系统相关的开发整合任务,包括N9结算系统二次开发、N9系统各业务模块安装盘、结算与信贷整合、N6至N9系统的数据迁移。
从技术角度来看N9系统,N9系统是一个包含很多经典设计模式,N9的设计非常优秀是我学习的榜样,N9系统的总体结构非常的清晰,清晰的结构和优秀的设计带来了高可复用、可扩展性,但是这确实也提高了开发人员的技术门槛。
在刚开始负责N9系统结算系统维护和开发工作期间,对这些行业业务名词和流程都不熟悉,对这块要谢谢我们经理给予的各方面的帮助,谢谢之前同事写的关于N9系统的文档,很难想象没有那些资料的情况。
对N9系统的工作使我更加认同软件系统文档的重要性所以在工作之中我尽力的整理出自己对N9系统的学习和开发经验并上传给公司知识库以分享给其它同事。
- 鞍钢N9项目
鞍钢N9项目是我个人工作以来经历的非常锻炼人的项目,这个项目给我个人的积累不再是简单的技术主题,而更多的是个人综合素质、团队配合、协同工作。在与同事的协作过程中有意识的提高自己的交流、沟通、描述各方面的能力,在这个过程中体会到软件工程和标准化的意义真正理解到CMMI等软件管理主题存在的价值。我们技术存在的价值就是为客户服务,技术只是整个软件工程中其中一个关键点,良好的技术体系是支撑起好的软件产品的基础,但技术一定不会也不能是软件的全部。
在鞍钢项目感触很深,很钦佩范经理的工作作风,他的那种对待事情的态度和坚持不懈的精神是项目成败的关键。
看到有的同事那么晚了还在支持着现场的Bug!
看到有的同事被现场一个电话一个电话的打扰着但还是认真的去对待问题!
看到有的同事为了一些公司的问题而争论的面红耳赤,但他们是对事不对人的!
看到有的同事做着不被人重视的工作但同样硬着头皮去完成它,这是对自己的超越!
到有的同事他为了大家公共的事情而费心费神的去想着还会有哪些事情没有暴露!
项目责任让大家联系到一块,虽然这样那样的事情接踵而至,但在大家的共同努力下事情总是可以被解决。
- 数据迁移
迁移前期需要考虑的几个问题
- 迁移源与目标的对应关系。
- 划分阶段是非常明智的选择。
- 如何对迁移后的数据进行验证。
- 需要哪些类型的工具来支持迁移的过程。
- 迁移后的验证场景数据初始化。
迁移工具
迁移工具这块我们使用了Kettle完成需要进行复杂逻辑转换的场景,而结构逻辑简单不涉及到的数据分析和转换但结构数量非常大的场景我们选择构建自己的工具包来做。
迁移工作
总结我们在进行迁移工作时遇到的问题,
- 耗时最多的不是沟通/交流而是迁移后的验证流程,因为我们是业务系统的迁移,迁移后还需要做非常多的各子系统重新初始化工作而这些工作如果独立出来也可以做成一个不小的工具包。
- 无法回退,迁移完成后进行的业务流程有的跨多个子系统,这让我们在没有提出将任务划分阶段来做的想法时让大家很被动,又认真的实践把大问题分解的思想。
- 验证场景,迁移源与目标上的应用程序场景业务流程一致但实现技术上差别较大,涉及到的业务知识面非常广所以需要协调到多个熟悉不同子系统的业务和开发人员共同验证,但这样会非常耗费成本。
- 迁移过程中的需求变化,这一点我们再次验证了随着大家对某件工具的理解越发的深入总是会有新的需要新的想法和改进意见。
- 迁移工作涉及到最基础的是数据库中的数据,一个结构设计合理表实体间的对应关系、列的取值范围、列的取值与业务逻辑的处理的映射、列的取值约束、列的默认值约定,看起来会在设计上一笔带过的问题在今后的维护扩展工作留下隐患增加工作量。
- 数据迁移阶段会把原始系统隐含的一些Bug和缺陷给暴露出来,这块会影响到整体数据迁移的质量和进度。
- 数据迁移初期的技术评审很重要尤其涉及到业务子系统的数据迁移,咱们单纯的几个同事是不可能对一个庞杂的子系统的各个细节了然于胸。当时我们为了节省时间我们对这项过程未花费太多时间与相关的系统模块负责人交流太多,初期我们进展很顺利迁移程序也顺利的开发完成,但后期当我们真正把项目拉到现场就没有非常顺利。
- **系统优化任务
这个任务的规模很小,在正常情况下是可以忽略的,之所以把它记录到工作总结,是因为在处理这个任务时因为个人过失确实影响到了公司形象,在此还得感谢王经理他们对我工作失误后的理解和鼓励。
错误的理解Oracle中事务的处理机制,在没有慎重的检查和测试改动后的处理逻辑的情况下,就把版本发布了,结果给系统的核心逻辑中加入了带有Bug的代码,直接导致出现严重的问题,系统无法正常使用。
总结经验
- 对Oracle基础知识点掌握的不牢固并自以为是没有进行大量的实践
- 祈祷/赌徒心理
- 在对事情未做好充分准备之前是不能盲目进行操作的。
- 即使客户那边给的压力再大也要保证改动的内容进行过测试和验证(就是因为压力大就更不要轻易做决定)。
不足之处和计划2013年
从2011-09-06入职已经在公司有一年多的时间,在这些时间里我的工作重心都算是技术方向,而忽略了业务知识的学习,虽然对基础性的业务有所掌握和了解,但在解决真实遇到的带有业务性质的问题时效率还是非常的低,所以计划在下一年能对N9系统业务的理解能上升一个层次。倾向于在2013年工作重心能够主要放在分析设计和对N9系统的设计开发方向。
至此,以上内容是个人2012年工作总结,谢谢我周围那些辛勤工作的同事,2012因为有他们,我工作的也很快乐。