重构几乎是每一个软件工程都会碰到的事情，每当人们提到“重构”的时候总会这样描述：使用各种手段重新整理一个对象设计的过程，目的是为了让设计更加灵活并且/或者更可重用。你可能有几个理由来做这件事情，其中效率和可维护性可能是最重要的原因。
关于如何进行重构和进行重构给我们带来的种种益处，不是本文想要述说的内容，本文是想通过重构来谈谈，如何才能让每一个程序员都快乐的工作。
米卢蒂诺维奇给中国足球带来了源自欧洲的先进足球理论，除了这些理论还有一个很重要的理念，那就是“快乐足球！”。他教导他的中国球员是因快乐而踢足球，更因足球而快乐。同样我的一个Leader也常常这样告诉我们，我们每天工作八个小时，如果在这一天最重要的时间里你过得不快乐，那么你的工作还有什么意义呢？
代码太容易变坏。代码总是趋向于有更大的类、更长的方法、更多的开关语句和更深的条件嵌套。重复代码随处可见，特别是那些初看相似细看又不同的代码泛滥于整个系统：条件表达式，循环结构、集合枚举….信息被共享于系统一些关系甚少的组成部分之间，通常，这使得系统中几乎所有的重要信息都变成全局或者重复。你根本不能看到这种代码还有什么良好的设计。(如果有的话，也已经不可辨识了。)
这样的代码难以理解，更不要说对它加以修改。如果你关心系统体系结构、设计，或者是一个好程序，你的第一反应就是拒绝工作于这样的代码。你会说："这么烂的代码，让我修改，还不如重写。"然而，你不大可能完全重写已经能够甚至是正在运作的系统，你不能保证新的系统能够实现全部的原有功能。更何况，你不是生活在真空，还有更多的投资、交付、竞争压力。
于是你使用一种quick-and-dirty的方法，如果系统有问题，那么就直接找到这个问题，便当地修改它。如果要增加一个新功能，你会从原来的系统中找到一块相近的代码，拷出来，作些修改。对于原来的系统，你想，既然我不能重头写过，而且它们已经在运作，让它去吧。然后，你增加的代码变成了下一个程序员咒骂的对象。系统越来越难以理解，维护越来越困难、越来越昂贵。系统变成了一个十足的大泥球。
不难看出程序员的工作有些时候无疑是繁重和枯燥的，如何让程序员摆脱这些不快呢，作为程序员出身的我，有一个很重要的方法，就是对代码执行重构。
由于成功地重构之后，提高了开发效率。程序员有了时间可以看一看书或者新闻，给自己的朋友回一封Email，而不是每天埋头于无休无止的复制和调试。维护一份陌生的代码的时候也不再会去诅咒先前的设计人员的糟糕设计，能够轻松的面对日程表上的进度安排。
很多时候设计很难一次作得很好，要保证软件的活力，注定要经常的修改需求，面对如此多的迭代，作为设计师和程序员，必须充分的重视重构给一个软件产品带来的活力。