分类目录

链接

2011年 12月
 1234
567891011
12131415161718
19202122232425
262728293031  

近期文章

热门标签

新人福利,免费薅羊毛

现在位置:    首页 > .NET > 正文
你有重构的勇气么?(二)
.NET 暂无评论 阅读(2,210)

缘起 OO 和重构

引言

记得在大学的时候, OO 思想像一首流行歌曲一样只要是学计算机的同学都会说的朗朗上口。或许会问什么是 OO 当时的大部分)会说的像唱歌一样,封装,继承,多态。或许会再问,怎么实现,会说:封装就是把属性 Get Set 隐藏实现。继承就是有个父类子类就去继承它来达到重用,多态就是指类对象动态指向父类的现象叫多态。那时候知道的 OO 都是口头上的仅此而已 .

 

记得我一个睡上铺的哥们买了几本大师级的书叫人月神话, Java 编程思想,设计模式之类的当时就鄙视他想问句你真看的懂吗?因为没有编写的代码量到一定数量,看了也是白看,因为自己也是做这行的没办法也了一两本也经常有系里的同学用鄙疑的眼神从我身边走过。那时好像自己没本那样的书都不 Fashion .

 

很多人一翻开 重构,设计模式 等就像进入了一个 “ 空中花园 ” 那么多的技巧让你感叹,会花很多时间去理解。可是一合上书,马上又进入了另一片天地,空中花园 ” 离你那么遥远,高高在上。 随着你编写的代码量达到一定高度才渐渐理解它应用场景和所解决的问题。

 

什么是重构

重构( Refactor 就是不改变软件现有功能的基础上,通过调整顺序代码改善软件的质量、性能,使其程序的设计模式和架构更趋合理,提高软件的扩展性和维护性。

 

重构的好处

显而易见的大概有这么几点 : 容易阅读,找到潜在 Bug, 提高软件效率,降低维护本钱。

 

什么时候重构 ?

三次法则
第一次做某件事时只管去做 ; 第二次做类似的事会产生反感,但无法如何还是做了 ; 第三次再做类似的事,就应该重构。

  1. 添加功能时一并重构
  2. 修补错误时一并重构
  3. 复审代码时一并重构

但软件无法正常运行或到软件交付期时不应该重构

 

 

下面是自己写代码重构遇到几个阶段

代码级重构

刚开始的时候经常 Ctrl+C 和 Ctrl+V 10 个页面就 10 个 Ctrl+V 开始的时候觉得 Ctrl+V 最节省时间的而且方便。读书的时候做个小项目练下手,但是很多地方用 Ctrl+C 和 Ctrl+V 记得最多的一次是做个权限验证,用户登录后获取该用户的权限。当该用户访问该页面时就验证该用户是否有该页面访问权限。把用户信息缓存在外地,每个页面构造函数里加验证判断,如果验证失败就跳转到提示页,当时记得有 30 个页面左右。复制 30 左右次眼睛累的不行,因为怕复制漏了或者复制错了 Ctrl+V 完后测试,去,验证规则写的有漏洞,之后每个页面一个一个改, 30 个页面啊,改完测试,没什么问题,但后来功能不能满足需求,就改 User 表,验证方式也变了没方法又要每个页面改代码。极其痛苦,血的教训!

代码级的重构还有很多如 重命名,封装字段,改善可读性 , 添加注释等重构。

 

方法级重构

知道痛了才会改变,渐渐的学会把公有的局部提取到一个方法里。方法尽量简单,功能专一以不变应万变。方法重载和省缺参数也在不同是情况下使用

 

会在工作中慢慢积累很多通用方法如分页, SqlHelper, 图片处置,随机数等,随着开发经验的增多,公用方法就会越来越多并成为自己珍贵的资源。

 

实体,结构级重构 — 继承和多态

经常在刚开始的时候我会使用继承,随着需求的变化我父类可能会添加新属性或方法,慢慢的会发现继承可能造成无限膨胀,而且子类是受害者会继承些完全不需要的东西影响性能,慢慢实体的维护修改变的异常艰难牵扯也会很多。

后来发现继承应该少用,除非在很强的父子继承关系时才用,用耦合的灵活性远远高于继承 .

个人认为多态是面向对象的核心,之前经常在实体结构中不知道何时用多态,再后来慢慢的困惑我 , 使用多态的时候是用抽象类还是接口。

 

后来我听说说面向笼统编程(面向接口编程)高内聚低耦合的思想 才找到多态的用处。慢慢的会将对象和行为分离笼统出接口实现来防止大基类的设计。把笼统或实现完全分离来应对需求的变化。

 

这我经常也会用到一些设计模式来应对变化和扩展。

 

模块级的重构

之前我可能会为页面和业务逻辑,业务逻辑和数据实例化而伤透脑筋。后才我知道为了更好组织各层开发,隔开耦合,也会采用 MVC MVP MVVM 模式或分层开发;

 

项目中为了解除各模块和组件的耦合,也会利用 IOC 思想解耦我会引入 IOC 框架;

 

此如果项目数据处理量不是特别大,为了使项目的开发速度更快且更方便,也会引入 ORM 思想来加快项目的开发速度和可维护性;

 

用户不时增加系统压力逐渐增大用户漫长的等待时,可能会考虑自己写缓存机制或引入缓存架构

 

如果我应用顺序和服务会交错,可能会考虑用 SOA 架构, WCF web servic 等

 

经常遇到困惑

系统越做越大的时候,每次开发部门接到新需求或需求变卦大家心里好像都有一些凉意,怕自己一个微小的变化所需的努力,将自己或整个项目引入错误的恐惧。或许你心里想高呼一声:上帝 , 让我重来一次吧,一定做到接近完美。呵呵,以前经常在做像这个的白日梦。重构是继续性的没有人能够把系统一次性重构非常完美的就算当时完美随着时间,需求的推移和变更,还需要重构。这种现象主要有几个原因导致的

  1. 没有勇气去重构,怕出错给自己带来没必要的麻烦。
  2. 自己昏天黑地,看其他同事逍遥快活,心理不平衡。导致自己跃跃欲试的重构计划成为虚构。
  3. 工程量太大,望而怯步。如果要大量改接口或结构的话,还是劝你重写吧。

 

重构是顺序员必然经历的过程,发展到现在书籍和工具已经有很多,重构 — 改善既有代码的设计和圣殿骑士的 31 天重构 推荐下。重构工具自己用过的除了 Vs 自带的就是 ReShap 非常棒的一个工具可以帮你分析,发现需要重构的地方。下篇说到 IOC. 未完待续 …

============ 欢迎各位老板打赏~ ===========

本文版权归Bruce's Blog所有,转载引用请完整注明以下信息:
本文作者:Bruce
本文地址:你有重构的勇气么?(二) | Bruce's Blog

发表评论

留言无头像?