重构，走出重构误区
现在有太多是文章讨论各种重构的技术，咱们就不谈了，我们就谈谈要怎么重构。
一谈到重构，大家大多认为是运用设计模式，来使你的代码看上去非常优雅。其实重构包括很多，一个变量名的修改、代码格式的编排、分解一个大方法的等等都是属于重构的范畴。
我相信肯定有人和我一样，捧一本重构方面的书（《重构与模式》Joshua Kerievsky著，这本就不错），一劲的狂喊这样写代码太漂亮；可是丢开书本，面对自己的代码一直寻找可以运用设计模式、需要重构的代码，最后发现一处可重构的都没。 写出优雅的代码，相信对于很多人来说一直是个瓶颈、很难去突破。不过突破后，你会发现你的世界变大了，犹如跳出井口的青蛙。
那我们到底才能写出那么优雅的代码呢。我们先说说，我们的重构误区吧。
误区：
1、从已有的代码寻找与书本中匹对一样或类似的场景。
2、在编写新代码时，脑子一直想着那几种模式，想去套用，一直想用上几个。
最终还是没什么好的消息，造成这样的原因是，你没真正的理解设计模式的运用场景、重构技术。
也许心里面会对自己说，这是项目比较小，没出现书本提到的那些场景。
其实重构你可以从以下几个方面入手。
2、review自己的代码，如果觉得不好的地方就想想有没有更好的方法。可以拿出来和别人讨论，相信你一定有不一样的收获。
3、让别人review自己的代码。在团队开发中，难免其他队员开发的功能，会和你这边的模块有关联，当有队员来问你这个函数实现什么功能、这段代码的什么意思。
这有可能以下的原因：a、自己写的代码太烂！ b、队员的技术太菜，看不懂。 c、队员较懒，不想去看。
在给他解释时，你就要注意你们的对话，对你重构是有帮助的。
队员：我不懂你这个变量是干什么的。
你就要想想，自己写变量命名不规范？
队员：你这段太长了，看得我头痛。
也是你的函数真的太长了，该修剪你的代码了，把这个大功能，分割为几个小功能。
4、阅读别人的代码。你可以阅读一些比较经典的开源代码，这样你可以和很多人一起讨论。在阅读时，要认认真真的看，读懂它的框架，渗透理解它的各个细节。
下面我举一个我在现实开发中碰到的一个问题：
第一次代码：
1 public class OrderSync
2 {
3 //订单状态，Created、Closee、Dealing、Paying、Posting
4 public string Status;
5 public void Sync()
6 {
7 OrderRequest req=new OrderRequest();
8 req.Status=Status;
9
10 req.Search();
11 ...
12 }
13 }
14
15 OrderSync orderSync=new OrderSync();
16 orderSync.Status = "Created";
缺点：
1、不清楚订单有哪几种状态。
2、如果“Created”，改成为“Create”，需要修改所有的地方，那你就开始寻找吧。
3、orderSync.Status = "Created";不小心写成orderSync.Status = "Created1111";只能单独纳闷为什么无法查询到记录。
第二次代码：
1 public class OrderSync
2 {
3 //订单状态，Created、Closed、Dealing、Paying、Posting
4 public string Status;
5 public void Sync()
6 {
7 OrderRequest req = new OrderRequest();
8 req.Status=Status;
9
10 req.Search();
11 ...
12 }
13 }
14
15 public class OrderStatu
16 {
17 public static string Created = "Created";
18 public static string Closed = "Closed";
19 public static string Dealing = "Dealing";
20 public static string Paying = "Paying";
21 public static string Posting = "Posting";
22 }
23
24 OrderSync orderSync = new OrderSync();
25 orderSync.Status = OrderStatu.Created;
此次重构解决了第一次的3个缺点。但它还是有缺点的：
1、在OrderSync中Status是字符串的，没相应的格式来限制。若你的团队来了一个新的成员，他对此系统不是很熟悉，他就有可能这么写： OrderSync orderSync = new OrderSync(); orderSync.Status = "Created";
第三次代码：
1 public class OrderSync
2 {
3 public OrderStatu Status;
4 public void Sync()
5 {
6 OrderRequest req=new OrderRequest();
7 req.Status = OrderStatuHelper.GetStatu(Status);
8
9 req.Search();
10 ...
11 }
12 }
13
14 public enum OrderStatu
15 {
16 Created,
17 Closed,
18 Dealing,
19 Paying,
20 Posting
21 }
22
23 public class OrderStatuHelper
24 {
25 private static string Created = "Created";
26 private static string Closed = "Closed";
27 private static string Dealing = "Dealing";
28 private static string Paying = "Paying";
29 private static string Posting = "Posting";
30
31 public static string GetStatu(OrderStatu orderStatu)
32 {
33 switch(orderStatu)
34 {
35 case OrderStatu.Closed:
36 return Closed;
37 case OrderStatu.Dealing:
38 return Dealing;
39 case OrderStatu.Payding:
40 return Pading;
41 case OrderStatu.Posting:
42 return Posting;
43 default:
44 return Created;
45 }
46 }
47 }
这样在给订单赋值时，只能从OrderStatu去选择状态，避免了第二次的缺点。
当然了它也是有缺点的：
1、性能相对于第一次不是很高。（在性能差的系统中，这往往不是影响系统性能的主要原因）
2、增加了系统的复杂度。
这样，如果以后我们再碰到“第一次的代码”，我们就能直接把它重构到“第三次代码”，不用经过“第二次代码”。
想想为什么我们无法写出像书本上那样的优雅的代码，那是因为我们没真正理解问题的所在、找到问题的关键点。必须先经历“第二次代码”，才能到达“第三次代码”。
PS：很高兴得到大家的积极回复、讨论。
对于“第三次代码”中的OrderStatusHelper560889223又再次重构，我个人觉得是一段很精彩的代码，把它在这，提供大家参考。
1 public class OrderStatuHelper
2 {
3 private static readonly Dictionary<OrderStatu, string> enum2string;
4
5 static OrderStatuhelper
6 {
7 enum2string = new Dictionary<OrderStatu, string>();
8 enum2string[OrderStatu.Created] = "Created";
9 enum2string[OrderStatu.Closed] = "Closed";
10 enum2string[OrderStatu.Dealing] = "Dealing";
11 enum2string[OrderStatu.Paying] = "Paying";
12 enum2string[OrderStatu.Posting] = "Posting";
13 }
14
15 public static string GetStatu(OrderStatu orderStatu)
16 {
17 string statuString;
18 return enum2string.TryGetValue(orderStatu, out statuString) ? statuString : enum2string[OrderStatu.Created];
19 }
20 }
