[學習筆記] 重構使用 Introduce Variable for Substring

要知道的事

  • 這是個人的學習記錄
  • 可能對你沒幫助
  • 不知不知最可怕。快不起來,因為你不覺得慢
  • 希望對你有幫助
  • 使用 Visual Studio & ReSharper

問題

把原本的程式
string url = “http://localhost:5000/api/v3.3/refund/PayPal/SF188964T"

變成下面這樣

string domain = “http://localhost:5000";
string code = “SF188964T”;
string payType = “PayPal”;
string url = $”{domain}/api/refund/{payType}/{code}”;

你會怎麼作 ?

我原本的作法,一個字一個挖出來,命名變數,再填回去。

怎麼作可以更快 ?

透過 Resharper 的 Refactor > Introduce Variable > Introduce Variable for Substring 即可快速重構。

參考 91 的影片

我實測原本的開發時間約為2~3分鐘,善用工具約可以在 30 ~ 45 s 完成。
效能提昇 400 % !!!!!(聽起來就很威)

當然結合了 Vim 與 Visual Studio 的工具才達到這樣的速度,強烈推薦以下課程。

我只推薦好東西

【極速開發+】 202002 第九梯次 台北

課程優點

  1. 學心法也學作法,不是只有理論的打高空
  2. 認識同好 ,來上課的同學都是願意精進自已的人,所以身上有很多寶可以挖
  3. 認識 91 ,遇到 91 盡量挖就對了,偷到一招半式都完勝 10 年在那邊處理 NullReferenceException
  4. 學習怎麼學習

其它本周學習事項

  1. 可以讓中斷點停留在 lambda express 中
  2. MSTest 請用 DescriptionAttribute 加入測試描述
  3. .Net MVC Model Binding 若欄位為空字串預設為轉為 Null

本周待確認事項

  1. 如何對 HttpClient 測試 ?
  2. 如何用 FluentValidation 作測試 ?

(fin)

[實作筆記] Stripe 串接

Agenda

  • Stripe 簡介
  • 註冊
  • 付款

Stripe 簡介

Stripe是一家提供讓個人或公司在網際網路上接受付款服務的科技公司。
Stripe提供在網上接受付款所需的技術、避免信用卡詐騙技術及銀行基礎設施

– 引述自 Wiki

Our mission is to increase
the GDP of the internet

– 引述自 Stripe 官網

業務範圍大多為歐美,亞洲方面支援香港、新加坡與日本等國…

註冊

只需要透過信箱即可註冊, 註冊後需要到信箱收取確認信以開通帳戶,
如果真的要在線上使用需要提供公司相關的資訊,
但以開發者而言,此時的 Stripe 已經提供一組測試 api 供你使用,
隨後即可以登入後台操作。
請在 Dashboard 的左邊側欄>開發者>API 密鑰,取得Secret key
在後面呼叫 API 中都會使用這組 Secret Key 請特別留意。

付款

這裡只介紹 Stripe 信用卡的付款方法,
並根據 Stripe 文件整理一些資訊給大家。

如下圖,這是一個標準的 Stripe 結帳流程,
stripe overview

主要的兩個步驟在 Create SourceCreate Charge
這裡會透過呼叫 Stripe API 以完成付款流程。

下面會介紹幾種信用卡的付款方式, 僅供參考,實際作業請以最新的 Stripe 文件為準。
過程中如有呼叫 API 都會用 curl 帶過,
Secret Key 一律以 sk 表示, Public Key 以 pk 表示
Stripe 有提供多種語言的範例或是提供 SDK 或 Libary, 請親自去看它們的文件囉。

使用 Checkout Session

Step 1. 建立 Session

1
2
3
4
5
6
7
8
9
10
11
curl https://api.stripe.com/v1/checkout/sessions \
-u sk_test_dAa6L6BL4gZDuscgJcl3an8K00aJL2yIaW: \
-d payment_method_types[]=card \
-d line_items[][name]=T-shirt \
-d line_items[][description]="Comfortable cotton t-shirt" \
-d line_items[][images][]="https://example.com/t-shirt.png" \
-d line_items[][amount]=500 \
-d line_items[][currency]=hkd \
-d line_items[][quantity]=1 \
-d success_url="https://example.com/success" \
-d cancel_url="https://example.com/cancel"

Step 2. 建立 CheckOut 頁面

Step 1 會取得一組 session_id ,請填入頁面中的{session_id}pk 請填入 public key

1
2
3
4
5
6
7
8
9
10
11
12
13
14
<script src="https://js.stripe.com/v3/"></script>
<script>
var stripe = Stripe('pk');
stripe.redirectToCheckout({
// Make the id field from the Checkout Session creation API response
// available to this file, so you can provide it as parameter here
// instead of the {{CHECKOUT_SESSION_ID}} placeholder.
sessionId: '{session_id}'
}).then(function (result) {
// If `redirectToCheckout` fails due to a browser or network
// error, display the localized error message to your customer
// using `result.error.message`.
});
</script>

Step 3. 載入頁面

調整你的付款流程,引導消費者到 Step 2. 的頁面,
會自動轉導到 Stripe 的標準頁,並且出現填寫信用卡的資訊,
消費者需要手動輸入卡號後,確認付款。
如果確認會引導至 Step 1 的 success_url
消費者取消的話會引導至 Step 1 的 cancel_url

說明

這是標準的第三方串接步驟,可以發現在 Step 3 的時候,
消費者會被帶離你原本的站台到 Stripe 的付款頁面,
這樣的好處是你不需要經手敏感的資料,像是信用卡卡號,
但是有時候,轉導到外部頁面會讓消費者不安進而中斷結帳,
那我們可以參考其它的作法。

使用 Source

一般來說,Source 是 Stripe 最常用的付款方式,
但在歐洲相關規定調整後,信用卡不再建議使用這個 API。
可以參考官方文件的說明

Card Payments with Sources
Use Sources to accept card payments from around the world.

Use of this API is no longer recommended. We recommend adopting the Payment Intents API.
This new integration lets you benefit from Dynamic 3D Secure and helps you prepare for
Strong Customer Authentication regulation in Europe.

不過理論上您的客戶中沒有歐洲人的話,還是可以呼叫這個 API ,
作法如下:

Step 1. Create Source 並指定 Type 為 Card

