我是如何将3000行代码重构成15行的

等你无法重构的时候再考虑重写

我 带过很多优秀的程序员，也与很多优秀的程序员共事过。有一大部分的程序员在看到一套系统不是那么满意，或者存在某些明显的问题，就总是忍不住要把整套系统 按自己觉得可以优化的方向来重写，结果，重写结构往往并不令人满意。系统中确实存在很多不合理的地方，但是有不少的这种代码，恰恰是为了解决一些特定场景 下的问题的。也就是说，所有的规范以及编程的原则，其实也是有条件限制的，他可能在大部分的时候是正确的，能够指导你完成你的任务，但是，并不是在所有地 方都是适用的。比如数据库范式，但实际中我们的设计往往会考虑冗余，这是违背范式的，但是为什么还有那么多人趋之若鹜呢？因为我们可能需要用空间换时间。

如果我们一开始就考虑重写，那么你可能会陷入以下的困境：

• 需要花更大的精力来完成一些看似简单的BUG你要知道，有一部分看似错误或者非常不优美的代码，其实恰恰是为了解决一些非常刁钻的问题的。
• 再也无法兼容老的系统了你急于把原有系统重写，却往往忽略了对原有系统的兼容，那么你新的系统的推进则会十分缓慢。而老系统的维护，又会陷入及其尴尬的情况。
• 过度设计，导致重写计划迟迟无法完成有重写冲动的程序员往往是在架构设计上有一些读到的见解，他们善于利用所学的各种设计模式和架构技巧来建立系统，但是越是想尽可能的利用设计模式，越是陷入过度设计的困局，导致重写的计划迟迟都无法完成。
• 无法有效利用现有系统已经完成并测试的代码如果你确实有必要进行重写，我还是建议你把代码尽可能的重构。因为重构之后的系统，能够让你更轻易的重写，又最大限度了保留以前可用的业务代码。

我举个例子，说明如何通过重构更好的利用现有代码的。

我有一个非常庞大的系统，其中有一块功能是用于数据采集、存储、告警管理以及电话、短信等告警通知。大致的结构如下：

class MainEngine:IEngine{
	public MainEngine(ConfigSettings config){
		
	}

	public void Start();
	public void Stop();
}

需要增加新的业务功能时，程序员写的代码往往是这样的：首先时修改配置类

class ConfigSettings{
	public bool NewFuncEnable{get;private set;}
	public ConfigSettings(){
		NewFuncEnable=xx;//从配置文件读取
	}
}

接着修改主程序：

class MainEngine:IEngine{
	private NewFuncClass newCls=new NewFuncClass();
	public MainEngine(ConfigSettings config){
	}

	public void Start(){
		if(config.NewFuncEnable)
			newCls.Start();
	}
	public void Stop(){
		if(config.NewFuncEnable)
			newCls.Stop();
	}
}

在修改的过程中，往往是根据配置文件来判断新功能是否启用。上面代码会造成什么问题呢：

• 主程序代码和扩展功能耦合性太强，每增加一个功能都要修改主程序代码，这里非常非常容易出错。尤其是新的人进度开发组，很容易就忘主程序中增加了一些致命性的代码。比如上述的扩展功能，可能是在特定的项目中才会有这个扩展功能，但是，写代码的人忘记增加是否启用的配置选项了，导致所有的项目都应用了这个功能，而这个功能需要特定的表，这样就悲剧了。即使是你增加了配置，也是非常的不美观，因为在通用的版本中使用了这个配置，往往会让定制项目以外的人员感到困惑。
• 增加扩展功能的人还需对整个MainEngine代码有一定的熟悉，否则，他根本就不知道在Start方法和Stop方法进行newClas的对应方法的调用
• 如果你打算对这段代码进行重写，那么，你会感到非常的困难，因为你分不清楚newCls这个新实例的作用，要么你花大精力去把所有代码理清楚，要么直接就把这段新增的业务代码去掉了。