我的职场生涯（九）这两年工作总结_职业发展

您所在的位置：程序员俱乐部 > 非技术区 > 职业发展 > 我的职场生涯（九）这两年工作总结

我的职场生涯（九）这两年工作总结

2011/1/4 7:51:38 snowolf http://snowolf.javaeye.com 我要评论(0)

摘要：在2010年的最后一个月里，我终于告别了为期两年的煎熬。两年前，当我满怀欣喜的跳到一家公司后，迎接我的是为期两周的紧急短任务，这就是对新入职员工最好的历练。这个任务其实听起来很简单，赶在移动终止wap计费接口前，争取一笔年前的wap计费收入，换言之——更改计费接口。这个任务其实对于一般工作了3年左右的人来说都是小菜了，但当我真正开始看代码的时候，我傻眼了——这代码还不如我大学时代写的漂亮呢！一个类中就一个方法，一个方法上千行，一个方法中一个数据库连接跨越多个数据库操作。且不说代码行数吓人
标签：总结工作总结工作职场

在2010年的最后一个月里，我终于告别了为期两年的煎熬。

两年前，当我满怀欣喜的跳到一家公司后，迎接我的是为期两周的紧急短任务，这就是对新入职员工最好的历练。

这个任务其实听起来很简单，赶在移动终止wap计费接口前，争取一笔年前的wap计费收入，换言之——更改计费接口。这个任务其实对于一般工作了3年左右的人来说都是小菜了，但当我真正开始看代码的时候，我傻眼了——这代码还不如我大学时代写的漂亮呢！一个类中就一个方法，一个方法上千行，一个方法中一个数据库连接跨越多个数据库操作。且不说代码行数吓人，就是这个数据库操作就让人无比无奈——对于一个要更新的数据，先查询，然后更新；删除数据也一样，先查询是否存在，然后再考虑更新……诸如此类的操作数不胜数，数据库检索永远只有按照“唯一”规则取出来非唯一的数据，然后按照优先级，取得第一条数据。我在看过千余行此类型的代码后，顿时有种无以言状的痛，这个词叫崩溃！

拿到新的计费接口包后，就开始对代码开始全面改造。按照习惯理解，计费操作应该封死在一个业务模块中，但其实不然。这里，网络层调用数据库层，业务层调用网络层，偶尔也完成数据库层操作，域对象还会自己调用业务层，或者数据库层初始化自身数据。说白了就是想起来什么，就在哪用什么，完全没有章法。于是乎，调整计费接口需要我这样的“大拿”级人物来处理。对每个原有计费接口方法调用处都做“TODO”标识，然后记录文档（对代码不熟悉，以免出现新问题）。接着，建立独立的计费业务实现类，对外提供接口，包装第三方计费接口实现。经过18个小时的奋战，完成全部方法的调整。看看表，凌晨4点钟，回想来公司的时间，昨日上午10点。回到家里，一觉睡到8点，头痛欲裂，这就是我的周末礼物！事后，听到一位“博士”曾经这样评价加班一词，曰：“不加班的员工就不是好员工！”

看着这样的学生级别的代码，我真的很有心把它全部重构，我认为一个有如此之大用户量的公司，不会让自己的项目有这样或者那样的漏洞。但是，我错了。所有的民企都要面对一个问题——生存问题！大家都在拼命赶在政策变化前，拼命捞钱，避免被兄弟公司吞掉，或者被挤垮！在完成这个任务后，当我想要奋力重构代码时，我被安排到其他任务上，再然后，有如此，再然后，更如此。终于，有一天我找到了一个词形容自己，我就是一个空降兵。什么都能做，什么地方都是我的战场，神马都是浮云！

2008年底就这样告别了，在熬夜改代码的日子里，在全公司集体加班到10点都是常事的日夜里。

虽然，现在是2010年末，但我却很难想起来2009年一年，我都做了什么。在乏味的肉眼和代码中，在不断的跟各个部门项目干系人沟通的口水中。似乎我什么也没有留下来，没有沉淀什么东西。

也许，你不能想象，用肉眼人工识别代码差异是个什么工作！但是当时的DM就这么要求我，甚至是每一个人。我们的工作最主要的一项就是“合代码”。要合并即将上线的新功能到线上代码；要在线上代码基础上，修正刚刚爆发的bug，零时再合并需要同期上线的功能。肉眼识别，在svn的环境下，我们还被要求肉眼识别。多年之后，我终于完全退化了svn合并代码的能力。