1
2
3
4
5
6
7
8
9
curl https://api.stripe.com/v1/sources
-u sk
-d type=card
-d currency=hkd
-d owner[email]="[email protected]"
-d card[number]={{cardNumber}}
-d card[exp_month]=12
-d card[exp_year]=2020
-d card[cvc]=123

Step 2. Charge With Source

Step 1 可以取得 source id,利用 source id 呼叫 charge API 付款

1
2
3
4
5
6
7
8
curl https://api.stripe.com/v1/charges
-u sk
-d source={{source id}}
-d amount=411
-d currency=hkd
-d description="Charge for [email protected]"
-d metadata[a]="b"
-d metadata[b]=123

使用 Token

不過 Sorce 信用卡在官方文件上不再被建議使用,
我們可以看看另一個類似的方法 Token

Step 1. Create Token 並傳入卡號

1
2
3
4
5
6
curl https://api.stripe.com/v1/tokens
-u sk
-d card[number]={{cardNumber}}
-d card[exp_month]=12
-d card[exp_year]=2020
-d card[cvc]=123

Step 2. Charge With Token

Step 1 可以取得 token id,利用 source id 呼叫 charge API 付款

1
2
3
4
5
6
7
8
curl https://api.stripe.com/v1/charges
-u sk
-d source={{token id}}
-d amount=412
-d currency=hkd
-d description="Charge for [email protected]"
-d metadata[a]="c"
-d metadata[b]=663

使用 Payment Intent

終於來到 Payment Intent 了,
實際上這是目前 Stripe 最推薦的信用卡支付方式,
呼叫的作法也很類似於 Source 與 Token,
沒什麼特別考量的話,建議使用這個付款方式。

Step 1. Create Payment Method 並傳入卡號

1
2
3
4
5
6
7
8
curl https://api.stripe.com/v1/payment_methods
-u sk
-X POST
-d type=card
-d card[number]={{cardNumber}}
-d card[exp_month]=12
-d card[exp_year]=2020
-d card[cvc]=123

Step 2. Create Payment Intent With Payment Method

Step 1 可以取得 payment method id,
利用 payment method id 呼叫 payment intents API 付款

1
2
3
4
5
6
7
curl https://api.stripe.com/v1/payment_intents  
-u sk
-d payment_method={{payment method id}}
-d amount=555
-d currency=hkd
-d confirmation_method=manual
-d confirm=true

小結

想快速成立訂單請用 Session 的作法,
想要避免轉換率下降,請使用 Payment Intents。

參考

(fin)

[實作筆記] 讓 SonarQube 檢查你的代碼

前情提要

  1. SonarQube 是一個開源的代碼品質(Quality)管理系統
  2. 我目前的公司 N 社是自架 SonarQube Server 再與 CI 結合
  3. 能夠透過工具讓代碼品質提昇,我訂定的目標如下
    • 免費
    • 能夠與 CI 結合,持續檢查代碼品質
    • 與 Side Project 結合

應該要知道的事

  1. 掃瞄環境為 Windows
  2. 掃瞄專案為 .Net Core 2.2 版
  3. 使用 PowerShell 執行 Command
  4. 也許不需要知道

實作筆記

  1. 申請SonarCloud帳號,我直接使用 Github
    • 需要允許 SonarCloud 存取 Github 的專案 Repo
    • 建立一組 Token, 用來作身份驗証,可以重複使用請勿外流
      • 如果要刪除 Token 請至 My Account > Security 找到並 Revoke
        建立 token
        建立 token2
    • 下載 SonarQube 執行檔,請選擇你的語言
      執行命令
  2. 執行掃瞄前的準備作業
    • 設定 Path (實務上我沒有設定)
    • 切換到專案目錄底下
  3. 啟動掃瞄,以 .Net Core 為例
1
> dotnet "{path of sonar scanner}\SonarScanner.MSBuild.dll" begin /k:"{project name}" /o:{group name} /d:sonar.host.url="https://sonarcloud.io" /d:sonar.login="{your token}"

輸出結果

1
2
3
4
Using the .NET Core version of the Scanner for MSBuild
Pre-processing started.
中略...
16:40:31.855 Pre-processing succeeded.
  1. 建置專案
1
dotnet build

輸出結果

1
2
3
4
Microsoft (R) Build Engine version 15.9.20+g88f5fadfbe for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.
中略...
Build succeeded.
  1. 上傳結果
1
> dotnet "{path of sonar scanner}\SonarScanner.MSBuild.dll" end /d:sonar.login="{your token}"

輸出結果

1
2
3
4
5
6
7
8
9
10
11
12
SonarScanner for MSBuild 4.6.1
Using the .NET Core version of the Scanner for MSBuild
Post-processing started.
中略...
INFO: Analysis total time: 21.446 s
INFO: ------------------------------------------------------------------------
INFO: EXECUTION SUCCESS
INFO: ------------------------------------------------------------------------
INFO: Total time: 2:27.021s
INFO: Final Memory: 24M/72M
INFO: ------------------------------------------------------------------------
The SonarQube Scanner has finished

最後到 SonarCloud 的網站上就可以看到報告結果,
下一步就是將這整段流程結合 CI ,官網推薦是使用 Travis CI,
也有相同的文件與資源,我會試試看或是使用 Jenkins,
如果有機會能更進一步,我想結合 OpenShift ,
讓部署的過程中結合代碼品質檢查。

結果上傳

參考

[實作筆記] Unit Testing With TypeScript

前情提要

  • 難得有機會寫前端的東西
  • 其實只有寫 JavaScript
  • 我要用 TypeScript 寫
  • 合理的軟體工序 TDD
  • 所以我要寫測試
  • node 版本 v8.11.1
  • npm 版本 5.6.0
  • typescript 版本 3.3.3333

Context & User Stories

來自前端的需求,在一個日曆工具要加入對可選日期判斷的邏輯。
原始需求如下,g、h、i、j 可以透過修改日曆元件選項調整,
而細微的日期與時間判斷需要撰寫新的方法作判斷。

原始需求

a. 每週一過中午12點不能選週二及以前的日期
b. 每週二過中午12點不能選週三及以前的日期
c. 每週三過中午12點不能選週四及以前的日期
d. 每週四過中午12點不能選週五及以前的日期
e. 每週五過中午12點不能選隔週一及以前的日期
f. 每週日都不能選
g. 90天以後的日期不能選
h. 需指導我們如何讓特定日期不能選,以因應遇到國定假日的狀況
i. 預設為選擇最近一個可以使用的日期
j. 改成中文

測試環境準備

