Git能助你做出步子更大的重构

许多国外重构大师，如Kent Beck和Martin Folwer都建议我们：重构的步子要尽量小，每两次测试变绿的时间间隔要尽量短。若代码耦合过密，两次测试变绿的时间间隔很难变短，而需要很长时间时该怎么办？

首先解释一下什么是重构的步子（Step）。一个重构的步子，就是在同一个测试的两次变绿（运行通过）之间所做出的代码改动。

下面是两位程序员之间的对话。

B：“现在代码中Clock下面有红线，表示这个类还没有定义，不过我觉得咱们现在就可以提交代码到git。”

R：“啊？代码编译还未通过，就提交代码？我们公司可是要求我们直到测试运行通过才能提交代码的。”

B：“对，你们公司说得没错，不过我认为这个要求是针对某种特殊情况而言的，即版本控制系统的代码库是使用‘客户端-服务器’这种集中式的管理的情况。你们公司管理代码版本用的是什么工具？”

R：“SVN。”

B：“嗯，SVN用的就是这种集中式管理的方式来管理代码版本。早先的代码管理工具CVS也用的是这种方式。这种方式最明显的特点就是一旦断网就无法提交代码。”

R：“是呀，用SVN管理代码必须联网。我在家办公的时候，要是连不上公司网络，那就没法写代码了。”

B：“而用分布式的代码版本管理工具git就没这个问题。git除了也有远端代码库外，在客户端也有客户端代码库，网断了一样也可以管理本地代码版本。程序员不必等到本地编译或测试通过，而可以随时把代码提交到本地代码库。直到本地的代码编译和测试都通过后，再统一把代码push到远端代码库中，照样不会破坏远端的持续集成。”

代码版本控制系统根据代码库的管理方式分为两种：一种是“客户端-服务器”的集中式管理方式，即“一个中心代码库，多个客户端”，如SVN、ClearCase和CVS。其特点是客户端没有管理代码版本的能力，一旦断开网络，就无法进行代码版本的管理。另一种是分布式管理方式，即“一个中心代码库，多个客户端代码库”，如git和BitKeeper。其特点是客户端代码库有管理代码版本的能力，断网也能管理代码版本。

“代码只有编译和测试通过才能提交”这一点，主要是针对集中式的代码版本控制系统而言的，以保证不会破坏远端的持续集成的编译、测试和打包。但如果程序员正在做一个步子较大的重构，比如需要修改30行代码，当修改了20行代码时，发现写错了，需要回退到修改了10行代码时状态，若使用集中式代码版本控制系统，代码的状态只有在提交时才记录，那么要回退的话，也只能回退到上次测试变绿即修改了0行代码时的状态，这样那10行代码的修改就找不回来了。

但对于分布式的代码版本控制系统，只要不push到远端的代码库，程序员无论代码是否通过了编译和测试，甚至每修改一行代码，都可以随时提交到本地代码库，这样就可以轻松地在代码写错时回退到上面修改了10行代码的状态。当程序员在自己电脑上的本地代码库中，最终让编译和测试运行通过，并从远端代码库fetch回代码与自己的代码进行了比较，确保没有冲突后，就可以一次性地把自己电脑上所有本地代码库中提交的代码，push到远端代码库上，这样同样能够保证不会破坏远端持续集成系统的编译打包工作。

既然git能从机制上保证程序员只要不push代码到远端，就可以不管代码是否编译和测试通过，而频繁地commit代码，那就意味着在一步重构之内，即两次测试变绿之间，代码是可以频繁commit到本地代码库，而不用担心破坏远端的编译测试打包工作的。而中间频繁的commit，就可以帮助程序员轻松回退到写错前的代码，进而在一步重构之内写更多的代码，从而支持更大步伐的重构。

喜欢我今天的文章，不妨点击右上角按钮分享到朋友圈，以广结善缘。无论是否喜欢，都可回复本条微信，我必看必回。

您看到的上面我写的文章，首发于微信公众号bjdp_org。该公众号服务于我创办的bjdp.org公益编程操练社区。在这里，程序员们聚在一起，编程、学习、找乐子；和测试工程师一起结对编写验收测试代码；与产品需求专家一块探讨如何能让软件开发的成果不离谱。程序员、测试工程师和产品需求专家，是密不可分的“三兄弟”。

欢迎在微信上搜索bjdp_org关注北京设计模式学习组。

如果您想看本公众号以往的精彩内容，请回复m