-
2008-07-16
忍无可忍
版权声明：转载时请以超链接形式标明文章原始出处和作者信息及本声明
几个月前，一个同事跟我说，这个bug改不动了，我问为什么，他的答案是，那块的代码太乱了，改一丝会动全身。
http://dreamhead.blogbus.com/logs/24874404.html
昨天，一个同事跟我说，这块太乱了，做不动了。
两次，我做了相同的选择：重构。
重构和开发新功能在很多PM眼里一直是一对很难调和的矛盾。对于PM来说，来自客户的压力让他更关注项目的进展，而重构往往代表项目的原地踏步，只有开发新功能才是“正道”。放弃“正道”，选择看不见进展的重构，站在PM的角度上，这是难以接受的。
“破窗户”理论告诉我们，一旦置破烂于不理，其结果通常是烂得更多更快。
一个同事和我聊天时，提到了他正在做的一个系统，他们在开发的过程中发现了很多问题，很多bug改起来都非常困难。他们想重构，但是强势的PM坚持要开发新功能，于是，这些问题有幸在代码中继续生存下去。随着项目的进行，这些问题暴露得越来越明显，以致于有些问题已经成为项目继续开发新功能的障碍。当问题到了不得不进行修改时，发布的日期也逐渐临近了。
当我做出重构的选择时，我知道，我会失去对当前进度的控制。但我期望得到的是一个合理的设计，以此，后续的一些开发工作会得到大幅度加快，前面失去的进度后面在一定程度可以得到弥补。
几个月前，那段时间，项目进度如预期的慢了下来，但随着重构的进行，我对代码质量也逐渐的越来越有信心了。事实证明，项目后期出现了进度井喷的现象，原本耽误的进度到最后居然出现了提前完成。
这次，当我和那个同事讨论了新版设计之后，我从那个曾经失望的眼里看到了光芒。今天开始工作之前，项目组的所有开发人员又在一起重新讨论了这个新的设计，并进行了一些完善。于是，一个Pair开始采用这个新的设计方案进行编码。事实出乎意料的顺利，原本预计耽误很多的进度，在他们生花妙手的努力下，在今天下班之前，就将大部分赶了回来，让我着实惊讶于他们的开发速度。
从这几个项目的经验来看，重构，短期上在阻碍开发的进度，但是站在长期的角度，却可以大幅度提升软件开发速度，也提高了软件本身的质量，更重要的是，通过重构，解决掉一些原有实现中固有的缺点，可以将程序员从痛苦中解救出来。编程本应该是快乐的，不是吗？
忍无可忍，无须再忍，重构吧！
引用地址：
梦想风暴
一个小程序员的信口开河
搜索
最新评论
评论
我也忍过，而且现在也还在忍，因为项目进度或者说稳定对我来说也是重要的，而一次性的大重构，我觉得非常人所能，额外的时间和精力投入以及压力是非常巨大的，干过一些，也看到别人干着。
从另一个角度来说，凡事并非一蹴而就，所以为什么要忍？让我想起一个保护地球保护环境的广告，其实代码环境又如何不是呢。
所以我开始用另一种方式，那就是自己键盘所到之处，所需之处，绝对清理，之外的视情况而定。这需要更多的忍耐，循序渐进真的很难，就好像骑自行车，依靠惯性快点骑比慢慢骑要容易一些，我每次都是恨不能一蹴而就，但其实只要考虑到重要的东西其实非常多，比如持续集成，其极限设为一天，那么很显然你这一天是很难做非常大的重构的，所谓小不忍则乱大谋，所以暂时让视野之外的垃圾留一留，甚至是为之存活加点生活垃圾也行，当然，前提是你还会回来清理掉它。
相对来说，为加新功能进行必要的重构是很容易让人接受的，而我更认为基本上别人不能干预，PM总不能关心我一天中每个小时都在干什么吧，关心也无所谓，没有动到PM的奶酪，人家肯定愿意放手让你撒野。
做一个好的程序员真的很难，即便自己做得很好，也很难保证项目组所有人都做得很好，所以，眼之所及，会有许多不甚理想的地方。很早的时候，我就告诫过自己“不要完美”，要权衡收益。如果收益小于付出，容忍一些垃圾是可以的，反之，放手去做是最好的选择。