5行代码，即可让微信小程序上架到自己的APP中 | 注册送大疆、华为、樱桃键盘！>>>

方法重构分析

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

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) 分支