磨刀不误砍柴工

      今天费了整整一天的时间，从早上8点多，忙多晚上8点多，忙活10多个小时，修改上传了400多个文件，却没有解决任何故障。不过我觉得今天的工作是非常值得的。

 

      代码大全里面曾讲到，代码的22中坏味道，其中重复是万恶之首。我的确是真体验到了。一套代码40多个项目，有四十多个分支。如果仅有几个文件有定制，那或许还算是比较愉快的事情。但是如果几十个文件有几十个定制，这就是一件让人生不如死的经历了。然而非常不幸，这让我体验到了。

      前些日子，一个同事添加一个新功能，修改了几十个文件，又非常不幸的传到了定制分支。如果事情仅仅如此，也罢了，不幸的是，后面又有十几个项目都要求合入这个功能，于是这几十个文件就被拷贝了几十份。这一下子让很有意义的编码彻底变成了一场体力劳动，往往每修改一个文件，都要同事同步几十次。虽然之前也有想法想彻底处理一下，但是一直没有动手。

 

     如果这是一个结束也就罢了，可是就是这几天七八个项目接踵而至，使岌岌可危的项目维护雪上加霜。为了避免事态进一步恶化，将一切掌于控制之中，使得自己和后来的同事能有一个更好的开发维护环境。我下定决心把代码整理一下。

 

    代码整理步骤如下：

     第一个阶段，找出所有与这个功能有关的修改文件，查找整个项目下这个文件的所有定制；把功能合到各个定制分支下面。编译各个项目，并对重点项目进行波及分析和测试。

     第二个阶段，查找各个分支定制，删除与主分支相同的文件定制；对于定制分支通用性接口和功能尽量合到主分支，减少维护代码的工作量。

 

    如此一来，很多情况下几十份的工作量就减少到一两份，而且避免了由于分支忽略导致的编译错误和功能遗漏，可谓一劳永逸。

 

    我们在是否重构之间犹豫，到底是应该勇于改变还是保持现状，这是每一个开发者到了开发中期必需面临的问题。重构为了项目的可持续发展，不过也是存在风险的；保持现状是为了项目稳定，不过越到后期项目也不可维护。既然是该做的事情，我们就要去做；也不一定要一蹴而就，可以循序渐进，每次只重构一个功能或者一个函数。当然，人非完人，重构建立在充分自测测试的基础之上，完全有可能鱼和熊掌兼得。长痛不如短痛，更重要的是要有一个意识，每新加入一个功能都考虑后续可维护性，加入后上传之前多代码走查。所谓早预防、早诊断、早发现、早治疗。