[转载]重构:避免重构误区

baacloud免费翻墙vpn注册使用

[转载]重构,避免重构误区 – 成长的足迹 – 博客园.

现在有太多是文章讨论各种重构的技术,咱们就不谈了,我们就谈谈要怎么重构。

一谈到重构,大家大多认为是运用设计模式,来使你的代码看上去非常优雅。其实重构包括很多,一个变量名的修改、代码格式的编排、分解一个大方法的等等都是属于重构的范畴。

我相信肯定有人和我一样,捧一本重构方面的书(《重构与模式》Joshua Kerievsky著,这本就不错),一劲的狂喊这样写代码太漂亮;可是丢开书本,面对自己的代码一直寻找可以运用设计模式、需要重构的代码,最后发现一 处可重构的都没。 写出优雅的代码,相信对于很多人来说一直是个瓶颈、很难去突破。不过突破后,你会发现你的世界变大了,犹如跳出井口的青蛙。

那我们到底才能写出那么优雅的代码呢。我们先说说,我们的重构误区吧。

误区:

1、从已有的代码寻找与书本中匹对一样或类似的场景。

2、在编写新代码时,脑子一直想着那几种模式,想去套用,一直想用上几个。

最终还是没什么好的消息,造成这样的原因是,你没真正的理解设计模式的运用场景、重构技术。

也许心里面会对自己说,这是项目比较小,没出现书本提到的那些场景。

其实重构你可以从以下几个方面入手。

1、寻找代码的坏味。 《你的代码需要重构吗?》

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、增加了系统的复杂度。

这样,如果以后我们再碰到“第一次的代码”,我们就能直接把它重构到“第三次代码”,不用经过“第二次代码”。

想想为什么我们无法写出像书本上那样的优雅的代码,那是因为我们没真正理解问题的所在、找到问题的关键点。必须先经历“第二次代码”,才能到达“第三次代码”。

赞(0) 打赏
分享到: 更多 (0)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

微信扫一扫打赏