忍无可忍---dreamhead

忍无可忍

Tag：脚下的路

版权声明：转载时请以超链接形式标明文章原始出处和作者信息及本声明
http://dreamhead.blogbus.com/logs/24874404.html

几个月前，一个同事跟我说，这个bug改不动了，我问为什么，他的答案是，那块的代码太乱了，改一丝会动全身。

昨天，一个同事跟我说，这块太乱了，做不动了。

两次，我做了相同的选择：重构。

重构和开发新功能在很多PM眼里一直是一对很难调和的矛盾。对于PM来说，来自客户的压力让他更关注项目的进展，而重构往往代表项目的原地踏步，只有开发新功能才是“正道”。放弃“正道”，选择看不见进展的重构，站在PM的角度上，这是难以接受的。

“破窗户”理论告诉我们，一旦置破烂于不理，其结果通常是烂得更多更快。

一个同事和我聊天时，提到了他正在做的一个系统，他们在开发的过程中发现了很多问题，很多bug改起来都非常困难。他们想重构，但是强势的PM坚持要开发新功能，于是，这些问题有幸在代码中继续生存下去。随着项目的进行，这些问题暴露得越来越明显，以致于有些问题已经成为项目继续开发新功能的障碍。当问题到了不得不进行修改时，发布的日期也逐渐临近了。

当我做出重构的选择时，我知道，我会失去对当前进度的控制。但我期望得到的是一个合理的设计，以此，后续的一些开发工作会得到大幅度加快，前面失去的进度后面在一定程度可以得到弥补。

几个月前，那段时间，项目进度如预期的慢了下来，但随着重构的进行，我对代码质量也逐渐的越来越有信心了。事实证明，项目后期出现了进度井喷的现象，原本耽误的进度到最后居然出现了提前完成。

这次，当我和那个同事讨论了新版设计之后，我从那个曾经失望的眼里看到了光芒。今天开始工作之前，项目组的所有开发人员又在一起重新讨论了这个新的设计，并进行了一些完善。于是，一个Pair开始采用这个新的设计方案进行编码。事实出乎意料的顺利，原本预计耽误很多的进度，在他们生花妙手的努力下，在今天下班之前，就将大部分赶了回来，让我着实惊讶于他们的开发速度。

从这几个项目的经验来看，重构，短期上在阻碍开发的进度，但是站在长期的角度，却可以大幅度提升软件开发速度，也提高了软件本身的质量，更重要的是，通过重构，解决掉一些原有实现中固有的缺点，可以将程序员从痛苦中解救出来。编程本应该是快乐的，不是吗？

忍无可忍，无须再忍，重构吧！