1.
做维护开发工程师大概有一年的时间了，起初还能学到一些新东西，但时间长了，有些厌倦了。
总感觉是在吃别人嚼过的东西，就算把嚼过的东西整理的再好，吃到嘴里感觉还是很恶心。
除了恶心还很苦逼，维护的是一线生产系统，不容有半点闪失。
有时后半夜系统出问题了，接到现场电话，要马上起来，抖擞精神抓bug,没办法现场一群人等着呢，你要是不弄，明天可能就是一个大问题。
所以很长时间我的睡眠都不好，总睡不踏实，总觉得晚上可能有事。
好不容易过个周末，正玩的很爽，现场电话来了，看到电话立马蔫了，这个时候真有把电话摔了的冲动，连个周末都不让老子过安生。
从此之后我落下了周末接电话恐惧症的毛病。周末一有电话响，心脏立马开始剧烈跳动。
这是坑爹It生涯的第一步，做一个勤勤恳恳的维护发工程师，虽然苦，而且似乎也很难做出耀眼的成绩，但天道酬勤，你的努力不会白费，你走的每一步都算数，当机会来的时候，你准备好了，别人也刚好能在门口看到你。
2.
我们的老系统要重构了，W女士做项目经理，她钦点你做这个项目的开发负责人，Ben亲自跟我说。
一下子我从一个维护开发工程师，摇身一变成了开发负责人，而且这个项目要配备5个开发工程师，由我来统一管理。
我当时压力还是非常大，因为第一次成为开发负责人。
当时我专门找了W女士，有那么多有经验的开发经理，为什么选择我？
W女士告诉我，你对老系统非常了解。让你来负责设计风险小，更重要的她看重我这个人。
半年前我曾经负责维护老系统和她负责的项目有系统接口，当时我作为新人把接口的开发及配合联调工作做得很到位，而且工作负责，加班加点，他看到了的我的职业态度和专业能力。相信我的潜力，所以宁愿冒一定风险让我来做。
所以工作中要时刻保持专业的态度，不管是你的领导，同事还是合作伙伴，你的作为，他们会看到，不知道下一个机会来自谁那里。
3.
进了这个新项目组，我成了不折不扣的多面手，也就是传说中的万能程序员。
系统要重构的主要原因是，公司在管理上开始学习台湾某个大型集团的管理模式。
从台湾那边挖了很多专家过来，据说都是年薪百万的业务专家。
所以第一步就是要和台湾专家一起写管理制度，制度的编写要结合我们公司的实际情况，也不能一下步子迈得太大。
我们作为信息化部门代表参加，主要是为了吃透业务，编制软件需求。
我第一个角色就是需求，那是听他们讲管理，讲流程，总会脑子里一下就映射到系统怎么设计，很多时候想不清楚。
后来做了专业的需求才明白，其实是少了一层需求分析。
管理制度只是用户需求，还需要经过需求分析转化成业务需求和软件需求，这样就化复杂为简单了。
其实工作中做很多事都是类似，一个复杂的问题摆在面前，我们要做的是就是确定目标，分解任务步骤，提出问题清单，把这三方面做好，很多复杂问题就会迎刃而解。
需求发布了，我还要负责总体系统设计，虽然以前在做系统维护时，也做过部分模块的重构设计，但整个一个系统的设计还是第一次。
这时候Ben帮了很大的忙，让我能抓住要点，最关键的设计就是要做数据模型设计（也就是数据建模）和应用模型设计（就是应用层的服务设计）。
数据模型设计要考虑三个范式，尽量不在数据库层面做存储过程和触发器，耦合性太高，不方便维护和移植，除非在应用层无法解决效率问题才会迫不得已在数据层完成。
现在那么多并行计算工具，基本上通过应用层和还有内存数据库，都能在应用层通过内存数据解决效率问题。
应用服务设计要适当采用一些设计模式，让底层设计的可维护性，扩展性更好。
当时我记得运用了工厂模式，策略模式，设计出来的服务非常清晰，实用。
另外除了类图设计，我认为比较重要的两个图应该在设计中提现。
一个是活动图，他能把程序的执行步骤描述清楚。另一个是状态迁移图，明确数据实体的状态变化。
作为开发负责人还要负责排计划，更要命的是，这个项目只给了一个月的开发周期。
为了赶工我不但要负责开发管理，开发指导，还要自己负责部分功能的开发。
那段日子很苦，真是传说中的7*24，没有半点喘息时间。
为了提升开发进度，除了采用赶工的方式，我们才用了快速迭代的方式，设计和开发并行，开发和测试并行，小版本迭代，终于一个月左右的时间系统能跑起来了，一个全新的系统，生机勃勃。
系统当然也是我负责发布的，谁让我是万能的程序员呢！
我们之所以能快速的完成开发任务，和我们采用强矩阵的管理模式分不开，大家不用扯皮，沟通高效，问题不会拖，基本都是当天解决，这样的团队一定是个战无不胜的团队。
今天这篇文章用手机，在机场写的，感觉也还挺高效的，以后多尝试采用这种方式，还是挺棒的。
今天先写到这吧，改天继续。
