少年包工头的工作日记--俺的重构心得

W3CHINA Blog首页 管理页面写新日志退出

Blue blue sky

小工头发表于 2011/1/23 15:42:13

　今天是俺头一次选择“软件技术”分类。身为一个有经验的IT青年，好歹也该秀一秀专业嘛。根据权威教材的定义，重构就是在不改变软件外在表现的情况下，对其实现进行修改。从这个定义来看，重构对于使用软件的乙方、售卖软件挣钱顺路给IT青年发工资的老板、一边指挥IT青年干活一边被老板扁的领导、甚至调用软件接口的其他IT青年……这么说吧，对于不直接进行软件开发的所有人都没有好处。既然不会改变软件的外在表现，为何还要做这种无意义的事情呢？答案是，重构是对抗“代码腐化”的最好方法。“代码腐化”是个挺有意思的说法：代码写出来之后又不会变，怎么会“腐化”呢？实际上，“代码腐化”指的是维护代码的难度和工作量逐渐增加，最终导致代码不可用的现象。据俺观察，导致代码“腐化”的原因主要有两个方面：第一，应用环境的变化。最常见的是项目持续时间太长，需求变来变去，临时应付的小修小改积累太多，导致代码冗余，体积增大，效率下降，逻辑混乱等等。具有讽刺意味的是，越是重大项目越容易出现这种类型的代码腐化，原因是因为关系重大，开发者不敢轻易变动已有的代码。只要代码还能正常运转，能不改就不改，能少改就少改。不知不觉地，代码显得越来越脆弱，开发团队把代码供起来天天烧香，祈祷它不要出问题。一旦出了问题，所有人都大怒，可是相互之间推来推去，就是没人敢改。要是情况持续恶化，原先的开发人员大约就会另谋出路，然后老板痛下决心重新开发……到了这时候，代码就彻底腐化了，而项目也失败了。第二，人的变化。铁打的硬盘流水的兵，代码前后被不同的IT青年维护开发是常见的事。IT青年的思路各自有别，写出来的代码自然也会不同。如果沟通不畅，前后任开发者的想法不一致，代码的内在逻辑就会不连贯，后续维护的时候就变得困难。另外，即使是同一个人做开发，也会发生变化。如果掌握了新的技术，原有的代码就会显得落伍。以俺为例，自从学会了STL vector之后，每次看到以前代码里留下的new和delete就头疼。更有甚者，即使与新技术无关，这种情况也会发生。还是以俺为例，前段时间俺把自己刚入职时做的一个工具重构了一下，只是简单地封装了一些代码，做了做复用，统计下来5000多行代码减少了将近2000行。汗！也不知道当年俺是怎么保住这份工作的。与坐等代码腐化然后重写相比，重构只修改需要重构的部分，复用其他没有腐化的部分。持续重构，代码就可以保持可用。与重写相比，重构的代价显然更小（话说回来，这对于乙方仍然是没有意义的）。重构为何能保持代码的可用性，其奥妙就在于“不改变软件外在行为”这几个字上。要想确实地“不改变软件外在行为”，首先要确实地知道软件的所有外在行为。因此，重构必然是以全面深入地分析代码开始的。有人在重构软件，就意味着有人对软件有着全面而深入的了解，代码在被人精心地维护着，无论是修改bug还是增加新特性，都有可靠的人选来完成。另一方面，重构之后如果要确认软件的外在行为没有改变，必然要经过全面的测试，潜藏的bug也就可以及时发现了。所以，重构并不是一个简单的开发的动作，而是与分析、架构、测试甚至文档等等软件开发的方方面面联系都很紧密的一件事。对于从事一线开发的IT青年来说，重构是一件很有益的事。完成一次成功的重构，意味着对代码有了全面而深入的了解，对软件开发这件事也会有新的理解，不管是对个人水平的提高，还是对个人在公司地位的稳固，都是很有益处的。对俺来说，显而易见的好处是重构占用了俺的工作时间，俺就不用做maintain那种无聊的事情啦！啊哈哈哈～

阅读全文(5886) | 回复(1) | 编辑 | 精华

回复:俺的重构心得

原创空间, 软件技术

xhbao(游客)发表评论于2011/1/31 15:58:45

幸福的人呀！！俺们都是一边添新功能，一边改底层架构，常常觉得重写一遍来的比较爽，可惜。。。。。。

个人主页 | 引用回复 | 主人回复 | 返回 | 编辑 | 删除

回复:俺的重构心得

原创空间, 软件技术

真不准发表评论于2011/1/25 22:51:56

重构不是容易的事情，尤其是一些成熟的大型软件，想重构客户反而不放心。搞笑的是明明有BUG，客户却早已经了然于胸，有他的处理办法，他们反而担心我重构后可能引起他们不熟悉的问题，然后大规模发布后引起重大问题。所以有时候看看以前代码狂烂，但也都不能改了。

个人主页 | 引用回复 | 主人回复 | 返回 | 编辑 | 删除

» 1 »