代码改变世界

回顾2011——一个程序员工作半年后的自白

2011-12-30 22:36  bangerlee  阅读(11345)  评论(29编辑  收藏  举报

2011年就要过去了,这一年,我从学校毕业,走上工作岗位,成为了一名程序员。在w公司工作的半年时间里,参与过项目开发,经历了岗位调动(由开发转为维护)。经过这段时间的工作,逐渐地对w公司开发人员和维护人员的工作和生活状况有了认识,相比刚走出校园的自己,心态也发生了一些变化。在此记录下2011年我工作后经历的点滴,与大家分享。

2011

 

开发:狂奔的蜗牛

进入w公司后,第一个参与的项目是U项目,U项目是融合通信相关的,基于已有的业务代码作二次开发,功能包括即时消息、IM会议、宽窄带电话等。

 

原有的业务代码,结构混乱、冗余代码多、模块交互过程繁杂、历史悠久。很多源码文件代码行数过万,某个.c文件有4万多行代码,其中一个函数有将近3k代码,代码调用层次最深的达到10多层。在这份号称过百万行的代码里,2007年产的那叫陈酿,2000年产的那叫国窖经典,甚至有人发现80年代的代码,那叫一个“代码恒久远,一码永流传”。

 

一位老员工对我说:少年,你若能把这份代码看懂,以后看其他代码,那都是浮云!但他不知道,从看到这份代码起很长一段时间,我见到老同学,都是这样一副表情:

哭!

 

原有代码的恶臭,加上通信流程的理解门槛,新员工很难在新项目开发中担任主力。项目时间紧,业务需求不断变动,更加大了开发的难度和老员工的负担。尽管采用了“流行”的敏捷开发流程,但更多地是赶工期的敏捷、加班的敏捷。像过去一样,依赖"人多力量大",新老员工合力扛过了U项目这“一大波僵尸",但这之后,从人员技能、代码优化方面,是否应该考虑进行装备升级呢?

 

个人工作

吐槽过后,来讲讲我在U项目中的工作。在U项目中我负责F模块部分功能的开发:

  1. 消息跟踪功能:显示模块中部分变量的值,展现程序的调用过程与返回结果
  2. 防止内存泄漏功能:检测模块调用者,在调用者失效时释放其申请的内存块

另外,参与了与F模块相关的单元测试、性能测试。在编码过程中,了解了代码静态检查圈复杂度检查等概念以及相关工具的使用方法;在单元测试过程中,学习了gtest单元测试框架的使用方法。

 

维护:笨拙的侦探

U项目就要进入交付期的时候,我被告知要调到另一个项目组的维护组。

震惊

是的!当时听到这个消息就震惊了!俺可是立志从事软件开发的娃啊!维护是做神马的?!人家一点思想准备都没有啊!!!

 

说说维护

调换部门后,经过一个月的摸索,渐渐了解了维护工作内容。我所在的小组负责平台的维护工作,这里的“平台”涵盖硬件(CPU、内存、磁盘、网卡等)、存储设备、操作系统和中间件软件,那工作内容又包括哪些呢?包括改进完善维护工具、实施保障与问题处理。问题处理是指在上层业务出现异常或中断的时候,通过查看各种日志,排查故障原因(平台相关的)并协助恢复业务,问题处理是维护工作任务中的主要一项。

 

困境

平台支撑各种产品的业务,使用中的设备数量多,基数大,问题出现的概率就大。每个维护人员常常同时处理几个问题,加上夜间保障与支持,维护人员更是感到身心疲惫。分析维护工作困难重重的原因,我认为有以下几点:

1.人才缺失

最根本的原因还在于人。维护工作涉及计算机的各个方面:硬件、存储设备、操作系统(Linux)、网络、中间件软件(双机软件、数据库等),维护人员要求了解以上各个方面知识,但现状是,对于以上每个方面,组内并没有专研得深、研究得透的人。

正因为缺乏专业知识,在分析问题原因的时候,维护人员更多是根据经验库,与问题现象作匹配。也就是说,维护人员能处理的问题,大多是过去发生过的、已知原因的、相对浅显的问题。面对需要从“深层次”寻找原因的问题(例如通过分析内核代码,排查内核bug),我们往往无计可施。

笨拙的侦探

 

2.跨部门合作的瓶颈

作为基础平台的维护人员,需要与业务人员、服务热线人员和业务实施人员合作,共同处理、解决问题。各类人员分属不同部门,问题的严重程度、是否处理得当,涉及到各个部门及个人的利益。当问题严重程度高、问题出现原因不明晰的时候,经常出现相关人员相互推诿、都不愿担责的情况。

在开展工作的时候,各方人员很少能抱以精诚合作的态度,反而是将工作压力层层转嫁。业务实施人员向业务维护人员施压,业务维护人员向平台维护人员施压。这造成w公司内维护人员工作压力、劳动强度大,但工作成果反而不被认可的现象。

 

尽管维护工作面临很多困难,但与U项目类开发工作相比较,个人更愿意选择维护工作。原来项目开发的工作,更多地要求熟悉业务通信流程和原有的代码,对个人编程技能提升鲜有帮助;相比之下,做平台维护方面的工作,有机会深入学习操作系统、 Linux内核、存储、网络等方面的知识。经过一段时间的维护工作,我心态上也从抗拒,逐渐变成适应与接受。作为初入IT行业的工作者,多尝试,多积累不同 产品的开发经验、不同岗位的工作经历,相信有助于自身的成长和发展。

 

出来混,始终是要还的

“出来混,始终是要还的”,工作后接触的人、发生的事让我深深体会到这一点。当前的工作和生活态度,决定了我们将来的生活状态。只有拿出积极的态度,才可能获得好的结果。

坚毅

 

很多程序员工作任务重,加班是家常便饭,容易忽略技术的积累,技能不能提升,久而久之,就变成流水线上的工人。为了避免(或改变)这种情况,我们可以放眼未来,为自己设定一个中期目标(比如两年后某某技术我要达到什么层次/两年后我要跳到某某公司),再根据设定的目标,作相应的技术积累。

 

另一方面,一些刚参加工作的程序员同学,过于寄望未知的未来。当他们对公司或工作稍有不满的时候,解决的方法直接了当:跳槽。没错,IT热潮下再找一份工作并不难,但这并不是解决问题的根本途径。在跳槽想法萌生的时候,请考虑这些问题:我是否胜任当前工作?与当前工作相关的知识我是否都理解?从当前工作中我是否已经学不到更多的东西了?我是否达到心仪工作的技能要求?如果以上问题的答案都是“否",那请暂时放弃跳槽的打算,将当前工作相关的知识学好,把底子打扎实。

 

为避免成为以上两种人,我经常问自己:

  1. 今天要学习哪些知识?昨天掌握了哪些知识?真正掌握了吗?
  2. 两年后我要在哪里?要做什么事情?现在的自己是在往这个方向前进吗?

这是我激励自己的方法,相信你也有你自己的方法。

 

最后,祝大家在2012年过得更有意义、更加精彩。