使用 Mocha 與 Chai

1
npm i -D chai mocha nyc ts-node typescript

安裝 TypeScript

安裝至專案

1
$ npm i -D typescript ts-node

安裝至全域

1
$ npm i -g typescript

建立專案 tsconfig.json

1
$ tsc --init

安裝 MochaJs

1
npm i -D mocha @types/mocha

安裝 Chai

1
npm i -D Chai @types/chai

設定測試

package.json\

1
2
3
"scripts":{
"test": "mocha -r ts-node/register tests/**/*.test.ts",
}

寫測試

1
2
3
4
5
6
7
8
9
import { expect } from 'chai';
import Calculator from '../src/calculate';

describe('calculate', function() {
it('add', function() {
let result = Calculator.Sum(5, 2);
expect(result).equal(7);
});
});

實作代碼

1
2
3
4
export default class calculator {
static Sum(a: number, b: number): number {

}

執行測試

1
npm t

修正代碼

1
2
3
4
5
export default class calculator {
static Sum(a: number, b: number): number {
let c = a + b;
eturn c;
}

測試結果

1
2
3
4
5
calculate
√ add


1 passing (61ms)

測試覆蓋率

// TODO

安裝 nyc

1
npm i -D nyc

設定 scripts

1
2
3
"scripts":{    
"testCover": "nyc -r lcov -e .ts -x \"*.test.ts\" mocha -r ts-node/register tests/**/*.test.ts && nyc report",
}

執行

1
> npm run testCover

執行結果

1
2
3
4
5
6
7
8
9
10
11
12
略過測試部份
------------------------|----------|----------|----------|----------|-------------------|
File | % Stmts | % Branch | % Funcs | % Lines | Uncovered Line #s |
------------------------|----------|----------|----------|----------|-------------------|
All files | 100 | 100 | 98.63 | 100 | |
src | 100 | 100 | 87.5 | 100 | |
Calculator.ts | 100 | 100 | 100 | 100 | |
beforeShowDay.ts | 100 | 100 | 80 | 100 | |
tests | 100 | 100 | 100 | 100 | |
beforeShowDay.test.ts | 100 | 100 | 100 | 100 | |
calculator.test.ts | 100 | 100 | 100 | 100 | |
------------------------|----------|----------|----------|----------|-------------------|

完整 Test Cases

今天是 2019/3/30 號星期六 12:05
√ 日曆上 2019/4/02 星期二 出貨 可以選
√ 日曆上 2019/4/02 星期二 設定為國定假日, 出貨 不可以選

今天是 2019/3/24 號星期日 12:05
√ 日曆上 2019/3/25 星期一 出貨 不可以選
√ 日曆上 2019/3/26 星期二 出貨 可以選

今天是 2019/3/23 號星期六 12:05
√ 日曆上 2019/3/25 星期一 出貨 不可以選
√ 日曆上 2019/3/26 星期二 出貨 可以選

今天是 2019/3/22 號星期五 23:05
√ 日曆上 2019/3/25 星期一 出貨 不可以選
√ 日曆上 2019/3/26 星期二 出貨 可以選

今天是 2019/3/21 號星期四 01:30
√ 日曆上 2019/3/21 星期四 出貨 不可以選
√ 日曆上 2019/3/22 星期五 出貨 可以選

今天是 2019/3/22 號星期五 23:05
√ 日曆上 2019/3/25 星期一 出貨 不可以選
√ 日曆上 2019/3/26 星期二 出貨 可以選

今天是 2019/3/19 號星期二 23:05
√ 日曆上 2019/3/21 星期四 出貨 可以選

今天是 2019/3/22 號星期五 12:59
√ 日曆上 2019/3/22 星期五 出貨 不能選,因為現在時間超過 12 點
√ 日曆上 2019/3/25 星期一 出貨 不能選,因為現在時間超過 12 點
√ 日曆上 2019/3/26 星期二 出貨 可以選
√ 日曆上 2019/4/1 星期一 出貨 可以選
√ 日曆上 2019/3/23 星期六 出貨 不能選,因為現在時間超過 12 點

今天是 2019/3/21 號星期四 23:59
√ 日曆上 2019/3/21 星期四 出貨 不能選,因為現在時間超過 12 點

今天是 2019/3/18 號星期一12:00
√ 日曆上 2019/3/18 星期一 出貨 不能選,因為現在是12點
√ 日曆上 2019/3/19 星期二 出貨 不能選,因為現在是12點
√ 日曆上 2019/3/20 星期三 出貨 可以選
√ 日曆上 2019/3/21 星期四 出貨 可以選

今天是 2019/3/18 號星期一10:00
√ 日曆上 2019/3/24 星期日 出貨;不能選,因為週日都不能選
√ 日曆上 2019/3/18 星期一 出貨 不可以選,因為當天不能選
√ 日曆上 2019/3/19 星期二 出貨 可以選
√ 日曆上 2019/3/20 星期三 出貨 可以選

心得

能堅持「工序」是專業人士的表現,
我相信這是一種實務上能保持品質與速度的作法。
特別是越大規模越複雜的專案,
避免掉進焦油坑的方法就是一開始就別踩下去。

寫測試案例也是一種技能,在這次的 Case 中,
E2E測試是相對困難的,受限於時間與日期,
單元測試可以控制時間反而成了絕妙的工具。

我一開始寫的測試並不優良,涵蓋的情境不夠(註:這裡並非指程式碼的函蓋率),
但是與 PO 反覆確認之後,調試出的情境終於滿足了需求,
看來我還要增進一下寫測試案例的能力。

最後,下次再試試用 Jest 寫寫看。

參考

(fin)

[實作筆記] ASP.NET 專案部署地雷-消失的靜態檔

應該知道的事