除此之外，每当我打开log4j的配置文件，就仿佛看到了天书一般。数千行log4j的配置，让人难以下咽。修改一个小地方，就得所有人跟着动！因此，所有员工入职的第一件事情就是学习“log4j标准”，那种明显存在代码理解误区的自定义标准！

在这样一个环境中，很多新技术难以施展，很多历史问题总要上演。数据库主键自增由触发器控制，表与表之间缺乏主外键关联，字符集非要以GBK为主！一切表征，只能说明，这些技术起点，源于学生时代，并几乎止步不前了。说到这点，我不得不提，曾经有个项目多表之间以用户名字段做表关联，而用户名本身是不唯一的，当我检索一条数据时，竟然花费了550ms，当我强制用户名唯一后，检索只需要5ms。这简直不是一个数量级，但这就发生在我周围！

在这样一个环境下，该做点什么？我的技术热情无处施展，技术的止步就等同于倒退！该做点什么？该做什么？于是，我把我的技术全部整理在博客中，于是乎，意外出书。也许2009年，对于我工作上没有什么记忆，因为出书的热情完全对冲了工作上的不悦，让我感到平衡。唯一让我印象深刻的是有这么一个人，在我高烧三天在家整理对外接口的时候，无视我的邮件，将一个接口发给合作方，但当我回到公司后，问我的第一句话却是工作如何如何安排，进度等等。用这位仁兄的经典台词就是：“人人都是CPU，你必须让你的人时刻保持满负荷”。很可惜，我是个人，还不到机器的份！不是有句名言吗？“把女人到男人用，把男人当牲口用，把牲口当机器用！”我想，这哥们的觉悟不是一般的高！

那些冲突的日子里，我几乎无法入眠，左侧卧入睡，就一定会半夜心悸醒来。每天看到这个人，就感到鸭梨很大，而且无法消化！

终于，有一天，这哥们想到了降薪降级的办法让我走。而我，最终还是抱有希望的留了下来。

调整部门后，我以为可以做点实在的事情。当我要修改一个控制器，部署上线时，我问我的Lader，Controller写到哪里。Lader说，什么是Controller？（控制器就是Controller）当时我就心凉了！难道我又进火坑了？这么基础的名词，居然不知道？！2010年，就以这样一个开场白展开了。

接下来的工作超级有规律，每三个月交接一次工作。每个季度我都要把交接工作写进季度考核中。有时候，我只能苦笑，“哥们同志是块砖，哪里需要哪里搬！”我被定为“擦屁股大拿”！渐渐的，我还是沉迷了，颓废了，基本上消失在同事的视野里，似乎我基本上不存在了。

在历尽许多自诩牛人的项目后，我感到毫无收获，于是，我黯然离去。
其实，当初我面试入职的时候，我依然了解这公司的技术起点。由一个面试问题可以窥探其结论。

面试官：“对比Spring的JDBCTemplete跟Hibernate和iBatis的实现，各有哪些优势？”
我简言之：“Spring的实现么有缓存，而Hibernate跟iBatis这一点上完全胜出！”
面试官：“这个完全可以通过继承EhCache的代码来实现嘛！”
听完这句话，我就想到了，这个公司的技术起点还停留在对象继承阶段，还停留在代码开发，而非配置级。这种东西，即便是Spring，也可以通过依赖注入，减少代码开发，直接使用其接口，达到其目的的！
于是，我反问：“能够通过配置级完成相应实现，我们何必要重复值早轮子呢？”

过去的，已经过去了。当我想要尝试通过Java，依托Spring框架面对各种挑战的时候，突然间，我发现很多东西我还没有来得及研究，更别说去运用。我已经没有机会去尝试了！
我曾经有着明显的代码洁癖，可以理解为偏执人格障碍。但今天，我明白了：“技术终究只是工具。工具不是艺术品，工具终究为解决问题而生，为满足用户需求而存在。”如果忽略了技术以人为本的定义，也就失去真正的意义。站在新的角度，就需要考虑新的问题，也就难免需要放弃一些固有熟悉的工具。

写在2010年的最后的一周里，对比两年前，如今的我依然鸭梨巨大，却感到了很多的快乐！人生不是骇客帝国，我不想成为那个该死的电池，被当作CPU来使用，我更想主宰我自己！