为什么感觉国内程序员都很少进行代码重构？
对于这个问题，我内心的回答是呵呵，你这是想搞事情啊。
首先需要明白代码重构是什么意思，重构就是在不改变软件系统外部行为的前提下，改善它的内部结构。那么问题来了，代码重构需要满足什么条件呢？
为何重构
如果遇到以下的情况，可能就要思考是否需要重构了:重复的代码太多代码的结构混乱程序没有拓展性对象结构强耦合部分模块性能低为何重构，不外乎以下几点：重构改进软件设计重构使软件更容易理解重构帮助找到 bug重构提高编程速度重构的类型：
对现有项目进行代码级别的重构；对现有的业务进行软件架构的升级和系统的升级。本文讨论的内容只涉及第一点，仅限代码级别的重构。重构时机
第一次做某件事时只管去做；第二次做类似的事会产生反感，但无论如何还是可以去做；第三次再做类似的事，你就应该重构。
添加功能时：当添加新功能时，如果发现某段代码改起来特别困难，拓展功能特别不灵活，就要重构这部分代码使添加新特性和功能变得更容易；修补错误时：在你改 bug 或查找定位问题时，发现自己以前写的代码或者别人的代码设计上有缺陷（如扩展性不灵活），或健壮性考虑得不够周全（如漏掉一些该处理的异常），导致程序频繁出现问题，那么此时就是一个比较好的重构时机；复审代码时：团队进行 Code Review 的时候，也是一个进行重构的合适时机。代码重构的艰辛坎坷之路一、如果你决定重构代码，特别是别人的代码，最好对整个项目有一个清晰的认识，最好记得哪些代码运行在哪些文件中的哪一行里（基于没有BUG即良好的思想，你可不重构）。我很反感以下的代码。boo _flag=false; boo _isexists=false; string _username;
上面的代码不用多说，大家也可以看出问题，当然这些简单的重构我相信初学者都可以改好，其实这是习惯问题，有时候是：习惯决定行为，行为决定思想，思想决定高度。至少在这里我看不出什么高度可言了。二、尽量不要去动那些核心的代码。这里所指的核心是：搞不好程序就当掉了。如果你真要没事想重构以显示你的能耐，我劝你还是考虑一下“没有BUG不要修改”的原则。我上一次对一个程序的核心代码（绝对是核心）修改前，花了一个星期去阅读所有文档和代码，虽然之前我已对所有文档和代码看过无数次。三、如果真要进行重构，那么最好让所有项目组成员都知道。不要以为你重构一点点功能而已，不影响什么东西；如果你不认同这一条，那么请回忆一下中国移动的广告：沟通无限。相信我，作为项目组的一员，他们是非常有必要和需要知道你正在动他们的奶酪的。四、记得作代码签入注释。我对那种不写注释的人，有想痛扁他一顿的冲动。五、让他人介入。重构前或者重构后，让你的同事或者上级审阅你的代码，如果你写得很好，也是一种享受；当然，如果你写得很烂，也算得到了指点。六、重构前，试试测试驱动开发。我从来不在真正的项目中直接切入重构，因为我不能预料到我的切入是否正确，那种感觉就像是，让我不穿衣服的站在街上的那么的窘迫。也许你想找环境的借口；不，我告诉你，环境都是人搭建的，搭建环境是相当不费事的，至少我还没有怎么费事。七、学会宽容和理解。重构之人火气通常都比较大，当然，你也许可以采用让被重构者请你喝杯咖啡来缓解紧张的气氛。八、没事不要老打重构的主意。最后一条我觉得是非常重要的一条，如果你没事老重构的主意，那只能说明一点，你写的很烂；或者你认为其它人写得都没有你高明。相信我，这绝对是没事找抽型的。
