关闭

《重构》——如何如何改善代码

420人阅读 评论(0) 收藏 举报
分类:

 

推荐博文到论坛,
即刻奖励2积分!

代码的坏味道:

1、重复代码;
2、过长函数;
3、过大的类(C中可说过大的结构体);
4、过长参数列表;
5、发散式变化;
6、依恋情结;
7、霰弹式修改;
8、数据泥团;
9、基本类型偏执;
10、switch惊悚现身;
11、冗余类;
12、平行继承体系;
13、夸夸其谈未来性;
14、过度耦合的消息链;
15、令人迷惑的暂时字段;
16、异曲同工的类;
17、狎昵关系;
18、中间人;
19、纯稚的数据类;
20、不完美的库类;
21、过多的注释;
22、被拒绝的遗赠;
何时需要重构:
1、如果你发现自己需要为程序添加一个特性,而代码结构使你无法很方便地打成目标,那就先重构那个程序,使特性的添加比较容易进行,然后再添加特性。
2、重构之前首先检查自己是否有一套可靠的测试机制。这些测试必须有自我检验能力。
3、重构技术就是以微小的步伐修改程序。如果你犯下错误,很容易便可发现它。
4、任何一个傻瓜都能写出计算机可以理解的代码,唯有写出人类容易理解的代码,才是优秀的程序员。
5、重构:对软件内部结构的一种调整,目的是在不改变软件客观查行为的前提下,提高其可理解性, 降低其修改成本。
6、重构:使用一系列重构收发,在不改变软件可观察行为的前提下,调整其结构。
7、事不过三,三则重构。
8、不要过早发布接口,请修改你的代码所有权政策,使重构更顺畅。
9、当你感觉需要撰写注释时,请先尝试重构,试着让所有注释都变得多余。
重构中的测试:
1、确保所有测试都自动化,让它们检查自己的测试结果。
2、一套测试就是一个强大的BUG侦测器,能够大大缩减查找bug所需的时间。
3、频繁地运行测试,每次编译请记得把测试也考虑进去——每天至少执行每个测试一次。
4、每当收到BUG报告,请先写一个单元测试来暴露bug。
5、编写未臻完善的测试并实行实际运行,好过对完美测试的无尽等待。
6、考虑可能出错的边界条件,把测试火力集中在那儿。
7、当事情被认为应该会出错时,别忘了检查是否抛出了预期的异常。
8、不要因为测试无法捕捉所有bug就不写测试,因为测试的确可以捕捉到大多数bug。
重构步骤:
1、随时挑一个目标;
2、没有把握就停下来;
3、学习原路返回;
4、结对重构。
      之所以会找到重构,因为在公司接手了一个项目要将其转化为产品。由于代码是一年前写就的,之后在需要做演示的时候会对以前的代拿进行适当的增减,完成要演示的功能。但是至于代码的质量无法保证。于是要进行BUG查找与修复。
由于一开始代码经由三个人写就,中间代码风格不统一,每个人写函数的方式也不一样。
在进行BUG查找与修复的过程中要理解代码,并找到需要改正的地方。
       由于代码中风格不一,代码中全局变量使用广泛,长函数随处可见。由于没有采用统一的对齐方式,代码对齐混乱(也有可能是自己编辑器设置的缘故)。在理解代码的时候着实头疼。很多时候,都怕因为没有正确理解函数原意,造成修改的错误。在修改的过程中,也确实发生过修改过的函数执行出现了异常。
       在经过了艰难的初步修改后,能够正常使用。但是对于修改过程仍感到十分辛苦。在想怎么才能在修改代码的过程中能更好一些。在之后遇到的《代码大全》中介绍了《重构》。
       读了《重构》后,发现自己以前修改代码的过程,其中一部分在修改过程中不改变代码原意,而是使代码更容易理解以及添加新的功能的一些修改,专业点就可以说是重构。但是以前没有这个概念。里边介绍的一些方法,在修改的过程中都用到了一些。经过这里的总结,发现对重构理解加深了很多。或许这些,总需要先经历一番这个过程,才会看到重构的价值。
       在重构的过程中,如何把握重构的程度,需要大量的实践才能获得。如其作者Martin Fowler 所言“因为你还不知道何时应该使用它们,何时不应该使用;何时开始,何时停止;何时前进,何时等待。使重构成功的,不是前面各自独立的技术,而是这种节奏”。

0
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:51454次
    • 积分:985
    • 等级:
    • 排名:千里之外
    • 原创:21篇
    • 转载:33篇
    • 译文:23篇
    • 评论:1条
    文章分类
    最新评论