定义一个 Enum 表示现有系统的 Workstation Type:
public enum WorkstationTypeEnum
{
Department_HR,
Department_Audit,
Department_IT,
}
定义一个方法表示从 config 里面读取 Workstation Type:
public static WorkstationTypeEnum GetWorkstationTypeFromConfiguration()
{
// 从 app.config 读配置信息以及其他复杂的逻辑操作。
return WorkstationTypeEnum.Department_IT;
}
在 Main 方法里根据不同的 Workstation Type 启动不同的 Workstation.
static void Main(string[] args)
{
WorkstationTypeEnum workstationType = GetWorkstationTypeFromConfiguration();
switch (workstationType)
{
case WorkstationTypeEnum.Department_HR:
Console.Write("Start HR department workstation.");
break;
case WorkstationTypeEnum.Department_Audit:
Console.Write("Start Audit department workstation.");
break;
case WorkstationTypeEnum.Department_IT:
Console.Write("Start IT department workstation");
break;
default:
throw new Exception();
}
Console.ReadKey();
}
现在想想,实习的时候真2呀,分到任务就噼里啪啦的开始做了。
Solution 1:在 Enum 中加上 Department_DEV,然后在所有用到的地方增加了一段逻辑进行比较,如果是 Department_DEV 就返回 Department_IT,当然如大家所想,刚给 Leader 看就被 Reject 回来了。当然如果是像上面例子这么话,这样做不会有什么问题。但坑爹的是在项目中从 config 里面读 Workstation Type 的方法,以及根据 Workstation Type 进行比较的方法分散在了很多的地方。如果按照这种方式修改的话会修改很多地方并且还不能保证全部覆盖到。而且,对以后的维护也是大大的不便呀。
Solution 2:被 Leader Reject 之后,就开始想其他的方式咯。先帮这些方法提成一个公共的方法,然后在那个公共的方法中进行修改。修改、测试好之后就去找 Leader Review了,当然,和第一次一样还是被 Reject 回来了。并不是说这种方式不对,而是在那个环境下这样做代价太大了。和 Solution 1 一样,这样修改并不能保证帮所有和 Workstation Type 相关的逻辑都找出来了,而且按这种方式修改涉及的范围太大了,因为这不仅仅影响到了 IT Department 的 Workstation。
Solution 3:好吧,我没辙了,只能求救了,结果 Leader 到我座位上只敲了一行代码,然后 DONE.....
public enum WorkstationTypeEnum
{
Department_HR,
Department_Audit,
Department_IT,
Department_DEV = Department_IT
}
都知道 Enum 默认类型是 int,按照上面的方式修改之后使得 Department_DEV 和 Department_IT 相等。在运行到 switch..case..的方法时,因为 Department_DEV 和 Department_IT 相等,所以所有的逻辑都会按照 Department_IT 方式进行,当然同样会进入 IT Department Workstation 中。
问题解决了,按照上面修改代价也是最小的,不会影响其他的 Workstation。但是吃了这种亏之后,估计以后的代码也不会这样写了,所有的 Workstation 只有一个入口,帮所有的代码都糅合在一起,给以后的维护带来了很大的不便,瑞士军刀式的代码并不是很好的实践方式。