乌龙记

 

过去两个月一直都在忙一个Feature(我们公司把一个大项目分解成很多小功能,每个小功能叫做一个Feature),这也是我工作以来真正意义上的第一个Feature,总体而言,累并快乐着。 

 

公司是电信设备商,我去年7月一进公司就听说了并且逐渐感受到了公司产品的复杂——既有历史的客观原因,也有人为的主观因素。通过做这个feature,才真正体会到了什么叫“浩如烟海”,哪个是“沧海一粟”。其实一开始在另外一个Team,等到快要真正开始做项目时又被转到了现在的team。现在做的是公司无线产品的仿真软件,已经由美国人做了十几年了,去年开始将一部分功能转移到中国做,而我就成了中国新组建的这个Team的一员。

 

尽管公司已有百余年的历史,而且奠定了现在通用的好多计算机/通信技术,但公司的传统却是身教重于言传,言传胜过文档,而文档却又七零八落。美国的同事给我们培训的时候我们问的最多的就是“文档在哪里”,而美国的同事回答最多就是“Reading the code”。尽管公司现在已今非昔比,但公司里其实还是有很多牛人的,通过看code就知道,因为我经常看不懂。

 

产品的code只是很小的一个方面,作为一个电信厂商,有很多更重要的东西需要Care,销售、管理、运营等我不熟悉的方面我就不谈了(因为无话可谈),但就软件而言(硬件我也不太懂),系统架构、代码管理、配置工具等等缺一不可。而这些东西在工作中又时常用到,人多手杂,天长日久也难免会出各种各样的问题。

 

第一次做feature,最难的不是实现feature,而是熟悉一大套工具和流程。即便是feature本身也大多不是非常有创意或技术含量的东西,本应是对现有产品的尽可能的仿真却由于各种原因蜕变成了现实与模拟的妥协,而我们要做的事就是在各种铜墙铁壁中找出一条夹缝,然后在夹缝中求生存。做产品的仿真软件,有时要截弯取直,有时又不得不曲径通幽,变化之间,奇妙无穷。

 

由于是公司内部用的仿真软件,因此不像电信产品那样要求稳定性、可靠性,只要能用来做测试就行了。一旦出了问题,重启一下软件继续。但是也正因为质量上要求不高,问题也是非常的多,每天都有很多用户发邮件找我们解决问题。同时我们又得不断开发新的feature以支持产品测试,每个人的压力还是很大的。我们刚接手,一个人也就当半个人用,可美国的那些同事,最少的也已经做了十年了,在经历了身边同事不断被裁掉的劫波之后,肩上的担子也越来越重。忙中也就难免会出错。

 

前两天我在测试自己的Feature时,发现了一个问题,就是将产品中代码和我们自己代码build出来Product在用的时候一直出问题。看log并且反复测试了一天最后终于发现了问题的所在:产品中改了一个struct的定义,增加了一个成员,而我们的代码中没有做相应更改。于是就把我的发现发邮件告诉了美国的Mentor。晚上在家里加班时,美国的mentor在MOC(Microsoft Office Communicator,一款企业IM软件,说实话做的非常一般)上问我具体情况,我告诉了他我的判断。他起初很怀疑我的判断,我就演示给他看,他终于承认了这个问题的存在,但还是试图找出一种他更愿意接受的原因。用了两个小时,最终证明确实不是我们的问题,而是产品team造成的。Mentor查看了那个文件修改的历史,发现了一个不是我们team的人改了那个文件,于是告诉我可以问问那个人是否改过源文件。那天晚上我睡觉时已经凌晨3:50了。第二天白天我给那个人发了一封邮件,可是始终没有得到回复。

 

第二天晚上,美国的Mentor和我查找产品team的负责人,由于公司team太多,每个team相对独立,很是费了一番力气。找到以后,mentor告诉我可以联系那个负责人。因为已经很晚了,于是我说我明天给他发邮件,可是mentor说他可以帮我立刻发邮件确认一下。由于那个产品也是由美国人负责,很快邮件得到恢复,说那人已经不再负责那个产品了,让我们联系另外一个人。我们有联系了另外一个人,那个人说他是manager,具体技术问题联系他的一个手下的员工。Mentor在MOC上加了那个产品的owner,由于之前有默契,Mentor和我组团忽悠产品owner,希望他们能调整一下那个struct新加入成员的顺序,把它加到最后,那样对我们的影响是最小的。尽管我们很卖力的忽悠,但人家认定现在已经不好改了,而且我们仿真软件就应该服务于产品,不能本末倒置,无果。于是mentor让我着手改我们的代码,而且越快解决越好。那天晚上睡觉时意识凌晨4:00多。

 

第三天白天下午我才去上班,上午在睡觉。刚到公司就有一个人给我打电话,问我关于那个struct的问题。原来那人已经再上一个release对我们的代码做了private的更改,上一个release的更改已经提交,只是这个release的还没有提交,要等到产品的代码提交后才可以。可是现在产品已经提交了,他们却并不知道,只能等到下一个load在提交了。难怪一个月以来没有用户反应这个问题,而在最新的release中我却碰到了问题呢。形势豁然开朗,终于不用我们再负责这个问题了。立马发邮件给mentor,告诉他这个好消息。

 

晚上mentor回复我的邮件,深表欣慰。他说那人提交代码的时候应该找我们team的人作为inspector,他找了吗?我回复说应该没有,不然我们应该会知道更改的。没想到mentor很快又发邮件给我说他想起来了,那个人确实找我们team做inspect了,那个inspector就是他——我的mentor!我顿时无语,只好给他恢复了“OMG!^_^”。

 

这种骑驴找驴的乌龙事件尽管耽误了我们不少时间,但想想也很有意思,因此尽管已经很晚了,我还是坚持把它记下来(其实我的生物钟已经和格林威治时间同步了,再修炼一段时间估计去美国就不用倒时差了^_^)。