关于重构(二)

最近在看《重构改善既有代码设计》这本书,有些感悟分享给大家!!此感悟均自己瞎想,说的不对请见谅!!

这本书我已经看到第6章了,前5章可以简单的总结为:“为何重构?怎么重构?(重构的方法、原则)”

书中提及“事不过三、三则重构”,意思就是一个方法、函数用过3次或是多次就应该考虑重构了。

何时重构?

  1. 添加功能时:因为在某个功能基类可能在多个地方被用到,但客户有了写的需求,需要添加新的功能,但是你又不确定在基类中修改会不会影响其他的功能点,此时就应该重构。
  2. 修补错误时:这个情况和上述情况差不多,在修补这个错误时,你无法确定在修改之后会不会引起其他的错误,此时就应该重构
  3. 复审代码时:复审代码在许多公司在交付项目时都会对代码进行复审(可能大公司才不会有吧,至少我暂时没有遇到过),因为代码不可能是复审人员写的(这个应该说是一定不是开放人员去自己复审自己的代码),可能对某些代码段无法理解其功能,就应该重构。

为何重构?可以说重构的好处、优点在哪?

  1. 改善软件的设计:应为软件在最初设计时,没办法将所有的事情想的面面俱到,所以在后续的开发中就应该用重构来弥补软件设计的不足。
  2. 使软件更容易理解:重构可以让计算机明确你“要他去做什么”,更能让后来者读懂它,“后来者”?这是有人会问:“后来者,是何许人也?”这里可以明确的告诉你,一个项目、一个功能点不可以永远满足需求,后期肯能要有改动,可能是你、也可能是另一个程序员,你自己能不能保证自己以前写的程序,现在拿过来就知道其中某个方法的功能呢?这时有人会说:“能”,(我靠大哥不要来抬杠行不,我不太清楚别人,但对于我自己来说,是很难一下理解的,(这时有人说那是你笨,我只能说我比较懒),我身边的大多数程序员都比较懒)感觉有些跑题了,咱们把思路拉回来,接着说重构的优点,重构大部分是为了“后来者”去更容易去理解代码的
  3. 帮助找到BUG:因为一些代码在一起可能无法一眼看出其中的BUg或是隐藏在深处的潜在BUg,我们需要去重构
  4. 提高编程速度:大家看到这会说,上面可以理解,重构怎么会能提高编程速度呢?书上说了一套书面话,我用大白话将它“翻译”了一下,是因为我们在最初设计软件时没办法设计的非常合理,在后期可能添加新功能,我们会化大把的时间花在调试、修改、调试、修改上,首先我们要花费很长时间去了解系统、理解代码,工期就会被拖长,(时间长领导就对经理说: 怎么搞的搞了这么长时间还没弄好?这时经理就找你了说: “就一个简单的问题搞了这么长时间,还没弄好?”,你心情不好,工作带有情绪,你辞职了,又来一新员工接着做你没做完的问题,形成恶性循环,当然我们抛出公司领导的管理问题,经理的管理能力、技术能力,我们单单站在程序员的角度去看问题)

说了这么多?有人就会问什么是重构啊?要知故事如何且待下回分解!!

原文地址:https://www.cnblogs.com/ITyueguangyang/p/4193296.html