2015年11月13日 正式回来结束了为期半年的工作生活。换了一个新的机房。,感觉跟在北京工作没什么两样,只是身边的人从同事变成了另一批。
半年的实习生活,遇到了一群一群同事,从陌生到熟悉,从严肃到嬉闹,从第一个组长第一个合作伙伴,从出差的“动荡不安”到动车组的朝九晚五;感觉自己遭了不少罪,同时也收获了不少五味杂陈。
入职第二周,完成了几个逻辑的内存方法编写,便被安排整组出差部署系统;整一个多两个月,沈阳-太原--酒店-服务器机房-火车站,三点一线。最终已肠胃炎--呕吐腹泻告终。
第二次面试入职,来到了动车组-技术管理部门;简单的交接,4天时间熟悉系统,便开始了关键配件寿命模块的编写,接下来收到的任务便大多都是数据脚本,系统小功能修改、优化。由于对动车业务流程不太熟悉,虽然是小功能修改,但大多都需要先看懂整个系统的代码流程;所以任务上而言,数据脚本基本上是1-2天完成,涉及代码编写的基本在2-5天不等。
由于有机会再两个组先后工作,评测中心的高铁项目,总体上属于中后期开发阶段,我赶上了一个横切的服务--内存的功能编写。之所以说它是横切,是因为在系统中属于横向提供服务的功能,在数据库与业务层再添加一层内存,临时存放24小时内常用数据,减少对DB的访问。
系统部署阶段,由于出差的人员就组长、另一个同事和我,人手还是相对较少;所以调试、改bug就处于一种,虽然不是你开发的,但是哪儿有错,也得当仁不让的干。那段时间基本处于一种每天看代码,改错,在固定的时间里尽可能多的完成任务;因为给沈阳铁路局做的系统,别人等着你的东西上线,所以相对还是比较紧张。
这种“项目还在后期开发却不远千里过来开始部署”的现象,我和同事也跟组长讨论过,因为有很多bug要改,系统还不成熟,同样的工作,一定要在一个16度/无网络状态实施么?效率低且工作时间很有限。交流的结果是“一是由于一些硬件开发环境下无法联调,二是用户等着使用,开发时间到期,用户不看着你开发,定期没有信息回馈,他也着急”;
组长也是干开发好十多年的老员工,像前期文档、需求方面使用的时间和编码的比例他肯定是心里有数的,什么原因导致项目bug不断还硬着头皮部署我们也没有多问。但结合咱自己开发项目,这样的现象应该不是少数。所以怎么合理安排项目进度,分配好时间,尤其是在项目较大的情况下,同时如何跟客户保持定期交流,及时反馈现状。这些是需要我们留意,培养的。
相对于高铁防灾系统,动车组这边就稳定老实的多,没有尝试什么新的技术框架,老老实实的三层,web service服务调用。不论项目技术上,还是员工工作环境,都稳定的多。
动车部位于铁科院电子所3楼,一整层楼组成了一个大组,两个主任一主内,一主外;整个动车部又细分为不同的项目组,分别负责铁路相关的不同项目;例如海滨在的高级修、志鹏在的物资和我在的技术管理组;每个组5--10人不等由一个组长负责ps.目测我们组长是里头最帅的。我们组负责好几个项目--动车履历(新造车上报)、同步平台、检修;我负责维护前两个,同时开发一个关键配件寿命管理模块。动车履历系统相对还是比较成熟了,但是同步平台还是让我花了不少心思。具体等实习总结会上再和大家分享。
两个项目组,高铁防灾使用到的新技术会相对多一些,例如WPF画界面,看着还是比较酷炫的;MQ数据传输中间件,WCF分布式服务调用;我主要负责写服务;动车这边同步平台挺值得研究,也使用了MQ传输数据,FTP文件协议,web service 服务,还有就是业务逻辑,因为动车大部分数据都需要通过同步平台传输,所以不同的数据用MQ自己内定的压缩、解压方法,形成了十多种数据不同的数据传输。
两个组,一个feel “有逗比的地方总是欢乐无限”。
两个组长性格上还是挺不同,以至于他们给组员分配任务、管理方式也稍有差异。第一个组张工比较健谈,我们酒店来来回回的路程,我就习惯老跟着他,聊东聊西;从四川美食到软件开发经验,都能说半天。。。。他也很培养我和另外一个同事,因为我俩都很年轻,平时很多东西不懂的,也比较耐心的给我们解释,技术上、管理上的经验也愿意分享。跟他聊天有种眼界被打开的开阔感。总体上跟高铁一个大组的同事相处都很愉快,每天也比较欢乐。
动车组就不太一样了,因为这里有一只奇葩。动车的组长郭居--就无言得多了,平时除了聊点儿子、车子、房子。技术上、项目开发上比较少涉及。这也跟动车组相对稳定的外在条件有关。
In a word,收获不少,继续向前!