当前位置:网站首页>代码重构之法——方法重构分析

代码重构之法——方法重构分析

2020-11-06 21:35:08 程序猿欧文

方法重构分析

代码重构之法——方法重构分析

Intro

想要写出比较优秀的代码,需要时刻警惕代码中的坏味道,今天想写一篇文章介绍一下如何分析你的方法是不是需要考虑重构

一个方法通常有三个部分组成,输入(Input),输出(Output),方法体(Method Body),我们就从这三个方面来分析一个方法是否该考虑重构

Input

方法输入也就是方法的参数,通常来说一个方法的参数基本可以控制在7个以内(仅作参考,可以自己衡量,SonarQube 默认方法最多七个参数),如果你的方法参数过多的话,可能就需要考虑重构一个方法参数了,通常的做法是封装一个独立的 model,参数作为 model 的属性。

举一个常见的例子,比如一个新闻列表的API,起初可能很简单,就只需要一个 lastId,一个 count 两个参数,但是随着业务需求的增加,可能会增加很多别的参数,比如前端提供一个 keyword 进行全文检索,提供一个 sortBy 进行排序,根据新闻标题匹配,作者名称匹配,分类匹配,根据发布时间筛选等等,最后可能会导致这个方法的参数有很多

通常我会新增一个 XxxRequest 的 model,然后方法参数替换成这个 model,然后指定 [FromQuery] 就可以了,可以对比一个修改前后的差异,是不是后面的方式更清爽一些呢

Task<IActionResult> List(int lastId, int count, string title, string author, string keyword, int categoryId, string sortBy, DateTime? beginTime, DateTime? endTime)
Task<IActionResult> List([FromQuery]NewsListQueryRequest request)

Output

Output 就是方法的返回值,尽可能返回具体的类型,尽可能避免使用 Tuple 等类型,方法的返回值应该具有明确的意义

使用具体的 Model 代替 Tuple 返回值,尤其是一些 public 的,要被外部访问的方法更应该返回具体的类型,虽然 C# 7.2 开始支持了 named tuple,会比之前友好很多,支持给 tuple 指定名称,但是这只是编译器级别的,实际还是 Item1,Item2 ...,还是比较推荐使用具体的 model,更加明了

Body

通常一个方法不要太长,曾经在群里看到群友吐槽一个方法两千多行,这样的方法维护起来简直就是灾难,不要让一个方法太长,保持方体体的简单,一些通用的逻辑通过 Filter 或结合 AOP 来实现

Sonar 有一个分析方法复杂度的一个方法,官方称之为 Cognitive Complexity

简单介绍一下,代码里的 if/switch/for/foreach/try...catch/while 都会增加方法的复杂度,出现一层嵌套则复杂度再加1, Sonar 默认的一个方法的复杂度不能超过 15

来几个简单的示例:

下面这个方法的复杂度是 3,有三个 if(else) 分支

版权声明
本文为[程序猿欧文]所创,转载请带上原文链接,感谢
https://my.oschina.net/mikeowen/blog/4554128