从Fix一个Bug看我的工作效率

前两天收到一堆Bugs的Fix Order，二话不说，我就驱Studio上路，第一个Bug很简单，无非是根据一个后台的逻辑去修改前台的一些控件的显示状态之类的，初初看上去，要Fixed它很简单，在后台一个一个控件设置一遍就可以了，不就是十几分钟的事情么？但是打开页面之后，我开始后悔刚才的想法，因为页面中的控件太多，要一个一个找出名字来，虽然不多，但是做重复性劳作容易出错，对我这个粗心又四眼的人来说确实是个吃力不讨好的事情，更何况哪天页面多加了个控件，而需要这个同样的需求的话，如果忘记了不又是一个让我吃的致哑黄连的毒药提供商！必需写一个公用的方法去把这些控件找出来，说做就做，方法的雏形很快就出来了，但是第一个priview根据传统总是有点意外的，果然在Updatepanel的包装下，它光荣地。。。挂掉了，跟踪调试Debugger，等把controls之间的关系搞懂了，priview2出来了，他现在可以从容地把Updatepanel
中的controls一一抠出来，窃喜之时又想起这个方法把层次写死了，如果有多层usercontrol包装，不也挂掉吗？不行，必需把它改造成一个递归的方法，把每个角落里的controls都抓出来严打！priview3出来了，测试之，咦？怎么，一个listbox竟然逃过我程序的法眼呢，哦，原来controls写死了，也没有把它写进黑名单，加上改之。但问题又来了，就这样加，如果日后再发现遗漏，我们不是还要添加一次，能不能包含所有的controls呢，如果能分离这段逻辑放到配置文件中就更好了，日后就不需要再修改这段程序了。。。Ok，priview4出来了，它已经基本满足我模块的需求了，但是bug report中的一个刺眼的"etc."又让我皱眉，是reporter的粗心还是有意为之，这样是不是意味着还有更多的模块需要这样的一个逻辑呢？沟通，这个时候需要沟通，果然经过和reporter的沟通，显然我的担心是百分之二百的正确，也就是说这个方法的逻辑要应用于很多模块中，那么它就不能只设计成只为我的模块服务啦，它必需要挪动到公共的模块或者基类中做修改，一轮忙乎，priview5降临了，用别人的模块简单的测试了一下，OK，这时候是该放下心头之石了用FF去冲冲浪休息一下了吧，FF？哦，对，FF和IE对于Control的展示的样式是有相当大的变化的哦，就是一个简单的disable都不一样，不行，必需为每种控件准备N套衣服以备不时之需才行，虽然衣服都已经有先人做好了放在公共的CSS箱子里，不过要我从头一个一个的去给他们量体选衣服真不是一件轻松的事情，不行，这里也得写个公共的适配器，督促他们自己去穿才行。。。Priview6出现了，运行都良好，不过看着洋洋洒洒而且臃肿的代码，越看越恶心，要高雅点，重构拆分之。。。随着一个个unitest的红灯慢慢转变成绿灯，嘴角终于可以有点笑容啦吧，让它check in进去让它晋升成alpha了吧，在这之前先给补补妆吧，加上绿绿的comments。哦~~，这里怎么comments妆化得又浓又看不清呢？恩，而且还散发着一股恶臭，必需给他整容，让它不用化那么恶心的妆来愚弄世人，要让每一个人包括我，N年后都记得它的美丽容颜，键盘又得欢快地高歌一曲咯。。。
代码check in，OK!我不禁把干涩的眼睛深深的闭了一下，抬头去感受下那份柔和的阳光，阳光依旧是那样轻抚我的脸，只是迟暮之光比起晨曦之光，少了分朝气，多了分疲倦。。。

同僚：搞定了没有，要下班啦
我：哦，搞定了一个。。
同僚：啊，不是吧，明天出build，要提高效率才行哦
我苦笑道：唉，没有办法，我就是手脚慢，效率低啊。。。

--
两边键盘声不断，
轻舟已过万重山。