2011年就要过去了，这一年，我从学校毕业，走上工作岗位，成为了一名程序员。在w公司工作的半年时间里，参与过项目开发，经历了岗位调动(由开发转为维护)。经过这段时间的工作，逐渐地对w公司开发人员和维护人员的工作和生活状况有了认识，相比刚走出校园的自己，心态也发生了一些变化。在此记录下2011年我工作后经历的点滴，与大家分享。
开发：狂奔的蜗牛
进入w公司后，第一个参与的项目是U项目，U项目是融合通信相关的，基于已有的业务代码作二次开发，功能包括即时消息、IM会议、宽窄带电话等。
原有的业务代码，结构混乱、冗余代码多、模块交互过程繁杂、历史悠久。很多源码文件代码行数过万，某个.c文件有4万多行代码，其中一个函数有将近3k代码，代码调用层次最深的达到10多层。在这份号称过百万行的代码里，2007年产的那叫陈酿，2000年产的那叫国窖经典，甚至有人发现80年代的代码，那叫一个“代码恒久远，一码永流传”。
一位老员工对我说：少年，你若能把这份代码看懂，以后看其他代码，那都是浮云！但他不知道，从看到这份代码起很长一段时间，我见到老同学，都是这样一副表情：
原有代码的恶臭，加上通信流程的理解门槛，新员工很难在新项目开发中担任主力。项目时间紧，业务需求不断变动，更加大了开发的难度和老员工的负担。尽管采用了“流行”的敏捷开发流程，但更多地是赶工期的敏捷、加班的敏捷。像过去一样，依赖"人多力量大"，新老员工合力扛过了U项目这“一大波僵尸"，但这之后，从人员技能、代码优化方面，是否应该考虑进行装备升级呢？
个人工作
吐槽过后，来讲讲我在U项目中的工作。在U项目中我负责F模块部分功能的开发：
- 消息跟踪功能：显示模块中部分变量的值，展现程序的调用过程与返回结果
- 防止内存泄漏功能：检测模块调用者，在调用者失效时释放其申请的内存块
另外，参与了与F模块相关的单元测试、性能测试。在编码过程中，了解了代码静态检查、圈复杂度检查等概念以及相关工具的使用方法；在单元测试过程中，学习了gtest单元测试框架的使用方法。
维护：笨拙的侦探
U项目就要进入交付期的时候，我被告知要调到另一个项目组的维护组。
是的！当时听到这个消息就震惊了！俺可是立志从事软件开发的娃啊！维护是做神马的？！人家一点思想准备都没有啊！！！
说说维护
调换部门后，经过一个月的摸索，渐渐了解了维护工作内容。我所在的小组负责平台的维护工作，这里的“平台”涵盖硬件(CPU、内存、磁盘、网卡等)、存储设备、操作系统和中间件软件，那工作内容又包括哪些呢？包括改进完善维护工具、实施保障与问题处理。问题处理是指在上层业务出现异常或中断的时候，通过查看各种日志，排查故障原因(平台相关的)并协助恢复业务，问题处理是维护工作任务中的主要一项。
困境
平台支撑各种产品的业务，使用中的设备数量多，基数大，问题出现的概率就大。每个维护人员常常同时处理几个问题，加上夜间保障与支持，维护人员更是感到身心疲惫。分析维护工作困难重重的原因，我认为有以下几点：
1.人才缺失
最根本的原因还在于人。维护工作涉及计算机的各个方面：硬件、存储设备、操作系统(Linux)、网络、中间件软件(双机软件、数据库等)，维护人员要求了解以上各个方面知识，但现状是，对于以上每个方面，组内并没有专研得深、研究得透的人。
正因为缺乏专业知识，在分析问题原因的时候，维护人员更多是根据经验库，与问题现象作匹配。也就是说，维护人员能处理的问题，大多是过去发生过的、已知原因的、相对浅显的问题。面对需要从“深层次”寻找原因的问题(例如通过分析内核代码，排查内核bug)，我们往往无计可施。
2.跨部门合作的瓶颈
作为基础平台的维护人员，需要与业务人员、服务热线人员和业务实施人员合作，共同处理、解决问题。各类人员分属不同部门，问题的严重程度、是否处理得当，涉及到各个部门及个人的利益。当问题严重程度高、问题出现原因不明晰的时候，经常出现相关人员相互推诿、都不愿担责的情况。
在开展工作的时候，各方人员很少能抱以精诚合作的态度，反而是将工作压力层层转嫁。业务实施人员向业务维护人员施压，业务维护人员向平台维护人员施压。这造成w公司内维护人员工作压力、劳动强度大，但工作成果反而不被认可的现象。
尽管维护工作面临很多困难，但与U项目类开发工作相比较，个人更愿意选择维护工作。原来项目开发的工作，更多地要求熟悉业务通信流程和原有的代码，对个人编程技能提升鲜有帮助；相比之下，做平台维护方面的工作，有机会深入学习操作系统、 Linux内核、存储、网络等方面的知识。经过一段时间的维护工作，我心态上也从抗拒，逐渐变成适应与接受。作为初入IT行业的工作者，多尝试，多积累不同 产品的开发经验、不同岗位的工作经历，相信有助于自身的成长和发展。
出来混，始终是要还的
“出来混，始终是要还的”，工作后接触的人、发生的事让我深深体会到这一点。当前的工作和生活态度，决定了我们将来的生活状态。只有拿出积极的态度，才可能获得好的结果。
很多程序员工作任务重，加班是家常便饭，容易忽略技术的积累，技能不能提升，久而久之，就变成流水线上的工人。为了避免(或改变)这种情况，我们可以放眼未来，为自己设定一个中期目标(比如两年后某某技术我要达到什么层次/两年后我要跳到某某公司)，再根据设定的目标，作相应的技术积累。
另一方面，一些刚参加工作的程序员同学，过于寄望未知的未来。当他们对公司或工作稍有不满的时候，解决的方法直接了当：跳槽。没错，IT热潮下再找一份工作并不难，但这并不是解决问题的根本途径。在跳槽想法萌生的时候，请考虑这些问题：我是否胜任当前工作？与当前工作相关的知识我是否都理解？从当前工作中我是否已经学不到更多的东西了？我是否达到心仪工作的技能要求？如果以上问题的答案都是“否"，那请暂时放弃跳槽的打算，将当前工作相关的知识学好，把底子打扎实。
为避免成为以上两种人，我经常问自己：
- 今天要学习哪些知识？昨天掌握了哪些知识？真正掌握了吗？
- 两年后我要在哪里？要做什么事情？现在的自己是在往这个方向前进吗？
这是我激励自己的方法，相信你也有你自己的方法。
最后，祝大家在2012年过得更有意义、更加精彩。
