Osheep

时光不回头,当下最重要。

坑爹的项目—我就是那个全能的程序员

《坑爹的项目—我就是那个全能的程序员》

我是全能

1.

做维护开发工程师大概有一年的时间了,起初还能学到一些新东西,但时间长了,有些厌倦了。

总感觉是在吃别人嚼过的东西,就算把嚼过的东西整理的再好,吃到嘴里感觉还是很恶心。

除了恶心还很苦逼,维护的是一线生产系统,不容有半点闪失。

有时后半夜系统出问题了,接到现场电话,要马上起来,抖擞精神抓bug,没办法现场一群人等着呢,你要是不弄,明天可能就是一个大问题。

所以很长时间我的睡眠都不好,总睡不踏实,总觉得晚上可能有事。

好不容易过个周末,正玩的很爽,现场电话来了,看到电话立马蔫了,这个时候真有把电话摔了的冲动,连个周末都不让老子过安生。

从此之后我落下了周末接电话恐惧症的毛病。周末一有电话响,心脏立马开始剧烈跳动。

这是坑爹It生涯的第一步,做一个勤勤恳恳的维护发工程师,虽然苦,而且似乎也很难做出耀眼的成绩,但天道酬勤,你的努力不会白费,你走的每一步都算数,当机会来的时候,你准备好了,别人也刚好能在门口看到你。

2.

我们的老系统要重构了,W女士做项目经理,她钦点你做这个项目的开发负责人,Ben亲自跟我说。

一下子我从一个维护开发工程师,摇身一变成了开发负责人,而且这个项目要配备5个开发工程师,由我来统一管理。

我当时压力还是非常大,因为第一次成为开发负责人。

当时我专门找了W女士,有那么多有经验的开发经理,为什么选择我?

W女士告诉我,你对老系统非常了解。让你来负责设计风险小,更重要的她看重我这个人。

半年前我曾经负责维护老系统和她负责的项目有系统接口,当时我作为新人把接口的开发及配合联调工作做得很到位,而且工作负责,加班加点,他看到了的我的职业态度和专业能力。相信我的潜力,所以宁愿冒一定风险让我来做。

所以工作中要时刻保持专业的态度,不管是你的领导,同事还是合作伙伴,你的作为,他们会看到,不知道下一个机会来自谁那里

3.

进了这个新项目组,我成了不折不扣的多面手,也就是传说中的万能程序员。

系统要重构的主要原因是,公司在管理上开始学习台湾某个大型集团的管理模式。

从台湾那边挖了很多专家过来,据说都是年薪百万的业务专家。

所以第一步就是要和台湾专家一起写管理制度,制度的编写要结合我们公司的实际情况,也不能一下步子迈得太大。

我们作为信息化部门代表参加,主要是为了吃透业务,编制软件需求。

我第一个角色就是需求,那是听他们讲管理,讲流程,总会脑子里一下就映射到系统怎么设计,很多时候想不清楚。

后来做了专业的需求才明白,其实是少了一层需求分析。

管理制度只是用户需求,还需要经过需求分析转化成业务需求和软件需求,这样就化复杂为简单了。

其实工作中做很多事都是类似,一个复杂的问题摆在面前,我们要做的是就是确定目标,分解任务步骤,提出问题清单,把这三方面做好,很多复杂问题就会迎刃而解。

需求发布了,我还要负责总体系统设计,虽然以前在做系统维护时,也做过部分模块的重构设计,但整个一个系统的设计还是第一次。

这时候Ben帮了很大的忙,让我能抓住要点,最关键的设计就是要做数据模型设计(也就是数据建模)和应用模型设计(就是应用层的服务设计)。

数据模型设计要考虑三个范式,尽量不在数据库层面做存储过程和触发器,耦合性太高,不方便维护和移植,除非在应用层无法解决效率问题才会迫不得已在数据层完成。

现在那么多并行计算工具,基本上通过应用层和还有内存数据库,都能在应用层通过内存数据解决效率问题。

应用服务设计要适当采用一些设计模式,让底层设计的可维护性,扩展性更好。

当时我记得运用了工厂模式,策略模式,设计出来的服务非常清晰,实用。

另外除了类图设计,我认为比较重要的两个图应该在设计中提现。

一个是活动图,他能把程序的执行步骤描述清楚。另一个是状态迁移图,明确数据实体的状态变化。

作为开发负责人还要负责排计划,更要命的是,这个项目只给了一个月的开发周期。

为了赶工我不但要负责开发管理,开发指导,还要自己负责部分功能的开发。

那段日子很苦,真是传说中的7*24,没有半点喘息时间。

为了提升开发进度,除了采用赶工的方式,我们才用了快速迭代的方式,设计和开发并行,开发和测试并行,小版本迭代,终于一个月左右的时间系统能跑起来了,一个全新的系统,生机勃勃。

系统当然也是我负责发布的,谁让我是万能的程序员呢!

我们之所以能快速的完成开发任务,和我们采用强矩阵的管理模式分不开,大家不用扯皮,沟通高效,问题不会拖,基本都是当天解决,这样的团队一定是个战无不胜的团队。


今天这篇文章用手机,在机场写的,感觉也还挺高效的,以后多尝试采用这种方式,还是挺棒的。

今天先写到这吧,改天继续。

点赞