作为一名程序员，我最大的愿望是自己写的代码，能够被人称赞，一直留存在项目里，直到永远。能够让自己的代码一直留存在项目里，一方面自己写的代码要健壮，没有任何逻辑错误。另一方面，还要具有很好的扩展性，能够适应需求的变化。对于前者来说，只要有个两三年的基本功，基本上就能保证代码的质量。然而，要写出具有扩展性的代码，却是一件比较困难的事情。
不是因为具有可扩展性的代码不好写，而是因为这个度不好把握。我们知道系统的可扩展性总是与系统的业务和性能成反比，因此，我们不会在追求系统的扩展性上而忽略了系统的业务和性能。相反，我们总是在三者之间寻求平衡，以求最大程度的满足客户的需求，同时降低系统的成本。
系统可扩展性 = 1/(系统的业务)*(系统的性能)
当我们为客户设计一个新系统时，客户和开发人员往往都不知道最终的系统是什么。对一个连需求都无法确定的项目来说，产品经理需要不断的重构和演化，确定出最终的系统原型。对于从未进行过该业务方面开发过的程序员来说，一方面要将代码转换为产品经理的原型，另一方面要实现系统的功能，而且还要时刻准备着迎接需求的变更。
在设计之初，每个程序员都怀着远大的梦想，精心去设计每一行Code，追求各种灵活性。但是后来他们发现，他们精心设计的代码轻轻松松就被“该设计不符合需求”而否定了。是他们的代码不够灵活吗？不，是系统的业务变化的太大了（我说的是前端，你懂的）。在一次又一次的痛批之后，他们终于明白，代码的灵活是跟不上客户的脚步的。于是，他们不再追求高可配性的代码，取而代之的是符合用户需求的简单实现。
随着业务逐渐明晰，系统也变得越来越复杂。最终开发人员发现代码已经变的臃肿不堪（如果你做过30人/年~50人/年的新项目，我想你会理解这些的），他们已经无法在当前的系统进行新业务的开发，于是他们必须要面临一个严峻的问题：是否需要对代码进行重构。
每个人都知道重构的危险：一方面会影响当前系统开发的进度，另一方面也可能会造成原来可用的流程变得不可用。在进行重构之前，设计们要再三评估重构的风险性以确定是否有必要进行重构。其实，当这个问题提出来的时候，系统几乎已经达到了重构的极限。要不是因为系统的耦合性太强，每做一小步的更改都会对系统产生巨大的影响，谁会浪费时间、浪费精力，想对代码进行重构呢。
很多人觉得代码被重构是一件可耻的事情，其实不然。对于一个需求不明确的大型项目来说，只有通过持续不断的集成和重构，才能产生健壮稳定的系统。只有不断的集成和重构，才能保证系统在业务和实现上都没有偏离重心，在可用性以及稳定性上，达到客户的要求。当我们的代码被重构时，我们应该感到庆幸，因为我们降低了系统走上“歧路”的风险，同时我们也为类似相关的案例积累了宝贵的经验，只有失败的经验才更刻骨铭心，不是吗？
我们的代码重构了，它终于被重构了，我感到很欣慰，我终于再也不用看那些烦心的代码了，也不用再担心哪个人不小心改了自己的代码，而导致我负责的模块不可用。