重构.水

重构的背景

重构的范围有点宽泛，重构也是可深可浅的。 一般代码优化，精简也是重构的一部分。 深入的重构是要基于框架，对业务有足够认知，把握。

重构不是想当然发生的。 深入的重构一定是现阶段系统已经不能更多的支持业务扩展；或者bug太多，无力追加新的需求。 这时一般架构师会联合产品经理一起来着手系统的重构

重构的目标

重构是基于目前系统的存在问题才会重构的。 一个优秀的系统去重构的带来的价值不大。 重构也不是说全部推翻重来，没有根据而进行重构。 找到目前系统的痛点，重构的目标是为了更好支持业务扩展，另一方面就是为了解决这些痛点。这才是重构的目标。

重构的准备

其实这点说起来有点赘述的感觉： 重构一定要结合业务本身。只有了解了业务的需求，产品的更多细节，重构才能做得更好。

这里说个我的实际例子： 我重构时，有一个架构师提供重构的整个架构，一个多年资深的技术/业务党（boss），还有一个实施经理（当时负责产品需求），我是重构的具体执行者（对于业务有一定的了解）。 重构时，每当出现疑问，不清楚的地方时，都会列举用户场景，给出解决方案，解决不了然后跟他们一起过，在会议中确定解决方案。 照着说这算是ok的。

但是在重构完，新的产品总监来梳理我重构的功能时，却发现有些地方设计过度，有些地方不是产品想要的东西...(注：此次重构解决了业务扩展的问题，跟原先系统的痛点)

所以在这里知道一个重构的准备是多么重要了吧，重构一定与基于业务本身来做，产品要做成什么样子，重构需要支持到那步，这都是需要重构商讨确认的地方，不然后果可能就是设计过度，或者没达到产品的需求

重构的过程

即使对业务了解，但也可能因为重构的关系，到了某些点的时候不清楚该怎样解决，或者不清楚某些点该如何实现。 这些都是问题。至于怎么解决问题，那么最有效的方式就是去列举用户场景，根据用户场景然后才能针对性的解决。

一般刚接触，不知道怎么做，然后就不知所措。其实这里要慢慢学习去列举用户场景，可能列不全，没关系，在跟产品讨论的时候这些会被慢慢补全，有了这些用户场景，然后你需要的就是实现各种用户场景下的情况就行

重构中学到

一个企业级的系统中，需要面临的复杂多变需求，程序是不可能用逻辑去完全兼容所有情况。这时我们需要转变思维：抽象业务，发现业务关键点，提取其中公共部分。提供输入参数，用动态灵活的配置(业务逻辑处理)来支持更多复杂多变的情况。

即使一个erp系统， 也需要去抽出平台层公共的组件，为上层业务提供支持，同能也能在业务层解耦。

本篇是未读<<重构:改善既有代码的设计>>写下的水文，不久等我读完这本书再来写点更多感悟