程式碼重構之法——方法重構分析
阿新 • • 發佈：2020-09-09
# 程式碼重構之法——方法重構分析
## Intro
想要寫出比較優秀的程式碼，需要時刻警惕程式碼中的壞味道，今天想寫一篇文章介紹一下如何分析你的方法是不是需要考慮重構
一個方法通常有三個部分組成，輸入(Input)，輸出(Output)，方法體(Method Body)，我們就從這三個方面來分析一個方法是否該考慮重構
## Input
方法輸入也就是方法的引數，通常來說一個方法的引數基本可以控制在7個以內（僅作參考，可以自己衡量，`SonarQube` 預設方法最多七個引數），如果你的方法引數過多的話，可能就需要考慮重構一個方法引數了，通常的做法是封裝一個獨立的 model，引數作為 model 的屬性。
舉一個常見的例子，比如一個新聞列表的API，起初可能很簡單，就只需要一個 `lastId`，一個 `count` 兩個引數，但是隨著業務需求的增加，可能會增加很多別的引數，比如前端提供一個 keyword 進行全文檢索，提供一個 sortBy 進行排序，根據新聞標題匹配，作者名稱匹配，分類匹配，根據釋出時間篩選等等，最後可能會導致這個方法的引數有很多
通常我會新增一個 `XxxRequest` 的 model，然後方法引數替換成這個 model，然後指定 `[FromQuery]` 就可以了，可以對比一個修改前後的差異，是不是後面的方式更清爽一些呢
``` csharp
Task List(int lastId, int count, string title, string author, string keyword, int categoryId, string sortBy, DateTime? beginTime, DateTime? endTime)
```
``` csharp
Task 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) 分支
``` csharp
void Method1(int num)
{
if(num > 0)
{
}
else if(num <0)
{
}
else
{
}
}
```
下面這個方法的複雜度是 3，`foreach` 帶來了 1 的複雜度，`if` 也是1的複雜度，但是因為 `if` 是巢狀在 `foreach` 內部的，一層巢狀會導致複雜度增加1
``` csharp
void Method1(int[] nums)
{
foreach(var num in nums)
{
if(num > 0)
{
}
}
}
```
下面這個方法的複雜度在上面的基礎上增加了兩個 `catch`，這使得複雜度會加 2，從而變成 5
``` csharp
void Method1(int[] nums)
{
try
{
foreach(var num in nums)
{
if(num > 0)
{
}
}
}
catch(InvalidOperationException e)
{
}
catch(Exception e)
{
}
}
```
更多示例可以參考官方介紹：