程序员成长日记-(2)会议与bug

2008.4.4. Monday
今天周一，上周四我就开始运行的导航数据转换已经完毕了，用时2天，采用新的dell工作站确实在效率上很不一样，我启动了数据合并处理，没想到在下午也运行完了，耗时只有原来的一半，紧接着我启动写文件，按照一般的耗时估计，下班前数据文件也出来，放心了！

上午测试和项目管理组的同事要求过一遍CQ上的bug，因为这周三要提交一个版本测试。于是小组相关的人来到了会议室，当大家坐定，项目管理的同事想进入机器时，发现进入不了机器了，于是一帮人都在会议室等着那个同事把机器调好，大家虽有点唏嘘，但并不是特别奇怪，因为这已经不是第一次发生这样的事情，结果检查了一会，大约10min左右，判断可能是机房的路由器出问题，于是又找公司的网管，网管终于找来优先解决这个问题（因为公司的老总也在等这个会议），最后发现机房的路由器上的到会议室的网线不知道被谁拔掉了，插上就好了。大家一听，都议论谁会拔了这根网线呢？但毕竟机器上网没有问题了，会议可以开始了。

我就在想，机房一般只有网管等相关人可以进入，所以拔掉这根线的应该就是这些人中的一位，但为什么会拔呢？谁也不会无缘故的拔网线玩，只能是在某个时间上，由于要使用那个端口，所以拔了，因为会议室的网一般没有人开会的时候是不用的，只不过使用完后没有插上去而已。我觉得这并没有什么大问题。
让我觉得有问题的是，会议召集的人，在没有把准备工作做好的情况下，就把大家都叫过来，结果大家只能在那里等着你首先解决机器的问题。为什么不能提前把这些工作都确认无误的情况下再召集大家呢？你并没有多花一点时间，只是需要提前一点，这样就不会耽误大家的时间了。

过CQ上bug的时候，有好几个问题是目前没有办法解决的，无非就是两个原因，一种是因为目前底层平台的缺陷导致，另一种就是在目前的开发阶段或开发能力导致。
底层平台缺陷导致的问题，目前几乎是没有办法解决的。对于这种情况的bug，如果不是影响终端用户的使用或者使用时排除非法操作，一般就只有做延后处理。
对于由于目前开发阶段或开发能力所导致的bug，情况就要复杂的多，一般在短期内是无法解决的，需要在后期投入人力和时间去完善。这样的bug在处理时，测试部门一般会咬住不放，这个时候需要耐心为测试部门讲解目前不能解决的原因，以达成一致的共识，将bug降级或延后处理。但如果测试部门不认可你的理由，这个时候可能需要让上一级领导来判断，如果领导认可你的理由，那么测试部门不会说什么了，但领导一般很少会直接给出结论，而是转而提问：同行业的其他公司的软件是如何处理的？这个时候如果开发部聪明，已经在开发的过程中参考了同行业的其他软件，应该可以回答。或者测试部聪明，他们在测试的过程中发现了这个问题，首先去比对别公司的产品，那么也可以回答这个问题。结果是谁都没有做这个工作，于是这个问题在这次会议上并没有定论，而是下来后研究了再决定，这无疑在无形中增加了时间成本。这样的bug，多半都是使用合理性和用户感受的问题。
原因二的bug，如果最终在目前无法解决，而测试部和领导又要达到某种效果，被逼的开发部就只能采用特殊的策略来解决，这是我的头很善用的一种方法，我很是佩服。稍稍有点完美主义的程序员都会觉得这种策略是可笑的，甚至是不屑的。但事实就是这样，公司需要产品的上市，而产品需要某种功能的必备。