  • 這個是 Debug 的筆記
  • 用的是 .Net Framework 4.6 不是 .Net Core
  • 對你可能沒有幫助

問題

方案裡面有三個 Web 專案 Web1 、Web2 、Web3,
因開發某功能需要加入一個文字靜態檔 Iamfile.txt
在部署的時候卻無法將檔案部署至網站根目錄。

誤解

對檔案按右鍵 > 屬性 > 複製的輸出目錄 > 下拉選取一律複製。

很可惜,這個設定的調整會讓這個檔案在建置的時候輸出到指定資料夾中( Ex: \bin ),
這個操作會影響 csproj 如下:

1
2
3
<None Include="Iamfile.txt">
+ <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
</None>

正解

注意 Tag 的名稱為 None,需要調整為 Content, 目前不確定如何用 IDE 操作。

1
<Content Include="Iamfile.txt" />

補充

找到你的 MSBuild 版本

1
cd C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\15.0\Bin 

執行建置

1
λ MSBuild.exe D:\Projects\IsASolution.sln /p:Configuration=QA;DeployOnBuild=true;PublishProfile=Mall.QA.pubxml;MvcBuildViews=false;AutoVersion=True

執行後輸出的位置需要看你的部署檔 *.pubxml 如下範例
可以在 D:\Archives\QA\IsASolution 找到我的輸出。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
<?xml version="1.0" encoding="utf-8"?>
<!--
此檔案是由您 Web 專案的發行/封裝處理程序所使用。您可以編輯此 MSBuild 檔案,
以自訂此處理程序的行為。若要深入了解,請造訪 http://go.microsoft.com/fwlink/?LinkID=208121。
-->
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<WebPublishMethod>FileSystem</WebPublishMethod>
<LastUsedBuildConfiguration>QA</LastUsedBuildConfiguration>
<LastUsedPlatform>Any CPU</LastUsedPlatform>
<SiteUrlToLaunchAfterPublish />
<ExcludeApp_Data>False</ExcludeApp_Data>
<publishUrl>D:\Archives\QA\IsASolution</publishUrl>
<DeleteExistingFiles>True</DeleteExistingFiles>
<PrecompileBeforePublish>True</PrecompileBeforePublish>
<EnableUpdateable>True</EnableUpdateable>
<DebugSymbols>False</DebugSymbols>
<WDPMergeOption>DonotMerge</WDPMergeOption>
</PropertyGroup>
</Project

(fin)

[實作筆記] ASP.Net Core Logger

要知道的事

  • 這是個人的學習記錄
  • 可能對你沒幫助
  • 網路上資訊很多
  • 希望對你有幫助

概念

Asp.Net Core 的 Life Cycle 由 Program.csmain 方法開始(是的,就如同其它一般的程式),
WebHostBuilder 中的 ConfigureLogging 可以提供彈性讓你設定屬於你的 LoggerProvider,
不論是微軟提供、知名的第三方套件或是你手工自已刻一個,大致你的程式碼會如下

1
2
3
4
5
6
7
8
9
10
public static IWebHostBuilder CreateWebHostBuilder(string[] args) =>
WebHost.CreateDefaultBuilder(args)
.ConfigureLogging(logging=>
{
logging.ClearProviders();
logging.AddEventLog();
logging.AddFile("D:\\Temp\\Log.txt");
logging.AddConsole();
})
.UseStartup<Startup>()

而在 Controller 或其它 Module 間,你只要透過建構子注入 logger 實體就可以實現 log 的功能

1
2
3
4
public HomeController(ILogger<HomeController> logger)
{
this._logger = logger;
}

預設的行為

如果你沒有呼叫 ConfigureLogging 預設的行為如下述.

The default project template calls CreateDefaultBuilder, which adds the following logging providers:

  • Console
  • Debug
  • EventSource (starting in ASP.NET Core 2.2)
1
2
3
4
5
6
7
8
public static void Main(string[] args)
{
CreateWebHostBuilder(args).Build().Run();
}

public static IWebHostBuilder CreateWebHostBuilder(string[] args) =>
WebHost.CreateDefaultBuilder(args)
.UseStartup<Startup>();

Find the Logs

Console

範例說明:在建構子中注入 ILogger 實體,運行網站後連到 Home\Index 頁面,並觀察 Console

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
public class HomeController : Controller
{
private readonly ILogger _logger;

/// <summary>
/// Initializes a new instance of the <see cref="HomeController" /> class.
/// </summary>
public HomeController(ILogger<HomeController> logger)
{
this._logger = logger;
}

public IActionResult Index()
{
this._logger.Log(LogLevel.Information,"HomeController Information");
this._logger.Log(LogLevel.Critical,"HomeController Critical");
this._logger.Log(LogLevel.Debug,"HomeController Debug");
this._logger.Log(LogLevel.Error,"HomeController Error");
this._logger.Log(LogLevel.None,"HomeController None");
this._logger.Log(LogLevel.Trace,"HomeController Trace");
this._logger.Log(LogLevel.Warning,"HomeController Warning");
return View();
}
}

結果如下,可以發現 LogLevel.NoneLogLevel.TraceLogLevel.Warning 並未出現在 Console 資訊當中

1
2
3
4
5
6
7
8
info: Marsen.NetCore.Site.Controllers.HomeController[0]
HomeController Information
crit: Marsen.NetCore.Site.Controllers.HomeController[0]
HomeController Critical
dbug: Marsen.NetCore.Site.Controllers.HomeController[0]
HomeController Debug
fail: Marsen.NetCore.Site.Controllers.HomeController[0]
HomeController Error

LogLevel說明了 None 的意義就是不記錄任何訊息,

Enum Level Description
Trace 0 Logs that contain the most detailed messages. These messages may contain sensitive application data. These messages are disabled by default and should never be enabled in a production environment.
Debug 1 Logs that are used for interactive investigation during development. These logs should primarily contain information useful for debugging and have no long-term value.
Information 2 Logs that track the general flow of the application. These logs should have long-term value.
Warning 3 Logs that highlight an abnormal or unexpected event in the application flow, but do not otherwise cause the application execution to stop.
Error 4 Logs that highlight when the current flow of execution is stopped due to a failure. These should indicate a failure in the current activity, not an application-wide failure.
Critical 5 Logs that describe an unrecoverable application or system crash, or a catastrophic failure that requires immediate attention.
None 6 Not used for writing log messages. Specifies that a logging category should not write any messages.

Log 的作用範圍會受 appsettings.json 影響,
另外要注意 appsettings.json 的載入順序.

1
2
3
4
5
6
"Logging": {
"LogLevel": {
"Default": "Trace",
"System": "Information",
"Microsoft": "Information"
}

Debug

如同 Console 的行為一般,可以在 Visual Studio 的輸出(Output)>偵錯(Debug)視窗中,查詢到記錄。

EventSource

如同官方文件所說,我下載了 PerfView
如下圖作了設定,
PerfView
不過我並沒有取得記錄,
PerfView Log

錯誤訊息如下
EventSource Microsoft-Extensions-Logging: Object reference not set to an instance of an object
暫時不打算深追查,
ETW 可以記錄的 Memory 、Disc IO 、CPU 等資訊,
其實與我想要的應用程式記錄有所差異,稍稍記錄一下以後也許用得到。
如果有人能留言給我一些方向,也是非常歡迎。

自訂 Filelog 與 EventLog

調整一下程式

1
2
3
4
5
6
7
8
public static IWebHostBuilder CreateWebHostBuilder(string[] args) =>
WebHost.CreateDefaultBuilder(args)
.ConfigureLogging(logging=>
{
logging.AddEventLog();
logging.AddFile("D:\\Temp\\Log.txt");
})
.UseStartup<Startup>()

這裡我使用 Microsoft.Extensions.Logging.EventLog 處理 EventLog 可以在 Event View 中看見記錄;
而 file log 我使用 Serilog.Extensions.Logging.File , 特別要注意以下兩點

  • Nuget 使用的版本為 2.0.0 以上版本,目前仍然不是穩定版本
  • AddFile 傳入的是記錄檔的完整 Path 而非目錄

自訂 Elmah

Elmah 在 Net 算是一個蠻方便的工具,有提供簡易介面、可以選擇用 File 或是 Database 方式作 Logging,
更重要是小弟我用了 4 年,順手就研究一下。

設定相當簡單, 在 Startup.csConfigureServices 加入

1
2
3
4
5
6
services.AddElmah<XmlFileErrorLog>(options =>            
{
//options.CheckPermissionAction = context => context.User.Identity.IsAuthenticated;
//options.Path = @"elmah";
options.LogPath = "D:\\Temp\\elmah";
})

Configure 加入

1
app.UseElmah();

要注意是使用 XmlFileErrorLog 時,要設定的 options 是 LogPath 而非 Path, 其實使用 File 只能說是開發環境的暫時處置,真正的 Prodction 應該將 Log 放到專門的 Database 或是 Cloud Service 之中,
在這裡可以看見 Elmah 的行為與 Net Core 的行為並不一致,Log 與錯誤記錄本來就不該混為一談。
我想我要調整一下我的想法了,不過關於 Log 暫時就到此為止。

參考

(fin)

[閱讀筆記] 重構---改善既有程式的設計,第一章

為什麼

知道自已不知道

上次在公司內部開始進行 Coding Dojo,在 FizzBuzz 的 Kata 嚐到了甜頭
但是下一道題目「Bowling」,卻卡住了。
我們有測試,也通過測試,但是卻寸步難行,
在重構上我們非常的弱,這裡的重構不是指一次性的全面翻掉,
而是逐步的、可靠的前進,
我想習得這樣的技能,因為現場的代碼腐敗的更加嚴重,
如果連 Kata 產生的代碼都不能優化,
那想對產品指手劃腳只不過是說幹話。

閱讀經典:重構—改善即有的程式設計

這是一本來自 Martin Fowler 的經典書籍,新版已經出了,而且是以 JavaScript 作為範例語言。
不過我手頭上借到的是以 Java 作為範例的板本。

CH1 重構,第一個案例

第一個問題就是我找不到書中說的「線上範例」,
即使找到我也沒有 Java 的開發環境,所以心一橫就開始了改寫成 C# 的計劃
這部份比我想像中的簡單很多,兩個語言是相同類似的,
第1章,第一個案例

接下來只要照著書上一步一步作就會…覺得越來越沒 fu …
為什麼 ???

其實 Martin 大叔在書中有提到「為即將修改的程式建立可靠的測試…畢竟是人,可能會犯錯。所以我需要可靠的測試」。
沒fu的原因就是我沒加測試,即使重構了,我也不知道好壞。
沒有反饋是很糟糕的一件事。

CH1 重構,第一個案例,加上測試

那麼要怎麼加測試呢 ?
書上的案例我分析了一下,其實重構的目標只是一個單純的方法
會針對不同的情境回傳不同的字串。

簡單的說,我只要讓測試覆蓋這個方法就可以開始重構了,
我選擇dotCover來檢驗我的覆蓋率。
選擇的原因很簡單,因為我有買ReSharper, 如果有更好用更便宜的工具也請介紹給我。

OS:課金真的能解決很多人生問題啊(茶)…

最後的結果,我開了一個分支包含了100%的測試覆蓋率,
這樣就可以開開心心重構了,相信我有測試真得很有感覺。

重構的技法請自行看書,我只稍微作個記錄,有興趣可以 fork 回去玩。

  • Extract Method
  • Move Method
  • Replace Temp with Query
  • Replace Type Code with State/Strategy Pattern
  • Replace Conditional with Polymorphism
  • Self Encapsulate Field

在重構的過程中我儘可能讓步驟小(Baby Step),看我的commit歷程即可知道,但是最好可以自已作作看。
另外有一些心法,也稍作個記錄

  • 把一坨爛 Code 抽到獨立的方法之中
  • 如果一個類別方法並沒有使用到該類別的資訊
    • 考慮職責,是不是要讓它搬家
    • 提醒自已這是個壞味道
  • 拆分職責時,有個方法相依兩個不同的類別的資訊,那應該將方法放在哪裡呢?(這裡花了點時間理解)
    • 將方法放在未來可能變化較大的類別之中
    • 相依的資訊作為方法參數傳進來
    • 這樣未來有異動就被縮限在這個類別裡面。
  • 暫存變數常常會帶來問題(壞味道)
    • 儘可能的把它消除
    • 要考慮效能的問題(書上後面會說。)
  • 保持小步調、頻繁測試
    • 使用中繼方法可以縮小重構步調(特別是對public的方法)
    • 讓新的 return 值插在舊的 return 之前
    • 測試 ok 就可以刪掉舊 code (有時刪不掉也還是可以運作的)
    • 善用變異測試
  • UML 可以幫助對程式重構前後的理解
  • Java 與 C# 對繼承的處理是不同的

後記

第一章的範例完成後的結果大致如下
100%!!!
很帥氣的100%啊,這樣的 code 測試覆蓋率 100 % 全綠燈,
而且完成了重構,根本是現場不可能出現的完全體程式碼!!! 代碼的部份我會放在最後的參考區塊。

我有沒有可能讓它更好?或是找出他的缺陷呢?
下一步,我有沒有可能讓它更好?或是找出他的缺陷呢?

這個時候我想起了變異測試
還沒有實作過,來玩看看好了。

首先要選擇測試工具,這裡使用了Stryker Mutator, 但是注意只能用在 .Net Core 的版本
照著官網安裝完成後執行

1
>dotnet stryker

跑下去竟然真的找到有存活的變異
存活的變異
這兩個變異存活的原因是類似的,

1
2
3
4
double result = 2;
if (daysRented > 2)
result += (daysRented - 2) * 1.5;
return result;

變異點發生在 daysRented > 2 的判斷式之中,
現有的測試在變異發生(daysRented >= 2)時,無法提出警訊,也就是測試上的不足。
不過依現有的邏輯,不論是進入 if 進行了加0運算,或是直接回傳 result,
都是等價的(回傳 2 ),目前還沒有想法怎麼強化我的測試,
希望有先進願意不嗇指點,實務上跟本沒在跑變異測試。

後記2

回歸一下我們當初 Kata 的目的:

  • 學習 Pair ,並透過 Pair 彼此學習
  • 學習 TDD ,並透過 TDD 學習重構
  • 學習 Vim,並提昇開發速度

事情沒有那麼簡單,比如說學習 Vim 的過程中,
我們的目的是增進開發速度,但是一開始反而會變慢,
一定要刻意的練習才能習得,
你必須擁有以下的能力。

  • 打字速度,網路上很多資源,我是使用Ratatype作練習
    • 能盲打
    • 指法要正確(特別在特殊符號)
    • 快速切換中英(建議加入英文輸入法用 win + space 之切換過去)
  • 英文能力。命名是開發很重要的一課,英文不好看不懂寫得差,命名自然不會好。
  • 熟悉工具,特別是你的IDE與外掛
    • Visual Studio
    • Resharper
    • OzCode
    • more ..
  • Vim
    • Vim Basic 基本功(v、c、i、s、j、k、g、h、l….)
    • VimRc 要學會配置自已的 VimRC,這裡不僅要刻意練習,還要刻意試錯找到自已最順的模式

彼此學習方面需要相當的軟技能,
溝通、尊重、謙虛…;這些一生的功課我就不贅言了。
Pair Programming 一半是 Pair 一半是 Progrmming;
而在進入 Progrmming 之前請搞懂你要作什麼

同樣的在 TDD 的過程之中,我們沒有事先理好需求,
沒有想好作好需求分析,隨便選了測試案例就開始進行,
如果好好分析,是可以歸納出其中的邏輯,
甚至是理出 test case 的順序。

重要的是過程,但是我們太在乎結果,以致程式快速的腐敗。
甚至到了難以修改的狀態,僅管有測試保護,卻無法重構。

這是很好的一課,特別在這裡記錄一下。

參考

(fin)

[實作筆記]使用 Windows PowerShell 批次上傳 AWS S3

目標

相關服務要雲端化,要將站台、資料等…遷移至 AWS,
這個案例需要將大量在 File Server 上的檔案(報表/單據/報告書等…)上傳至 S3
因為檔案數量相當的大,所以開發一個簡單的指令來執行。

Step 1 下載並安裝適用於 Windows PowerShell 的 AWS 工具

只需要安裝必要的程式

設定 aws config

打開 terminal 執行以下語法

1
> aws configure

依指示設定 Access key IDSecret access key, 這個資料需要具備一定的權限才能取得,如果權限不足請向你的 AWS 服務管理員申請。

撰寫 PowerShell 與執行

1
2
3
4
5
6
7
8
9
10
11
12
$bucketName = "********************-your_bucket_name"
$path = "Your\s3\path\"

Get-ChildItem -Filter *.pdf |
ForEach-Object -Begin{$i=0} {
$i++;
$key = $path+$_ ;
## 進度顯示
Write-Host $key "($i/1000)" -ForegroundColor Green ;
## 上傳 S3
Write-S3Object -BucketName $bucketName -File $_.FullName -Key $key ;
}

(fin)

[實作筆記] Coding Dojo 第一個 Kata FizzBuzz

前情提要

記錄一下 Kata 的思路。

實例化需求

1
2
3
4
5
6
7
1 is 1
2 is 2
3 is Fizz
4 is 4
5 is Buzz
6 is Fizz
15 is FizzBuzz

雖然可以把上面的案例濃縮到 4 種,
整除 3 是 Fizz、
整除 5 是 Buzz、
整除 3 又整除 5 是 FizzBuzz ,
不符合上述條件的都是原數字。

有沒有必要寫這麼多測試呢?
比如說 1、2、4 的測試是不是重複了?
日前 91 大有過類似的討論,

1
2
3
4
第一個 test case 挑最簡單的,讓你可以從紅燈變綠燈。驅動出你需要的產品代碼。  
接下來後面的幾個,都可以只是拿來「確認」是否滿足你期望的情境,
也就是你寫新的測試案例,你期望他就是綠燈了,然後驗證是否符合你的期望。
目的是「驗證」,不是「驅動」

測試的不是只有「驅動開發」而已。
而好的程式碼,也不能只依靠測試。

第一個測試案例,1 回傳 1

我一開始就寫成這樣,所以後面的 2、4 案例也都會是綠燈。

1
2
3
4
5
6
7
public class FizzBuzz
{
public string GetResult(int number)
{
return number.ToString();
}
}

考慮另一種情況,也許有的人第一個測試案例會寫成這樣

1
2
3
4
5
6
7
public class FizzBuzz
{
public string GetResult(int number)
{
return "1";
}
}

這時候就有可能需要靠 2、4 的測試案例來驅動程式碼的改變。
實際上並沒有,第一種寫法對我來說就夠 Baby Step 了。

第二個測試案例,3 回傳 Fizz

1
2
3
4
5
6
7
8
9
public string GetResult(int number)
{
if (number % 3 == 0)
{
return "Fizz";
}

return number.ToString();
}

相信這是很好理解的,雖然我的案例是從 1、2、3 而來,
但是在我的腦海中已經思考好了這個程式碼的「餘數規則」,

所有測試案例

實作出一個「餘數規則」後,程式碼應該很容易隨著測試案例變成下面這個樣子,
用一堆 if 檢查「餘數」然後回傳指定的「字串」,就是我們的「規則」。
這個時候的複雜度是 4 。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
public class FizzBuzz
{
public string GetResult(int number)
{
if (number % 5 == 0 & number % 3 == 0)
{
return "FizzBuzz";
}

if (number % 5 == 0)
{
return "Buzz";
}

if (number % 3 == 0)
{
return "Fizz";
}

return number.ToString();
}
}

重構

我儘量還原當初的想法,並記錄下來,
有許多值得改善的地方,換個順序重構起來就會更明快。

重構餘數檢查

這一步真的非常的的小,我想大多數的人甚至會跳過這步驟的重構,
我只是把餘數檢查抽成私有方法,可以透過 Resharp 快速重構。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
public class FizzBuzz
{
public string GetResult(int number)
{
if (IsDivisibleBy15(number))
{
return "FizzBuzz";
}

if (IsDivisibleBy5(number))
{
return "Buzz";
}

if (IsDivisibleBy3(number))
{
return "Fizz";
}

return number.ToString();
}

private bool IsDivisibleBy15(int number)
{
return IsDivisibleBy3(number) && IsDivisibleBy5(number);
}

private bool IsDivisibleBy5(int number)
{
return number % 5 == 0;
}

private bool IsDivisibleBy3(int number)
{
return number % 3 == 0;
}
}

抽出 result 變數作為回傳值

這裡我是作了一個舖墊,主要是我看到了 FizzBuzz 的字串重複出現在 FizzBuzz, 我預計下一階段要讓 FizzBuzz 是透過組合產生,而不是寫死在程式之中。
特別要注意的事是,我為了產生 result 變數,必須在最後多作一次空字串的檢查,
這個時候的複雜度會達到 5 。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
public class FizzBuzz
{
public string GetResult(int number)
{
string result = string.Empty;
if (IsDivisibleBy15(number))
{
return "FizzBuzz";
}

if (IsDivisibleBy5(number))
{
result = "Buzz";
}

if (IsDivisibleBy3(number))
{
result = "Fizz";
}

if (string.IsNullOrEmpty(result))
{
return number.ToString();
}

return result;
}

private bool IsDivisibleBy15(int number)
{
return IsDivisibleBy3(number) && IsDivisibleBy5(number);
}

private bool IsDivisibleBy5(int number)
{
return number % 5 == 0;
}

private bool IsDivisibleBy3(int number)
{
return number % 3 == 0;
}
}

組合 result 值

這個階段 ‘Fizz’ 與 ‘Buzz’ 在程式中只會出現一次,
15 的餘數檢查也被移除了,這時的複雜度是 4 ,
可惜的是我沒有意識到第三個 if 的明顯不同,
如果我能提早重構成 result = number.ToString();
後面的重構也許會更簡潔一點。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
public class FizzBuzz
{
public string GetResult(int number)
{
string result = string.Empty;
if (IsDivisibleBy3(number))
{
result += "Fizz";
}

if (IsDivisibleBy5(number))
{
result += "Buzz";
}

if (string.IsNullOrEmpty(result))
{
return number.ToString();
}

return result;
}

private bool IsDivisibleBy5(int number)
{
return number % 5 == 0;
}

private bool IsDivisibleBy3(int number)
{
return number % 3 == 0;
}
}

實作 FizzRule Class

這是繼 FizzBuzz 後產生的第二個 Class,
算有指標意義,這裡原本的目的是想要消除 if, 但無法一步到位,先試著把 Fizz 與 Buzz 的邏輯作分離,
一樣我只聚焦在 Fizz 與 Buzz 身上,
而忽略了 其它 的邏輯判斷,寫成了三元判斷除了變成一行外其實沒有其他好處。

1
2
3
4
5
6
7
public class FizzRule
{
public bool Check(int number)
{
return number % 3 == 0;
}
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
public class FizzBuzz
{
public string GetResult(int number)
{
string result = string.Empty;
var fizzRule = new FizzRule();
if (fizzRule.Check(number))
{
result += "Fizz";
}

if (IsDivisibleBy5(number))
{
result += "Buzz";
}

return string.IsNullOrEmpty(result) ? number.ToString() : result;
}

private bool IsDivisibleBy5(int number)
{
return number % 5 == 0;
}
}

實作 BuzzRule Class

一樣把 Buzz 的邏輯搬到新的 Class 中,
這裡故意用相同的方法名,是為了下一步要抽介面。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
public string GetResult(int number)
{
string result = string.Empty;
var fizzRule = new FizzRule();
if (fizzRule.Check(number))
{
result += "Fizz";
}

var buzzRule = new BuzzRule();
if (buzzRule.Check(number))
{
result += "Buzz";
}

return string.IsNullOrEmpty(result) ? number.ToString() : result;
}

介面 IRule

終於抽出了介面,自已為聰明的把關鍵字抽離到了介面之中,
卻沒有考慮到真正的邏輯是組合 result 的行為仍然相依在 FizzBuzz Class

1
2
3
4
5
public interface IRule
{
string Word { get; }
bool Check(int number);
}
1
2
3
4
5
6
7
8
9
public class FizzRule : IRule
{
public string Word => "Fizz";

public bool Check(int number)
{
return number % 3 == 0;
}
}
1
2
3
4
5
6
7
8
9
public class BuzzRule : IRule
{
public string Word => "Buzz";

public bool Check(int number)
{
return number % 5 == 0;
}
}

IRule List

準備好了 IRule ,就是要讓 FizzBuzzFizzRule 以及 BuzzRule 解耦的階段了,
這步我踩得有小,可以更直接一點重構,
一樣的問題,我仍然沒有意識最後一個if(?:)其實也是一種 IRule, 也沒有意識到 result+=XXXreturn YYY?number.ToString() : result; 其實應該是屬於 IRule 的一部份
這時的複雜度仍然是 4

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
public class FizzBuzz
{
private List<IRule> _rules = new List<IRule> {new FizzRule(), new BuzzRule()};

public string GetResult(int number)
{
string result = string.Empty;
var fizzRule = new FizzRule();
if (fizzRule.Check(number))
{
result += fizzRule.Word;
}

var buzzRule = new BuzzRule();
if (buzzRule.Check(number))
{
result += buzzRule.Word;
}

return string.IsNullOrEmpty(result) ? number.ToString() : result;
}
}

foreach List

自以為帥氣的完成重構,而且用 foreach 消除了重複的 if
實際上複雜度完全沒有下降。
關鍵的 result += rule.Word;
return string.IsNullOrEmpty(result) ? number.ToString() : result;
我繼續忽視它。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
public class FizzBuzz
{
private List<IRule> _rules = new List<IRule> {new FizzRule(), new BuzzRule()};

public string GetResult(int number)
{
string result = string.Empty;
foreach (var rule in _rules)
{
if (rule.Check(number))
{
result += rule.Word;
}
}

return string.IsNullOrEmpty(result) ? number.ToString() : result;
}
}

重構二、面對問題

消除 foreach

參考 Martin 大叔的作法,把 foreach 變成 pipelines
光是這個作法就讓我的複雜度從 4 下降到 2 了,
此時,result += rule.Word;
return string.IsNullOrEmpty(result) ? number.ToString() : result;
就顯得相當奇怪,第一個邏輯我認為應該放進實作IRule的類別之中,
而第二個邏輯應該是一個未被實作的 Rule 。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
public class FizzBuzz
{
private readonly List<IRule> _rules = new List<IRule>
{
new FizzRule(),
new BuzzRule(),
};

public string GetResult(int number)
{
string result = string.Empty;
var myRules = _rules;
myRules
.Where(r => r.Check(number))
.ToList()
.ForEach(n => result += n.Word);
return string.IsNullOrEmpty(result) ? number.ToString() : result;
}
}

實作 Apply

終於將result += rule.Word;的邏輯從 FizzBuzz 抽離到 IRule 之中,
再由各自的 Rule 實作,這個時候就會覺得 IRule.CheckIRule.Word 有點累贅,
基於 SOLID 原則,這部份邏輯甚至不該被揭露在 FizzBuzz之中。

1
2
3
4
5
6
public interface IRule
{
string Word { get; }
bool Check(int number);
string Apply(string input);
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
public class FizzBuzz
{
private readonly List<IRule> _rules = new List<IRule>
{
new FizzRule(),
new BuzzRule(),
};

public string GetResult(int number)
{
string result = string.Empty;
_rules
.Where(r => r.Check(number))
.ToList()
.ForEach(n => result = n.Apply(result));
return string.IsNullOrEmpty(result) ? number.ToString() : result;
}
}

NormalRule

終於加上 NormalRule Class 了,裡面只有一個方法 Apply, 這裡是為了將來的介面準備,我想讓 NormalRule 成為 IRule 的一部份,
不過可以看到的問題是,方法簽章並不一致。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
public class FizzBuzz
{
private readonly List<IRule> _rules = new List<IRule>
{
new FizzRule(),
new BuzzRule(),
};

public string GetResult(int number)
{
string result = string.Empty;
_rules
.Where(r => r.Check(number))
.ToList()
.ForEach(n => result = n.Apply(result));
var normalRule = new NormalRule();
return normalRule.Apply(number, result);
}
}

修改 IRule.Apply

在我的認知中,對 Production Code 修改介面是件危險的事,
這在 Kata 是可行的,但是在實際的 Production 恐怕就不夠 Baby Step 了,
我或許應該創造一個 IRuleV2 之類的介面,而不是直接修改 IRule

首先編譯會不過,這會趨動我去修改 FizzRuleBuzzRule
另外,這個時間點 IRule.CheckIRule.Word 作為 public 的資訊就顯得相當多餘了。
所以我會進一步將這些資訊從 IRule 介面中拿掉,
這也會使得 FizzBuzz Class 產生 Error,趁這個時候把 .Where().ToList() 一併拿掉,
但是要記得將 IRule.CheckIRule.Word 包含至 IRule.Apply 之中。

1
2
3
4
public interface IRule
{
string Apply(int number, string input);
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
public class FizzRule : IRule
{
private string Word => "Fizz";

private bool Check(int number)
{
return number % 3 == 0;
}

public string Apply(int number, string input)
{
return Check(number) ? input += this.Word : input;
}
}

NormalRule 與 IRule

這裡讓 NormalRule 實作 IRule 介面,
實際上在上面幾步已經完成了,IRule 反而比較像一個標籤掛在 NormalRule 上,
如此一來,就能夠在 FizzBuzz 裡面透過 List<IRule> 統整所有的規則。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
public class FizzBuzz
{
private readonly List<IRule> _rules = new List<IRule>
{
new FizzRule(),
new BuzzRule(),
new NormalRule()
};

public string GetResult(int number)
{
string result = string.Empty;
_rules
.ForEach(n => result = n.Apply(number, result));
return result;
}
}
1
2
3
4
public interface IRule
{
string Apply(int number, string input);
}

收尾

作到這裡大概把我想作的東西都作掉了,
if 散落在各個 Rules 裡面,
如果是 Production Code 我想我會使用 NameSpace 與專案資料夾再作進一步的整理吧。
最後把 FizzRuleBuzzRuleCheckWord 拿掉只是一點潔癖。

1
2
3
4
5
6
7
public class FizzRule : IRule
{
public string Apply(int number, string input)
{
return number % 3 == 0 ? input += "Fizz" : input;
}
}

結語

過程中一直考慮著想要拿掉所有if,或是套用職責鏈(Chain of Responsibility Pattern)的 Pattern,
現在想想都有點走歪了方向,一再忽視責職的歸屬而讓後面的重構有點吃力,
不過透過 TDD 仍然讓程式碼重構到了一定的程度。
如果重來一次的話,我會選擇提早分離職責,
不過當中的取捨可能需要練習更多的 KATA 吧。

有人說這麼重構,會不會有點 Over Design 了,
我想說的是,反正是練習嘛,刻意練習到過頭也只是剛好而已,
如果不在練習時下點苦功,在戰場上用得出來嗎?
至少我的天賦而言,我應該是用不出來的。

後記 1. 20190207

Aggregate

文章貼出後,同事的回饋,可以使用 Aggregate 取代 Foreach, 程式碼可以更加精鍊。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
public class FizzBuzz
{
private readonly List<IRule> _rules = new List<IRule>
{
new FizzRule(),
new BuzzRule(),
new NormalRule()
};

public string GetResult(int number)
{
return _rules.Aggregate(string.Empty, (r, n) => n.Apply(number, r));
}
}

參數優化

把 r、n 這類較沒意義的命名改成 input 與 rule,
單純是為了讓 Aggreate 的可讀性較高一些。
接下來這個異動的幅度較大,實務上我不會這樣作,
Apply 的方法簽章順序與 Aggreate 一樣把 input String 放在最前面,
真的真的非常沒有必要,因為會異動到介面。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
public class FizzBuzz
{
private readonly List<IRule> _rules = new List<IRule>
{
new FizzRule(),
new BuzzRule(),
new NormalRule()
};

public string GetResult(int number)
{
return _rules.Aggregate(string.Empty, (input, rule) => rule.Apply(input, number));
}
}

參考