欢迎访问昆山宝鼎软件有限公司网站! 设为首页 | 网站地图 | XML | RSS订阅 | 宝鼎邮箱 | 后台管理


新闻资讯

MENU

软件开发知识

后面我又觉得没必要每次打开界 图纸加密 面都要加载所有数据(那个tableview有几千行

点击: 次  来源:宝鼎软件 时间:2017-08-07

原文出处: @蛋疼的axb

假设你已经读过烂代码系列的前两篇:相识了什么是烂代码,什么是好代码,可是照旧不行制止的打仗到了烂代码(就像之前说的,险些没有措施员可以完全制止写出烂代码!)接下来的问题即是:如何应对这些身边的烂代码。

1.改进可维护性

改进代码质量是项大工程,要开始这项工程,从可维护性入手往往是一个好的开始,但也仅仅只是开始罢了。

1.1.重构的悖论

许多人把重构当做一种一次性举动,代码实在是烂的没法改了,可能没什么新的需求了,就召集一帮人专门拿出来一段时间做重构。这在传统企业开拓中几多能生效,可是对付互联网开拓来说却很难适应,原因有两个:

  1. 互联网开拓考究快速迭代,假如要做大型重构,往往需要暂停需求开拓,这个根基上很难实现。
  2. 对付没有什么新需求的项目,往往意味着项目自己已颠末尾成持久,纵然做了重构也带来不了什么收益。

这就形成了一个悖论:一方面那些改观频繁的系统更需要重构;另一方面重构又会延长开拓进度,影响改观效率。

面临这种抵牾,一种方法是放弃重构,让代码质量自然下降,直到工程的生命周期竣事,选择放弃可能重来。在某些场景下这种方法确实是有效的,可是我并不喜欢:比起让工程师不得不把天天的精神都挥霍在毫无意义的工作上,为什么不做些更有意义的事呢?

1.2.重构step by step

1.2.1.开始之前

开始改进代码的第一步是把IDE的重构快捷键设到一个顺手的键位上,这一步很是重要:抉择重组成败的往往不是你的新设计有何等牛逼,而是重构自己会占用几多时间。

好比对付IDEA来说,我会把重构菜单设为快捷键:

 后头我又以为没须要每次打开界 图纸加密 面都要加载所有数据(谁人tableview有几千行

这样在我想去重构的时候就可以随手打开菜单,而不是用鼠标逐步去点,快捷键每次只能为重构节减几秒钟时间,可是却能明明淘汰工程师重构时的心理承担,后头会提到,小局限的重构应该跟敲代码一样属于日常开拓的一部门。

我把重构分为三类:模块内部的重构、模块级此外重构、工程级此外重构。分为这三类并不是因为我是什么分类强迫症,后头会看到对重构的分类对付重构的意义。

1.2.2.随时举办模块内部的重构

模块内部重构的目标是把模块内部的逻辑梳理清楚,而且把一个庞大无比的函数拆分成可维护的小块代码。大部门IDE都提供了对这类重构的支持,雷同于:

  • 重定名变量
  • 重定名函数
  • 提取内部函数
  • 提取内部常量
  • 提取变量
  • 这类重构的特点是修改根基会合在一个处所,对代码逻辑的修改很少而且根基可控,IDE的重构东西较量结实,因而根基没有什么风险。

    以下例子演示了如何通过IDE把一个冗长的函数做重构:

     后头我又以为没须要每次打开界 图纸加密 面都要加载所有数据(谁人tableview有几千行

    上图的例子中,我们根基依靠IDE就把一个冗长的函数分成了两个子函数,接下来就可以针对子函数中的一些烂代码做进一步的小局限重构,而两个函数内部的重构也可以用同样的要领。每一次小局限重构的时间都不该该高出60s,不然将会严重影响开拓的效率,进而导致重构被无尽的开拓需求沉没。

    在这个阶段需要对现有的模块增补一些单位测试,以担保重构的正确。不外以我的履向来看,一些简朴的重构,譬喻修改局部变量名称,可能提取变量之类的重构,纵然没有测试也是根基靠得住的,假如要在快速完成模块内部重构和100%的单位测试包围率中选一个,我大概会选择快速完成重构。

    而这类重构的收益主要是提高函数级此外可读性,以及消除超大函数,为将来进一步做模块级此外拆分打好基本。

    1.2.3.一次只做一个较模块级此外的重构

    之后的重构开始牵扯到多个模块,譬喻:

  • 删除无用代码
  • 移动函数到其它类
  • 提取函数到新类
  • 修改函数逻辑
  • IDE往往对这类重构的支持有限,而且偶然会出一些莫名其妙的问题,(譬喻修改类名时一不小心把设置文件里的常量字符串也给修改了)。

    这类重构主要在于优化代码的设计,剥离不相关的耦合代码,在这类重构期间你需要建设大量新的类和新的单位测试,而此时的单位测试则是必需的了。

    为什么要建设单位测试?

  • 一方面,这类重构因为涉及到详细代码逻辑的修改,靠集成测试很难包围所有环境,而单位测试可以验证修改的正确性。
  • 更重要的意义在于,写不出单位测试的代码往往意味着糟糕的设计:模块依赖太多可能一个函数的职责太重,想象一下,想要执行一个函数却要模仿十几个输入工具,每个工具还要模仿本身依赖的工具……假如一个模块无法被单独测试,那么从设计的角度来思量,无疑是不及格的。