近20年过去了，Martin Fowler先生终于推出了新版的《重构》。本人有幸于ThoughtWorks技术雷达十周年峰会现场率先拿到了此书的国内发行版。

本文整理于《重构改善既有代码的设计》，这本书是用java写的，整理的目的是为了自己能写出更健壮、更具扩展性的代码，为以后的编码做参考。

重写大型系统比小型系统风险更高，考虑一下能否逐步重写。我们同时执行了以下几项工作：切换到新的数据库、使用“SOA”架构、更换为二进制协议，其实本可以逐步执行这些更换。

这个机会可能来自于各个方面，比如实现一些新功能或修复一个bug的时候。一个机会是“准备阶段的重构”，在你开始实现任务之前，你发现如果这个现有类的API稍微改变的一点的话，这个任务实现起来可能会更加的容易。这时候，你可以先将它重构为应该有的样子，然后再开始添加你的功能。

统一的代码风格规范是团队开发的重要要素之一。代码规范的统一有利于代码的阅读维护，有利于代码的“集体所有制”。试想，如果团队中每个人都使用自己的一套代码规范，那整体的代码风格就可谓“百花争放”，最后的结果就是代码越来越混乱，且难以阅读维护。我们项目中统一的代码风格概括来讲有如下几个方面：

本文主要起因是，一次在微博上和朋友关于嵌套好几层的if-else语句的代码重构的讨论（微博原文），在微博上大家有各式各样的问题和想法。按道理来说这些都是编程的基本功，似乎不太值得写一篇文章，不过我觉得很多东西可以从一个简单的东西出发，到达本质，

经常听到开发人员抱怨 ，“这么烂的代码，我来重构一下！”，“这代码怎么能这么写呢？谁来重构一下？”，“这儿有个坏味道，重构吧！”　　作为一名 QA，每次听到“重构”两个字，既想给追求卓越代码的开发人员点个赞，同时又会感觉非常紧张，为什么又要重构？马上就要上线了，怎么还要改？是不是应该阻止开发人员做重构？

首先，我们这里说的「重构」，和《重构:改善既有代码的设计》这本书中的重构不太一样，这是本好书，它主要说的是代码级别的重构，这种重构是需要在编码的时候时时刻刻进行的，更多的是一种编程思想的训练，而我们这篇的重构主要是说系统设计的重构。

对于如何进行代码重构，一直有着很多种说法。很多人都认为应该将重构代码放在backlog里。但是其实，这并不是一个理想的方法。