Hubert Hsieh

後端知識 - 我以為 JS 會先印 B。

Sun, 04 Oct 2026 00:00:00 GMT

這是 backend-lab 自學紀錄的 Day 2，主題是 C# 的 async 和 await。我寫了好幾年 Promise，以為這塊會很快，結果把 C# 和 JavaScript 的同一個實驗並排跑，我連自己最熟的 JS 都猜錯。這篇記錄那次猜錯，還有後面接連踩到的幾個坑：一個永遠等不完的 Promise、一個多此一舉的 Task.Run，以及我花最久才改掉的那個誤會。

執行緒 ID 的實驗、99 個計時器只花 1002 毫秒、還有 await setTimeout 的錯，post-11 都講過了，這篇不重複。

同一個實驗，寫兩次

C# 一份，JS 一份，看誰先印

C# 的 Task 和 JS 的 Promise 長得很像，都是「一個之後才會有結果的東西」。我想確認它們是不是真的同一套機制，所以寫了一個最小的實驗。

C# 的版本是這樣：

List<Task> tasks = new List<Task>();

for (int i = 1; i < 100; i++)
{
    tasks.Add(Task.Delay(1000));
}

async Task ConsoleDisplayAsync()
{
    Console.WriteLine("This is A");
    await Task.WhenAll(tasks);
    Console.WriteLine("This is B");
}

Task displayTask = ConsoleDisplayAsync();

Console.WriteLine("This is C");

await displayTask;

Task.Delay(1000) 是等一秒，Task.WhenAll 是等清單裡的全部做完，大概就是 JS 的 Promise.all。

跑出來是 A、C、B。

async 方法被呼叫之後，會先同步往下跑，跑到第一個 await 才停。停下來的時候，它把一個還沒完成的 Task 交給呼叫端，自己先退場。所以呼叫端接著印出 C，等那一秒過去，B 才出來。

這個結果我能接受，C# 對我來說是新東西，它怎麼跑我都沒意見。

接著我用 JS 寫一份一樣的。

「JS 一定是 A B C」

越熟的東西，越懶得跑

寫 JS 版之前，我很有把握地說，JS 一定是 A B C。

理由我現在已經講不清楚了，大概是覺得 await 寫在 B 前面，那 B 就應該先等完再輪到 C。

跑出來也是 A C B。

（盯著終端機那三行看了五秒，然後把 C 前面的程式碼從頭到尾再滑一遍）

兩邊的行為完全一樣。同步跑到 await，交出一個還沒完成的物件，控制權還給呼叫端，等到有人把它標成完成，後半段才繼續。

C# 我會小心，因為我知道自己不懂。JS 我沒跑就下結論，因為我覺得自己懂。

沒跑過的把握，是假的把握。 這句我寫進了錯誤紀錄，而且特別註明，「我熟的東西」最容易翻車。

一個永遠等不完的 Promise

Promise 不會自己完成，要有人按下去

為了在 JS 那邊做計時，我自己包了一個等一秒的 Promise。我寫成類似這樣：

console.log('start', Date.now());
await new Promise(() => {
  setTimeout(() => {}, 1000);
});
console.log('end', Date.now());

第一個時間戳印出來了，第二個沒有。

不是延遲，是消失。程式就停在那裡。

問題在 new Promise 給你的那個函式。它其實會收到一個參數 resolve，你要親手呼叫它，這個 Promise 才算完成。我沒有接，也沒有呼叫，所以它永遠是「等待中」，await 也就永遠等下去。

改成這樣才對：

await new Promise((resolve) => {
  setTimeout(resolve, 1000);
});

計時器一秒後去按 resolve，Promise 完成，await 醒來。

這個錯反而幫我看清了 C# 那邊。Task.Delay 之所以能被 await，是因為底下也有一個計時器，時間到了就去把那個 Task 標成完成。兩邊都一樣，要有人去按那個按鈕。

多包一層 Task.Run

等待不需要執行緒，我卻硬塞了一條給它

做 99 個計時器那個實驗的時候，我一開始不是直接把 Task.Delay 放進清單，而是包了一層 Task.Run：

tasks.Add(Task.Run(() => Task.Delay(1000)));

Task.Run 是把一段工作丟給 thread pool 去做。thread pool 可以想成後端程式預先準備好的一群執行緒，有工作就派一條出去。它適合拿來跑「需要 CPU 算很久」的東西。

可是 Task.Delay 根本不需要 CPU。它本身就是一個 Task，直接放進清單就好。

包了 Task.Run，等於為了「等一秒」這件事，特地叫一條執行緒出來，讓它去發起一個等待，然後再離開。

程式還是會動，結果也差不多。但這個實驗本來要證明的，正是「等待不佔執行緒」。我自己寫的那一行，剛好在反著做。

還控制權，不是換人

這是我花最久才改掉的誤會

Day 2 結束前，AI 要我口頭講一遍 async 的一生，從呼叫、await、等待、完成，一路到執行緒。總共六題，我答對四題。

錯的兩題，錯法一模一樣。

一題是「await 的時候，控制權還給呼叫端」，我講成「交給新的執行緒」。另一題是「等待交給計時器」，我也講成「交給新的執行緒」。

只要事情一變成非同步，我腦中就自動冒出另一條執行緒，好像不開一條新的，那些事情就沒地方跑。

實際上是這樣分的：

等待的那一秒，交給計時器，不佔任何執行緒
控制權還給呼叫端，還是同一條執行緒，它只是回頭去跑呼叫端的下一行
等待結束之後，後半段才由 thread pool 裡剛好有空的執行緒接手

被追問之後我有自己改正過來。但這個誤會之後又復發了好幾次，最後是靠印出執行緒 ID 才真的釘死，那段在 post-11。

平常寫 JS 的人，可能更容易犯這個誤會。JS 的世界裡本來就只有一條主執行緒，所以寫 JS 的時候從來不需要問「是誰在跑」。到了 C#，同一個問題突然有好幾個答案，而我的直覺選了最錯的那一個。

順帶收掉的兩筆債

都是 Day 1 欠下來、Day 2 補上的

關掉 ImplicitUsings

C# 用別的命名空間裡的東西，要在檔案開頭寫 using，有點像 JS 的 import。但新專案預設開著 ImplicitUsings，編譯器會偷偷幫你加一批常用的，所以 Day 1 的程式碼一行 using 都沒寫也能跑。

我把它改成 disable，想看看它到底藏了什麼。

build 直接噴了一整串錯，大多是 CS0103 和 CS0246，意思都是「這個名字我不認識」。Console、List、Task 全部找不到。

我一個一個補回去。補到 Task 的時候，我猜它在 System.Threading，加了 using System.Threading。

還是找不到。

Task 其實在 System.Threading.Tasks，比我猜的還深一層。這讓我推出一條規則。using X 只會打開 X 這一層，不會連 X 底下的子命名空間一起打開。

這裡我還跟 AI 吵了一下。我翻文件說 Tasks 是從 Threading 改良出來的，所以應該算在一起。最後拆成兩件事才講通，設計上的沿革是真的，但命名空間的巢狀只是分類，跟 using 能看到什麼無關。

.slnx 和 .csproj 的分工

專案裡有兩種專案檔。.csproj 描述一個專案，要編譯哪些檔案、用什麼套件。.slnx 是把好幾個專案串在一起的清單，比較像前端 monorepo 的 workspace 設定。

我憑記憶答了三題，都對：

dotnet run 只認 .csproj，而且目錄裡要剛好有一個能執行的，它不會把 .slnx 當成能跑的東西
.slnx 是給 IDE 讀的，讓 Rider 知道要一起開哪些專案
.slnx 不會自己跟檔案系統同步。刪掉一個專案資料夾，清單裡那一筆還會留著

一句話就是，build 認 .csproj，IDE 讀 .slnx，兩條路互不相干。

同一個觀念，換一個語言再跑一次

你已經會的，可能是你最該重跑一次的

Day 2 讓我翻車的，幾乎都不是 C# 的新語法，而是我以為從 JS 帶得過來的直覺。

A C B 這件事，我寫了好幾年 JS 都沒真正搞清楚，是到了 C# 才回頭發現的。

所以學一個新語言的時候，我會建議把你最有把握的那幾個觀念，用新語言寫一次，再用你熟的語言寫一次，兩邊都實際跑過。

猜錯的那一個，通常就是你一直沒真的懂的地方。

(來自一個 Promise 寫了好幾年、還是猜錯 JS 輸出順序的人)

後端知識 - Equals 說相等，== 說不相等。

Sun, 04 Oct 2026 00:00:00 GMT

這是 backend-lab 自學紀錄的 Day 2 後段，主題是 C# record 的相等性。兩個內容一樣的物件算不算相等，record 和一般 class 給的答案不同。這篇記錄我用一排實驗拆出來的三件事：相等性其實是逐個成員交給各自的 Equals 去比、Equals 和 GetHashCode 必須綁在一起，以及手寫 Equals 之後 == 不會跟著變。

HashSet 那行印錯變數、數字卻剛好對的事，post-11 寫過了，這篇不重複。Day 2 前段的 async 在 post-13。

先分清楚兩種相等

長得一樣，跟是同一個，是兩件事

C# 的 record 是一種專門裝資料的型別，一行就能宣告：

record Person(string FirstName, int Age);

我拿它跟一個欄位完全一樣的普通 class 比，各 new 兩個內容相同的物件，看三種比法：

                Equals   ==      ReferenceEquals
record Person   True     True    False
class           False    False   False

ReferenceEquals 問的是「這兩個變數是不是指向記憶體裡同一個東西」。兩次 new 就是兩個東西，所以三種型別都是 False。

普通 class 預設的 Equals 也是在比這個，所以它也是 False。

record 不一樣。編譯器幫它生了一套比內容的 Equals，名字和年齡都一樣，就算相等。

最有說服力的是 record 那一列。Equals 是 True，ReferenceEquals 是 False。

相等，但不是同一個。 值相等跟身分相等，在這一列被拆開了。

寫 JS 的人可以這樣對照：JS 的 === 比兩個物件，比的永遠是參考，兩個 { a: 1 } 永遠不相等。C# 的 class 預設也是這樣，record 則是把「比內容」做成預設行為。

比內容，到底比多深

不是深比，是外包

知道 record 比內容之後，我馬上想到下一個問題。如果欄位本身也是物件，它會一路比進去嗎？

我做了兩個實驗：

record NumberList(List<int> Numbers);
record Line(Point Start, Point End);

兩個 NumberList 都裝 { 1, 2, 3 }，比出來是 False。

兩個 Line 的起點終點都一樣，比出來是 True。

如果 record 是深比，NumberList 應該要是 True。如果它碰到參考型別就一律放棄，Line 應該要是 False。兩個猜法都被打掉了。

真正的規則是，record 不自己比，它把每個成員交給那個成員自己的 Equals。

List<int> 是普通 class，它的 Equals 比的是參考，兩個不同的 List 就是 False。Point 是 record，它的 Equals 比內容，所以 True。record 只是把這些答案收集起來，全部 True 才算 True。

這有點像一間公司的驗收流程。總經理不會自己去檢查每個零件，他問每個部門主管「你那邊 OK 嗎」，主管說 OK 他就簽。問題是倉儲部門的主管檢查的方式是「是不是同一箱」，不是「箱子裡的東西一不一樣」，那總經理也只會拿到這個答案。

Equals 根本沒被叫到

相等卻留兩份，是因為它根本沒被問

這段是整個 Day 2 我覺得最值得記下來的。

如果我不用 record，自己在 class 裡 override Equals，讓它比 X 和 Y：

class ClassOverridePoint
{
    public int X { get; }
    public int Y { get; }

    public ClassOverridePoint(int x, int y)
    {
        X = x;
        Y = y;
    }

    public override bool Equals(object? obj)
    {
        return obj is ClassOverridePoint other
               && X == other.X
               && Y == other.Y;
    }
}

Equals 確實回 True。但把兩個 (1, 2) 放進 HashSet，Count 是 2。

明明相等，卻留了兩份。

原因在 HashSet 找東西的方式。它不會拿新元素跟裡面每一個都比一次 Equals，那太慢了。它先算 GetHashCode，用這個數字決定要放進哪一格，只有落在同一格的元素才會進一步比 Equals。

我沒有 override GetHashCode，所以用的是預設版本，兩個物件算出來的數字不一樣。我實際印出來，一個是 23458411，一個是 9799115。

數字不同，放進不同的格子，Equals 從頭到尾根本沒被執行。

這就是 Equals 和 GetHashCode 之間的約定。兩個物件 Equals 相等，GetHashCode 就必須一樣。反過來不用，hash 一樣但內容不同是允許的，那只是剛好撞在同一格。

編譯器其實有提醒。build 的時候會出現 CS0659 警告，說這個型別覆寫了 Equals，卻沒有覆寫 GetHashCode。

（第一次 build 看到黃色那行，我很順手地就把終端機往上捲掉了）

補上一行就好：

public override int GetHashCode()
{
    return HashCode.Combine(X, Y);
}

Count 變回 1。

record 從來不會有這個問題，因為編譯器生 Equals 的時候，GetHashCode 是一起生的。

override Equals，== 不會跟著來

同一個物件，兩種比法給出相反的答案

換題重寫的時候，我把 Point 換成 Person，Equals 和 GetHashCode 都補齊了，HashSet 也正常是 1。

但我把 == 也印出來，看到這一行：

ClassOverridePerson Equals : True
ClassOverridePerson ==     : False

同一對物件，Equals 說相等，== 說不相等。

這個矛盾是我在實驗結果裡自己注意到的，原因也是自己推出來的。== 在 C# 裡是另一個運算子，class 沒有自訂的話，它比的還是參考。override Equals 只改了 Equals，== 完全不知道這件事。

要讓 == 也比內容，得另外寫 operator == 和 operator !=。

record 一次幫你生的是完整的一套，兩個 Equals、GetHashCode、==、!= 全部對齊。手寫 class 的時候，這五個你要自己一個一個補，漏一個就會出現上面那種矛盾。

常見應用：什麼時候會真的踩到

不是考試題，是會在正式環境出現的 bug

這三件事在實際寫後端的時候，大概會出現在這些地方：

拿物件當 Dictionary 的 key 或丟進 HashSet 去重複。漏了 GetHashCode，去重複會無聲失效，不會有任何錯誤
record 裡面放 List，以為兩筆資料內容一樣就會相等，結果永遠是 False
程式碼裡有人寫 a.Equals(b)、有人寫 a == b，對手寫 class 來說，這是兩種不同的判斷

第一個最麻煩。它不會 crash，只會讓資料多一份，而你要等到某天數字對不上才會發現。

所以 CS0659 那種警告，看到就要停下來讀。

(來自一個看到黃色警告，第一個反應是捲掉終端機的人)

後端知識 - MapGet 不是在執行，是在登記。

Sat, 03 Oct 2026 00:00:00 GMT

這是 backend-lab 自學紀錄的 Day 1，主題是 ASP.NET Core 的 Minimal API。我原本以為 MapGet 那一行就是「收到請求時執行這段」，結果它其實只是在登記路由。這篇記錄我怎麼從一個健康檢查端點，一路挖到框架的原始碼，最後還親手做出一個 race condition。

為什麼要綁住 AI 不准代寫，上一篇講過了，這篇只講學到的東西。

第一個端點長這樣

十幾行，但每一行都比我以為的多做了事

Day 1 的題目是寫一個健康檢查端點，回傳服務狀態跟時間。這種端點是讓外部確認服務還活著用的，部署平台會定期打它，沒回應就當作服務掛了。

用的寫法叫 Minimal API，是 ASP.NET Core 寫 API 最精簡的方式。不需要另外開 Controller 類別，幾行就能架起一個服務。

補全關掉之後我重寫出來的版本是這樣：

var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();

app.MapGet("/health", () =>
{
    var response = new HealthResponse("ok", DateTime.UtcNow);
    return TypedResults.Ok(response);
});

app.Run();

/// <summary>健康檢查回應。</summary>
/// <param name="Status">服務狀態。</param>
/// <param name="Timestamp">回應產生時間（UTC）。</param>
public record HealthResponse(string Status, DateTime Timestamp);

最下面那個 record 是 C# 專門用來裝資料的型別，宣告一行就有建構子跟屬性，Day 2 會再細講。TypedResults.Ok(...) 則是回傳 HTTP 200，並把內容一起送出去。

我 JS 寫得比 C# 多，第一眼看這段，腦中浮現的是 Express 的 app.get('/health', handler)。這裡的 handler 指的是處理請求的那個函式。C# 那邊的 () => { ... } 叫做 lambda，其實就是 JS 的箭頭函式。

感覺很熟，所以我很自然地把 MapGet 讀成「有人打 /health 的時候，執行這個 lambda」。

這個讀法不算錯，但漏掉了最重要的一半。

註冊，不是執行

MapGet 跑的時候，根本還沒有任何請求

MapGet 這一行是在 app.Run() 之前執行的。那時候伺服器還沒開始聽 port，不可能有請求進來。

所以它做的事情只有一件，就是把「/health 對應到這段 lambda」寫進路由表。

真正執行 lambda 的，是之後每一個打進來的請求。

用餐廳來想會比較清楚。開店之前，老闆把菜單寫好、規定每道菜的做法，這是 MapGet。開店之後客人點一份，廚房就照做一份，這是請求進來。

廚房不會在每個客人點餐的時候，重新討論這道菜要怎麼做。

編譯期、啟動期、請求期

整個 Day 1 最後收斂成這三行

寫 JS 的時候，存檔就能直接跑。C# 不一樣，執行之前要先經過編譯器，把程式碼翻成 .NET 執行環境看得懂的格式，順便把型別全部檢查一遍。這一步就是編譯期。

把「登記」跟「執行」拆開之後，我發現其實有三個時間點，不是兩個：

編譯期  → 編譯器推導出 lambda 的 delegate 型別，記進編譯結果
啟動期  → MapGet 執行，讀這份型別資訊，決定回應策略，寫進路由表
請求期  → 請求進來，照路由表既定策略執行。不猜、不判斷。

delegate 是 C# 用來描述「一個函式長什麼樣子」的型別，包括吃什麼參數、回傳什麼。

最前面那一段，是我用一個會失敗的實驗確認的。

我故意寫了一個 lambda，某個分支回傳字串，另一個分支回傳物件。程式根本跑不起來，還沒執行就報錯，說 delegate 的型別推導不出來。

這代表「這個 handler 會回傳什麼」在編譯的時候就要定下來了。回傳 string 就是純文字，回傳物件就序列化成 JSON，框架不會等到請求進來才去看你回了什麼。

跳進原始碼，然後迷路

抓機制，不要啃實作

規則裡有一條是遇到框架的「魔法」，要自己跳進原始碼看，不准問 AI 也不准 Google。

我寫 C# 用的 IDE 是 JetBrains 的 Rider，游標停在方法名稱上按 Cmd+B，就會直接跳到框架裡那個方法的實作。

所以我從 MapGet 一路往裡面跳，最後停在一個叫 RequestDelegateFactory 的類別。

這個檔案大約一千五百行。

我很認真地從頭讀，讀到中途就完全不知道自己在哪裡了 😵（然後默默把檔案往上捲回去，假裝剛剛沒讀過）

後來換了一個讀法。不去理解每一行在做什麼，只找一件事的證據，就是 lambda 是不是在啟動期被加工一次，之後就不再動。

證據是兩個東西。一個是裡面有 .Compile()，把 lambda 編譯成一個 RequestDelegate。另一個是我在啟動期把那個 delegate 的 GetType() 印出來，確認它真的是一個已經做好的東西，而不是每次請求才產生。

讀框架原始碼的時候，你不需要懂一千五百行。

你只需要知道自己要找什麼，然後找到那一行。

放錯位置的 record

啟動期只跑一次，所以放在那裡的東西也只會產生一次

搞懂三個時期之後，我回頭看 Day 1 犯的一個錯，才真的看懂它錯在哪。

我一開始把 HealthResponse 建在 handler 外面，像這樣：

var response = new HealthResponse("ok", DateTime.UtcNow);

app.MapGet("/health", () => TypedResults.Ok(response));

程式會動，打 /health 也有回應。但不管打幾次，Timestamp 永遠是同一個時間。

因為 handler 外面那一行屬於啟動期，整個伺服器生命週期只跑一次。之後每個請求拿到的，都是開店那一刻做好的那一盤菜。

這個錯本身沒什麼殺傷力，頂多時間不對。

但同樣的位置，如果放的是一個會被寫入的變數，就是另一回事了。

親手做出一個 race condition

說好的一百萬，最後只剩三十五萬

所以 Day 1 的最後一個實驗，是故意把這個錯放大。

我在 handler 外面放一個共享的 count，然後開 10 個 Task 同時跑，每個都對它加 10 萬次。Task 可以先想成 C# 版的 Promise，Day 2 會講。

照理說，最後的數字應該是一百萬。

實際跑出來是 353,900。

跑之前我有先賭一把，賭結果會「比較少」，這點有賭對。但我沒想到會少這麼多，三分之二的加法直接消失了。

原因在 count++ 這個看起來只有一步的操作。它其實是三步：

讀出 count 現在的值
加一
寫回去

兩個 Task 如果同時讀到 100，各自加一變成 101，再先後寫回去，結果是 101 而不是 102。

有一次加法就這樣不見了。十個 Task 一起搶的時候，這種事情會一直發生。

想像十個人同時在改白板上的同一個數字。每個人都是看一眼、心算加一、擦掉重寫，看的那一眼跟寫的那一下中間，別人早就改過了。

解法的方向是讓「讀、改、寫」變成一個不能被插隊的動作，也就是原子操作。具體怎麼寫，課程排在第三週，我還沒學到。

這裡我也學到要分清楚兩種情況。共享狀態如果只有讀，問題是資料舊了，像上面那個永遠不更新的時間。如果有併發在寫，問題就會變成 race condition，資料直接錯掉。

前者很容易發現，後者不會報任何錯，數字就只是靜靜地變少。

Day 1 結束時，我真的會的是什麼

照我自己的定義，只有能憑記憶重寫的才算

backend-lab 有一張掌握度的表，綠燈的定義是「打開空白檔案、不看範例能寫出來」。Day 1 結束時，綠燈的有這幾個：

Minimal API 的基本結構
MapGet 是註冊，不是執行
編譯期、啟動期、請求期的時間軸
回傳型別決定回應格式
handler 外的共享狀態是陷阱

還有一個是黃燈，就是上一篇講過的，我把 string 寫成 String。

如果你也剛開始碰 ASP.NET Core，我覺得 Day 1 最值得帶走的是那條時間軸。之後要學的依賴注入、middleware，都是建立在同一件事上。

啟動期先登記好，請求期只是照表執行。

(來自一個想把一千五百行讀完、讀到中途就迷路的人)

自我思考 - 我叫 AI 不准幫我寫程式。

Sat, 19 Sep 2026 00:00:00 GMT

今年七月我開了一個學後端的練習專案 backend-lab，用 C# / ASP.NET Core 從零開始學。這個專案跟我其他專案最不一樣的地方，是我在給 AI 的設定檔裡寫的第一條規則。不准替我寫實作程式碼。 這篇在講我為什麼要這樣綁住它、這個模式抓到我哪些裝懂的地方，以及這個預計四週的課程，最後停在第二天。

為什麼要綁住一個很會寫程式的工具

我要的是自己真的懂，不是 AI 幫我處理好

現在要寫一支 API，叫 AI 產一個出來大概只要幾十秒，而且它會動。問題就在「它會動」這件事。

會動的程式碼放在我眼前，我看得懂，也改得動，久了就會以為自己會了。但如果有人叫我打開空白檔案、不看範例重寫一次，我寫不寫得出來？老實說我不知道，而且在開這個專案之前，我從來沒有真的試過。

這有點像開車靠導航。開導航可以到任何地方，每天走同一條路上下班也沒問題。但哪天導航沒訊號，你才發現自己根本不知道那條路怎麼走。

你沒有迷路過，不代表你認得路。

我想真的掌握 C# 跟 .NET 底層的邏輯，所以乾脆把導航關掉。

我給 AI 的規則，比給自己的還多

它的角色是家教跟審查者，不是寫手

CLAUDE.md 是 Claude Code 每次開工都會讀的設定檔。我在裡面寫的「絕對禁止」有五條是給它的：

不准替我寫實作程式碼
不准直接幫我修 bug，我卡住時只能引導
不准一步給出完整答案
不准給我「骨架讓我填空」，那只是包裝過的代寫
不准把我還沒理解的套件或 pattern 塞進來

然後有三條是給我自己的，而且要它主動監督我。IDE 的 AI 補全全部關掉、不准複製貼上我不懂的程式碼、不准跳過驗證就往下走。

我卡住的時候，提示分成四層，一次只給一層：

第 1 層：告訴我這是什麼概念，要我自己回想
第 2 層：給方向，或問我一個對的問題
第 3 層：給虛擬碼，不給 C#
第 4 層：我要明講「我放棄，給我看」，它才給最小範例，而且給完要我關掉、憑記憶重寫，重寫過才算數

最後整份設定只繞著一個問題轉：

「Hubert 現在能不能打開空白檔案、不看任何範例、不用補全，把這段重寫出來？」

不能的話，不管程式會不會動，一律標紅燈。

第一天就被抓到用補全

眼睛記住，不等於手記住

規則是我自己寫的，但第一天寫的第一段程式碼，就是 IDE 的 AI 補全幫我寫的。😅

那天的題目很簡單，寫一個 /health 端點，回傳服務狀態跟時間。補全關掉之後重寫一次，七個重點我對了六個，錯的那個是把 string 寫成 String。

這個錯本身很小，C# 裡兩個都能編譯。但它說明了一件事。我明明看過好幾次 string，看的時候也完全知道它是對的，手打出來的卻不是它。

看得懂跟寫得出，是兩種不同的記憶。

那天還抓到另一件更丟臉的事。我一直在問環境設定、專案結構、IDE 怎麼設，問了很久還沒開始寫 code。後來我在錯誤紀錄裡替它取了個名字叫「準備成癮」。感覺很像在進步，其實是在拖延真正難的那一步。

同一個錯，我犯了三次

講得出來的觀念不算數，印出來的數字才算

Day 2 學 async / await。JS 的 Promise 我寫了好幾年，心裡覺得這塊應該很快。

結果這是我整個專案翻車最多次的地方。

我的誤會是以為 await 之後，程式會「交給另一條執行緒」去跑。所以被問到「呼叫一個 async 方法之後，呼叫端的下一行是哪條執行緒在跑」，我前後講錯了三次，一下說是空閒的執行緒，一下說是 timer。

第三次講錯之後，AI 沒有再解釋一遍，而是叫我把執行緒 ID 印出來自己看。幾天後它又抽考我一次，我重寫了一個更精簡的版本：

async Task Main()
{
    Console.WriteLine($"AAA thread = {Thread.CurrentThread.ManagedThreadId}");

    await FooAsync();

    Console.WriteLine($"DDD thread = {Thread.CurrentThread.ManagedThreadId}");
}

async Task FooAsync()
{
    Console.WriteLine($"BBB thread = {Thread.CurrentThread.ManagedThreadId}");

    await Task.Delay(1000);

    Console.WriteLine($"CCC thread = {Thread.CurrentThread.ManagedThreadId}");
}

await Main();

跑出來的是：

AAA thread = 1
BBB thread = 1
CCC thread = 5
DDD thread = 5

await 之前都在主執行緒（1 號）上跑，而且 await 本身不會換執行緒，它只是把控制權交還給呼叫端。真正換人的是等待結束之後。後半段由 thread pool 裡剛好有空的執行緒接手（5 號）。至於那一秒的等待，是交給 timer 處理的，它根本不佔用任何執行緒。

我後來把它記成一句話，timer 負責等待，執行緒負責跑程式碼。

這也解釋了我覺得最神奇的一個實驗。同時開 99 個 Task.Delay(1000)，全部等完只花了 1002 毫秒，不是 99 秒。後端用 async 不是為了讓單一請求變快，是為了在等待的時候不浪費執行緒，同樣的機器可以同時扛更多請求。

我在錯誤紀錄裡寫的教訓是，口頭最容易翻車，觀念要以實驗為準，不要相信自己的複述。

而且越是「我熟的東西」越危險，我在 JavaScript 那邊也犯了一個。await 了 setTimeout 的回傳值，以為它有在等。但 setTimeout 回傳的是一個數字，await 一個數字等於沒等，時間戳印出來是 0ms。

最毒的 bug，是數字剛好對

對的數字加上錯的來源，比錯的數字還難抓

Day 2 後段學 record 的相等性。我寫了一整排 HashSet 的實驗，驗證 record 跟一般 class 放進 HashSet 之後，重複的東西會不會被擋掉。

所有數字都跟預期一樣。但其中有一行，我 Add 進的是 A 這個 set，印出來的卻是 B 的 Count。兩個 set 的數量剛好都是 2，所以數字完全對，看起來一點問題都沒有。

如果數字是錯的，我會馬上去查。偏偏它是對的，所以我差點就讓它過去了。這件事讓我對「驗證」多了一層理解。不是看數字對不對就好，要較真這一行到底在量誰。

預計四週，停在第二天

最後一筆 commit 是 2026-07-28

整個課程排了四週。第一週 HTTP 服務跟分層架構，第二週資料庫，第三週認證跟安全，第四週測試跟部署。

我走到第一週的第二天。

原因很單純。後來案子一個接一個來，而且接到的案子是 Python + Flask 的 API，不是 C#。工作上用不到的東西，要在下班後擠出時間繼續學，說實話我沒擠出來。

這個專案停下來，但我覺得它證明了一件事。第二天的兩個主題，async 跟 record 的相等性，我都是打開空白檔案、不看範例重寫過，再用實驗自己證明的。

我沒有學很多，但這兩個，我是真的敢說我會。

如果你也想這樣學

先決定你要的是「做出來」還是「學會」

這兩個目標都沒有錯，但它們需要的 AI 用法剛好相反。趕案子的時候，讓 AI 多寫一點很合理。想學會某個東西的時候，它寫得越多，你學到的越少。

如果你想試試看，我自己覺得最有用的是這三件事：

把規則寫下來，並且要它監督你。 光靠自律，我第一天就破功了
不懂的時候要實驗，不要要解釋。 AI 講得再清楚，都沒有你自己印出來的那個 5 號執行緒有說服力
準備一張「我犯過的錯」的表。 我那張表現在是整個專案最有價值的檔案，因為它記的全是我以為自己懂、其實不懂的地方

接下來的案子是 Flask，我有在想用同一套規則再開一個 Python 的練習專案。至於 C# 那邊的第三天，就等案子告一段落再說了。

(來自一個規則自己寫、第一天就自己破功的人)

後端知識 - ANR 的真兇：一張沒設計索引的資料表。

Thu, 03 Sep 2026 00:00:00 GMT

上一篇提過，那次 ANR 追到最後是三個問題疊在一起：迴圈裡查資料庫、缺索引、資料表設計本身有問題。這篇把「缺索引」這一項拉出來講，包括我是怎麼發現的，以及索引這東西到底在解決什麼問題。

我是在做開單系統的時候發現的

車牌身分查詢，資料量一大就開始卡

當時在做一個開單系統，裡面有一段是查車牌對應的身分資料。

功能本身沒有很複雜，但隨著資料越堆越多，這段查詢開始明顯變慢，慢到會卡住主執行緒、觸發 ANR。

這個專案的本地資料庫是用 GreenDAO 管的。我是從這段查詢往回查，才發現除了主鍵之外，整張資料表沒有任何一個欄位加過索引。

不是這張表特別忘記加，是這個專案的資料表設計階段，索引這件事根本沒有被考慮進去。

用了 ORM 之後，@Entity 一標、欄位一寫、表就生出來了，索引不是自動附贈的，你不特別標記，它就是不存在。

沒有索引，資料庫在做的事

SQL 語法寫對，不代表資料庫找得快

沒有索引的查詢，資料庫的做法是把整張表從第一筆掃到最後一筆，逐筆比對符不符合條件。

表裡有一百筆，最壞情況就是比對一百次；有一百萬筆，就是一百萬次。

這解釋了為什麼一開始完全沒感覺。測試階段資料量小，全表掃描跟有索引的查詢幾乎感覺不出差異。等資料真的長到「非常大」，這個差異才會被放大到使用者感覺得到。

而放大到最後，就是主執行緒卡住、系統跳出 ANR 對話框。

索引做的事，簡單說是幫資料庫先建好一份「排序過的索引」，查詢時不用整張表掃過去，而是直接用類似二分搜尋的方式定位到資料。

差別是從「掃過去」變成「跳過去找」。

GreenDAO 底層還是 SQLite，所以要看一段查詢到底有沒有吃到索引，一樣可以用 EXPLAIN QUERY PLAN 檢查，只是要先從 DaoSession 把底層的資料庫物件拿出來，才能下原生 SQL：

// DaoSession 底層包的還是 SQLiteDatabase，拿出來就能下原生 SQL
Cursor cursor = daoSession.getDatabase()
    .rawQuery("EXPLAIN QUERY PLAN SELECT * FROM PLATE WHERE PLATE_NUMBER = ?",
              new String[]{"ABC-1234"});

如果結果顯示 SCAN PLATE，代表是全表掃描；顯示 SEARCH PLATE USING INDEX，才代表真的用到索引在找。

在 GreenDAO 裡加索引，不是手寫 CREATE INDEX，是在 Entity 的欄位上標註解，重新產生程式碼即可：

@Entity
public class Plate {
    @Id
    private Long id;

    @Index
    private String plateNumber;
}

要加唯一約束的話是 @Index(unique = true)。這一步的成本低到近乎沒有藉口。多一個註解、重新 build 一次，遠比想像中麻煩要小。

這件事回頭看，其實是設計階段就該問的問題

「這張表以後查詢最常用哪個欄位當條件？」

索引不是查詢慢了才補救的東西，是設計資料表的當下就該想的問題。這張表以後最常用哪個欄位去查？那個欄位就該加索引。

我們當時完全沒有問過這個問題，資料表是照著「有哪些欄位」去設計的，不是照著「以後會怎麼查」去設計的。

這跟前端的效能問題不太一樣。前端效能不好，通常是畫面明顯卡、掉幀，有感覺。

資料庫缺索引，在資料量小的時候完全沒有任何徵兆，等你發現的時候，通常已經是資料量長到某個門檻、使用者已經在抱怨的時候了。

如果你也在用 ORM 管本地資料庫，這件事更容易被忽略，因為連 CREATE TABLE 都是自動生成的，索引這種「不寫就不會出現」的東西，很容易被誤會成 ORM 已經幫你顧好了。

如果你也在做會長期累積資料的系統，這是一個值得在寫下第一個 @Entity 之前先問自己的問題。

前端知識 - React的生命週期：三年後，那篇文章有一半該重寫。

Thu, 03 Sep 2026 00:00:00 GMT

三年前我寫過一篇 React 生命週期，內文列的方法全部是 Class Component 的 componentDidMount、shouldComponentUpdate 那一套，但程式碼範例最後默默附了一個用 useState / useEffect 的 function component，內文一個字都沒解釋它。這篇是那篇的續集，重點在 useEffect 對不上 Class 生命週期的地方，以及 StrictMode 下 effect 會跑兩次這件事。

先承認那篇的問題

不是內容寫錯，是重心押在一個現在幾乎不會用的寫法上

三年前那篇在這裡。回頭看，Mount / Update / Unmount 這三個階段的描述到今天都還成立，那部分不用改。

問題在後面：我用了整整三節去列 Class 的生命週期方法，然後在最下面的 code block 裡貼了一個 function component，內文完全沒提到它。

老實說當年我根本沒意識到那段需要解釋。我大概是想「順便附一個現代寫法」，然後就這樣貼上去了 😅。

結果就是那篇文章的重心，押在一個 2026 年幾乎不會有人新寫的東西上。

`useEffect` 不是「三個生命週期合體」

這是從 Class 過來的人最容易帶著的錯誤直覺

很多教學會給你一張對照表，說 useEffect(fn, []) 等於 componentDidMount、回傳的清理函式等於 componentWillUnmount。這個對照大概方向對，細節全錯，而錯的地方剛好就是會咬你的地方。

我在自己的專案（React 18.2）裡開了一個測試頁，把三種 useEffect 掛在同一個元件上，實際跑一次看 console：

// 三種寫法掛在同一個元件上，看它們各自什麼時候被呼叫
React.useEffect(() => {
    console.log('effect deps=[] 執行');
    return () => console.log('effect deps=[] 清理');
}, []);

React.useEffect(() => {
    console.log(`effect 無 deps 執行 count=${count}`);
    return () => console.log(`effect 無 deps 清理 count=${count}`);
});

React.useEffect(() => {
    console.log(`effect deps=[count] 執行 count=${count}`);
    return () => console.log(`effect deps=[count] 清理 count=${count}`);
}, [count]);

把 count 從 0 加到 1，實際輸出是這樣：

effect 無 deps 清理 count=0
effect deps=[count] 清理 count=0
effect 無 deps 執行 count=1
effect deps=[count] 執行 count=1

三件事可以直接讀出來。

清理函式不是只在銷毀時跑

componentWillUnmount 一輩子只跑一次，就是元件要消失的時候。但上面那段輸出裡，元件根本沒有消失，count 只是從 0 變 1，清理函式就已經跑了兩次。

只要 effect 要重跑，它會先把上一輪清理掉。 所以正確的心智模型不是「掛載時執行、卸載時清理」，而是「每一輪 effect 自己負責收拾自己」。

清理函式看到的是舊的值

注意上面那兩行清理印的是 count=0，不是 count=1。清理函式是上一輪 render 建立的閉包，它記得的是建立當下的值，不是執行當下的值。

這件事像離職交接。你交接的是自己在職期間知道的狀況，不是公司現在的狀況。如果你在清理函式裡拿某個 state 去做判斷，你拿到的是舊的那份。

這是我自己踩過最久才想通的一個坑。

`deps=[]` 那個從頭到尾沒動

它在 update 時完全沒有出現在輸出裡。這部分確實接近 componentDidMount。但下一節就會看到，連這個也不完全成立。

沒有 `shouldComponentUpdate` 的等價物

這是對照表上最常被跳過的一格

useEffect 沒有任何辦法「阻止這次更新」。Class 的 shouldComponentUpdate 回傳 false 就整個 re-render 都不會發生，但 effect 是在 render 之後才跑的，它沒有投票權。

要擋 re-render 得換工具，而且這裡很容易搞混。真正能跳過 re-render 的只有 React.memo（對應 Class 的 shouldComponentUpdate / PureComponent）。useMemo 和 useCallback 本身不會阻止任何一次 re-render。它們只是讓傳給子元件的值或函式在每次 render 之間保持同一個參考，好讓外面包了 React.memo 的子元件有機會判斷「沒變」而跳過。

單獨用 useCallback 包一個 callback，什麼都擋不到。

而且這些是「效能優化」而不是「生命週期」，觀念上是兩件事。這也是為什麼把 hooks 硬塞進生命週期的表格裡會怪怪的。

StrictMode 下 effect 會跑兩次

React 18 開始的行為，第一次遇到會以為自己寫錯了

我在測試頁裡放了兩組一樣的元件，一組直接放、一組用 <React.StrictMode> 包起來，同一次載入的 console 輸出：

[plain]  effect deps=[] 執行
[plain]  effect 無 deps 執行 count=0
[plain]  effect deps=[count] 執行 count=0
[strict] effect deps=[] 執行
[strict] effect 無 deps 執行 count=0
[strict] effect deps=[count] 執行 count=0
[strict] effect deps=[] 清理
[strict] effect 無 deps 清理 count=0
[strict] effect deps=[count] 清理 count=0
[strict] effect deps=[] 執行
[strict] effect 無 deps 執行 count=0
[strict] effect deps=[count] 執行 count=0

沒包的那組跑一次，包了 StrictMode 的那組是執行 → 清理 → 再執行。

這是 React 18 刻意加的：它在開發模式下故意把元件掛載兩次，用來逼出「清理函式沒寫好」的 bug。如果你的 effect 發了一支 API 而沒有在清理函式裡取消，你就會看到請求送兩次。

那不是 React 壞掉，是它在告訴你這段程式碼經不起重複掛載。

只在開發模式發生，production build 不會。 但正因為只在開發模式，很容易被誤判成「我的程式碼有問題」而花時間去追一個不存在的 bug。上面那段 deps=[] 的 effect 在這裡也被清理了一次。所以連「deps=[] 等於 componentDidMount」都不能算完全成立。

那篇文章我不打算刪掉

寫錯的東西留著，比刪掉有用

Class Component 的生命週期還是有價值。維護舊專案會遇到，面試偶爾還是會問，而且理解 Class 那一套之後再看 hooks，會更清楚 hooks 到底解掉了什麼問題。

真正該補的是這篇：把當年那個沒被解釋的 function component 講完。如果你也是從 Class 那個年代過來的，希望這篇能幫你少走一點我走過的冤枉路。

自我思考 - 停更三年，回來才發現網站也壞了兩年。

Wed, 02 Sep 2026 00:00:00 GMT

這個部落格最後一篇文章是 2023-05-24，之後停了三年。這次回來想更新，第一件事不是寫文章，是發現網站根本部署不了。最後一次成功部署停在 2024-05，也就是說它已經壞了兩年，而這兩年裡沒有任何人告訴我，包括我自己。這篇是關於那三年我去做了什麼，以及為什麼「不會的時候，人是寫不出東西的」。

最後一篇文章的日期，剛好在換工作前一週

2023-05-24 發文，2023-06 進新公司

我沒有刻意停更。回頭看時間點才發現，最後那幾篇面試日記寫完、offer 拿到、進了新公司，然後就沒有然後了。

新工作跟我原本做的事不一樣。以前我是「寫前端的」，到了新公司變成前後台都要碰，而且手機 App 是開發跟維護都要做。

不是接手別人寫好的東西改一改就好，新功能得自己從頭做，既有的也得自己顧下去。

換句話說，我不只是在一個陌生的平台上修東西，是要在那個平台上做決定。而做決定這件事，需要的是「真的懂」，不是「查得到」。

工作忙起來是一個原因，但那不是真正的原因。忙的時候人還是有辦法擠出時間做喜歡的事。真正的原因比較難承認。

我從一個我會的領域，跳到一個我不會的領域。

然後我遇到了 ANR

前端沒有這種東西：畫面卡住不只是難看，是作業系統直接把你的 App 判死刑

在網頁上，主執行緒被卡住的後果是畫面頓一下、動畫掉幀、使用者覺得這網站有點慢。不好，但不致命。

在 Android 上，主執行緒卡太久，系統會跳出一個對話框問使用者「這個應用程式沒有回應，要關閉嗎」。這就是 ANR（Application Not Responding）。

它不是你的程式碼丟出的錯誤，是作業系統對你下的判決。

第一次遇到的時候我完全不知道從哪裡查起。錯誤訊息不會告訴你「你哪一行寫錯了」，因為根本沒有哪一行寫錯：每一行單獨看都是對的，錯的是它們加起來太慢。

而且它不是使用者回報給我的，是我自己測出來的。把測試資料灌多一點之後，App 開始卡，卡到系統跳出那個對話框。

資料少的時候一切正常，我原本以為那就代表沒問題。

從 ANR 追到 SQLite

症狀跟根因隔了三層，這是我學到最多的一次除錯

追查的路徑大概是這樣：先確認不是單一功能的 bug，而是效能問題；再往下找是哪一段耗時；最後追到資料庫。

問題不只一個，是三個疊在一起：

在迴圈裡查資料庫。一個列表跑迴圈，每一筆都去查一次，十筆就是十次查詢
缺索引。沒有索引的查詢就是整張表掃過去，資料少的時候快得看不出差別
資料表設計本身有問題，讓上面兩件事變得更容易發生

這三個有一個共同點，資料少的時候全部都看不出來。

而且它們不是相加的，是相乘的。迴圈的次數乘上每次查詢要掃過的資料量。

資料量小的時候，小數字乘小數字還是小數字；資料一多，兩邊同時變大，乘起來就直接把主執行緒卡到系統受不了。

這也是為什麼我一開始完全找不到「哪一行寫錯了」。每一行單獨看都對，錯的是這個設計在資料長大之後撐不住，而它在資料還小的時候完全沒有徵兆。

這段除錯經驗跟我以前在前端做的完全不同。前端的效能問題通常看得見，開 DevTools 就有火焰圖，哪一段慢一目了然。

這次是「東西在使用者手機上偶爾會死，而且不一定重現」。

三年前那篇文章，我自己變成了裡面的人

〈為什麼老是覺得自己不夠好？〉寫在 2023-05-16

那篇裡我寫過一段：

很多時候我們的確會應用一些技術，不論是查看文件或是 Google 都有相當多的範例可以參考⋯⋯但深層的原理如果沒搞懂的話，下次有人問起，要描述或是解說的話大概率又講不出來。

寫那篇的時候，我是站在「已經會前端」的位置上談這件事的。三年後我跳到 Android，變成那個「會用但講不出原理」的人本人。

我還在那篇裡用三步上籃當比喻。不熟練的人一下同手同腳，一下走步，一下力道過猛。當時我覺得那是個講給別人聽的比喻。

追 ANR 那段時間，我就是那個同手同腳的人。

而人在同手同腳的時候，是寫不出文章的。 不是沒時間，是沒有東西可以寫。你正在經歷的事情你自己都還沒搞懂，怎麼寫成一篇給別人看的筆記？

所以停更這件事，與其說是懶惰，不如說是我暫時失去了「可以拿出來講的東西」。

網站是怎麼安靜爛掉的

沒有人在看，也沒有任何機制會告訴你它壞了

這次回來清點，才知道這三年裡它爛成什麼樣子：

部署從 2024-05 之後就沒成功過。 原因是 Vercel 上的 Node 版本被釘在 18.x，而 Node 18 已經下架，建置在 clone 完就中止。那個版本號只存在 dashboard 的下拉選單裡，沒進版本控制，所以沒有任何東西會提醒我
/contact 的表單是死的。 <form action="">，送出不會有訊息送達任何地方。掛在站上三年，訪客按了以為寄出，我什麼都沒收到
post-6 裡我寫「目前暫定 6/7(三) 前要給回應，到時再更新狀況」，然後三年沒回來改那一行
7 篇文章裡有 16 處格式錯誤，中文散文被包在程式碼區塊裡，在網頁上被語法高亮切成隨機顏色

這些沒有一項是「我知道但懶得修」。全部都是我不知道。

一個沒有人在看、也沒有任何機制會回報狀態的系統，就是會這樣安靜地爛掉，而且爛的過程完全沒有聲音。

這次補的是機制，不是決心

說「以後會常常更新」沒有用，我三年前就說過類似的話了

所以這次回來，我沒有先寫文章，而是先把上面那些坑補起來，而且是用下次會自己叫我的方式補：

Node 版本寫進 package.json 的 engines，變成一個有 diff、有 commit 記錄的東西，而不是下拉選單裡的一個選項
死掉的表單整頁移除，聯絡方式改成一個實測收得到信的信箱
補上每頁的 title 與 description、sitemap、RSS。在那之前，/blog、/portfolio 加上 7 篇文章頁，九個頁面全部連 <title> 標籤都沒有
寫了一支檢查器，接在存檔的 hook 上。以後只要文章格式有問題，當場就會被擋下來，不用等我想起來去檢查

最後這一項是我覺得最重要的。那 16 處格式錯誤，我當年每一處寫下來的時候都覺得很合理。

不會覺得有錯的錯誤，不會有人主動去檢查。 所以能救的只有機制，不是提醒自己要小心。

所以呢

不做承諾，只講現在的狀態

我不打算說「以後會固定更新」。三年前的我大概也不覺得自己會停三年。

能說的只有：現在網站是活的，信箱是通的，寫壞了會有東西擋我，而我手上重新有了一些「搞懂了、可以拿出來講」的東西。就先這樣，寫得出來就寫。

如果你也有一個停更很久的部落格，我猜你的狀況可能跟我一樣。不是懶，是那段時間你正在變成一個新的菜鳥。

那沒什麼好丟臉的，等你從同手同腳變回會上籃，東西自然就寫得出來了。

面試日記 - 一場自己講的七零八落的線上面試，真的也是種經驗。

Wed, 24 May 2023 00:00:00 GMT

今天去面試的大略狀況

是台中的一間博弈產業公司，特別開設的全遠端的職缺。

該公司屬於大家認知上的那種博弈，面談過程就是自我介紹之後，彼此做一些了解以及口頭上的技術測試，
很多基本的東西我(比如 Box-Model)一時忘記名詞，講得是有多七零八落就多七零八落，我內心很無言 😰

面試結果

Get Offer

因為還有一些面試行程要跑，所以我還沒回覆，目前暫定 6/7(三) 前要給回應，到時再更新狀況。

筆試題目複習

題目沒有完全記得很清楚，我大致上描述，盡量還原題型。

請描述一下 Box-Model 是什麼

我第一個念頭想說，是不是在問我 Pop-up、Light-box 的概念，如果要跳出一個燈箱或提示訊息我會怎麼處理？那跟面試官確認了一下知道是自己誤會大了，其實就是 CSS 的盒模型，也就是區塊元素的組成是如何組成？

那大概描述一下，由內到外分別是 Content > padding > margin (這邊我回答時少講了border)

請描述一下，CSS排版時，要如何做垂直置中

我這邊是先向面試官確認，是這側的置中抑或是這側的置中？（比手畫腳），那面試官比給我的是"水平、垂直"都要置中

我大致上描述可能有哪幾種方法：

{
    display:flex;
    justify-content:center;
    align-items:center;
}

{
    position: absolute;
    left: 50%;
    top: 50%;
    transform: translate(-50%, -50%);
}

請描述一下 https 跟 http 的差異是什麼

我還一時半會真的不知道要怎樣描述https，全世界都知道他加密，但它原理是怎樣啊？ (內心吶喊 : 好想 Google)

我大概描述了一下:基本上HTTPS 比起 HTTP 就是多了加密形式去傳輸資料，比如說我在表單送出資料之後，如果被攔截應該也會是亂碼之類的。至於加密的原理跟詳細方式，老實說我不太清楚。

這邊後來Google了一下資訊，也幫大家做個補充。

HTTPS的基本原理就是 HTTPS 使用加密協議來加密通信。該協議稱為傳輸層安全性 (TLS)，以前叫做 SSL。該協議通過使用所謂的公鑰基礎設施來保護通信。這種類型的安全系統使用兩個不同的密鑰來加密兩方之間的通信。

參考來源 - AWS上關於http以及https的差異
 參考來源 - 熊貓先生
 參考來源 - YoJanni的轉職前端筆記本

請描述一下一個網頁如果 console 噴錯了，你大致上排除錯誤的流程會是如何？

這邊我是描述說:大致上會先看一下錯誤訊息是噴什麼，有沒有什麼低級錯誤，然後才去確認看看是哪個 function 或是源頭在哪，確認一下是前端功能的問題還是在 Call API 回來時沒處理好的問題，可能非同步的部分有疏忽了，導致資料還沒確定取得時，所寫的功能就跑了一些方法導致噴錯。這邊突然想到TS想說也順便描述一下，但TS應該在編譯前就會噴錯。（面試官也有回應我這點，是我這裡疏忽了）。

過往有沒有遇過什麼狀況是自己排除不了，問了同事之後，甚至也問到主管之後，還是沒辦法解決的話，要怎麼處理？

這邊我是如實描述說:過往還沒有遇過真的都問到主管那端，還沒辦法解決的問題，基本上遇到問題會先盡量去排除狀況，到方向比較明確之後，才去問資深的前輩，還是不行才會到主管那邊。

有沒有遇過 CORS 的問題？怎麼處理的？

這邊我是回答:基本上如果遇到 CORS 的問題，我會先和後端確認一下是不是沒設定好，那假設今天開發上，的確需要有跨來源的請求，那應該是需要透過反向代理伺服器去和後端Server發請求，也就是前端改為向反向代理伺服器發請求而不是直接向後端Server發請求。

有客製化過什麼hook嗎？

這邊是提到說:過往有把一個撈資料用的功能，比如說 Fetch 某支 API，把非同步的功能都寫好之後，包成一支 useFetch()，那團隊可以引入這支功能，一起使用

主要是避免其他人有非同步沒處理好的問題。

但後來想想應該是想知道說，如何複用一些功能，而不是該功能在做什麼。

面試反省

這次面試的時候稍微有點緊張，很多問題跟面試官有點牛頭不對馬嘴，一方面是第一次在線上面對多個面試官，一方面自己近期都沒在使用前端框架開發東西，很多原裡已經不太熟悉，所以之後首要就是先去熟悉以前的基本功？！

面試日記 - 當你被貓吵整晚不能睡，還要出發去面試跟筆試時。

Tue, 23 May 2023 00:00:00 GMT

正式面試前

心裡MurMur：一不小心騎過頭，該公司在西屯區，我差點前往龍井區品茶。

習慣提早出門的我，想說應該給人資跟面試官一個良好印象，早一點抵達做點準備也好，結果不知道是不是都沒什麼睡，頭腦發昏外加路不熟整個騎過頭，還好沒遲到，差點就可以直接右轉回家睡覺，也不用面試了。

一到公司樓下是一棟很氣派的大樓，不知是不是不成文的規定，好像博弈類的公司都在這種很氣派的大樓裡面。到公司後剛好遇到人資小姐姐經過門口幫我開門，進去之後稍微聊一下我如何成為前端工程師，以及了解我成為工程師之前的職業跟經歷。

後來面試官也有再問我一次工程師之前的經歷，履歷上面我沒完整列出從當完兵到成為工程師之前的經歷，是因為之前在Linkedin上，有幾名獵頭建議我非工程師的經歷其實可以不用列出來，我覺得很有道理就這樣調整了。

我認為工程師大多就是看過往做過哪些專案，然後技術的了解程度到哪，所以去年底開始到現在一直在盡力多做一些 Side Project 充實自己的 Github ，也盡量慢慢提升自己的能力，以前很多東西都只在工作中用用而已，過一陣子就忘記了，沒有好好記錄下來滿可惜的，現在重新把很多資訊輸入腦袋後再做一次輸出，感覺還是挺不錯的，對自己也慢慢多了點信心。

今天去面試的大略狀況

是台中的一間合法博弈產業公司

該公司有自己的產品，一個還滿知名的線上娛樂城，廣告很常看到，這類型產業在台灣很盛行，大多是走合法路線，自己也不排斥這產業。　　

面試流程除了前面跟人資小姐姐聊完之後，接著就是筆試最後再跟三位面試官面談，因為剛好該公司團隊是用自己比較喜歡的技術 React 做開發(內心老淚縱橫😭)，加上三位面試官很願意給我回饋，就趁這個機會跟三位面試官多請教請教，一不小心就聊到快中午，自己有點不好意思耽誤他們太多時間，不然還有滿多事情想跟面試官請教一番，很謝謝能跟他們聊這麼多。

筆試題目複習

題目沒有完全記得很清楚，基本上從CSS到JavaScript都有考到，大概分幾個方向

CSS的原理及排版方式
JavaScript的原理、寫法以及陣列的方法
型別的運算比較，比如經典的 1<2<3 以及 3>2>1
下面會記錄一下題目跟答案，跟我為什麼寫錯XD，然後再多做點補充

CSS的原理及排版方式

Id Selector > Class Selector > Type Selector (這題我寫成Id Selector > Type Selector > Class Selector)

我一時忘記Type Selector是哪個選擇器，腦袋中浮現的是div[data-color=red]，記得這個跟class是同等級，後來問面試官才知道Type Selector就是指Element，h1、h2、p那些標籤。

另外還有如何水平垂直置中、flex 排成直的一些排法等等，我自己通常如果是口頭測驗，會先確認水平置中、垂直置中、水平垂直置中三種考官要問哪種，不過概念大致上相同是也還好。

margin 邊界重疊的三種解法

比較要提的是 margin 邊界重疊的三種解法，自己很常利用padding去設定間距，所以很少遇到這類問題，後來詢問面試官其他的解法，原來可以幫元素加上clear-fix的屬性，我以前只知道是用來清除 float 的浮動問題，原來也可以解決 margin 邊界重疊的狀況，長知識了！

參考MDN - margin 邊界重疊的內容

Function.call() / Function.apply() 的差異

這題考如果要傳第二個參數，要傳陣列進去還是透過展開運算子傳一堆數字進去。真的滿久沒看到這兩個方法，大抵上知道是關於this的綁定，但我忘記實際寫法以及後面參數要傳什麼，最後也是跟面試官請教才回憶起來。

// 定義測試用函式，箭頭函式的this會根據語意指定作用域，故這邊不用箭頭函式
function testFunction (a, b) {
    console.log(this.name, a, b);
}

// 定義測試用物件
const obj = { name: 'Hubert Hsieh'};

// Assign function in obj
obj.func = testFunction;
obj.func(1, 2);

// 第一個參數選擇要指定this到哪，也可以是null
testFunction.apply(obj, [1, 2]); // 傳一個陣列進去
testFunction.bind(obj)(1, 2); // 依次傳參數
testFunction.call(obj, 1, 2); // 依次傳參數

Promise 語法

關於Promise相關的考題，這邊考了兩個方向

Promise 內運算的結果及Promise all方法的概念。
Promise 的寫法如何用 async/await 的方式改寫。

這邊自己覺得答題時沒有寫得很好，不過基本的概念自己還算是清楚的，Promise語法的出現是為了解決早期在做非同步處理時，必須不斷的透過CallBack去確保正確取到值之後，再執行某些運算或功能，當函式結構變得龐大時，程式碼就會越來越複雜，甚至會看到類似波動拳的巢狀結構。

Promise.all 則是可以等待多個 Promise 函式全部執行完成後，再回傳陣列結果，通常就是如果有多支 API 要一起執行時會運用到。

那 async / await 就是可以用類似同步執行的程式碼寫法，來處理非同步的事情，本質跟用Promise其實是差不多的。但是可讀性就高很多(這點可能見仁見智，我個人是習慣這樣寫，再利用 Try 集中處理 Success 相關的功能，Catch 處理 Error 時相關的功能)

// async / await的方式
const asyncFunction = async () => {
	try {
		const dataA = await fetchDatarA;
		const dataB = await fetchDatarB;
		console.log(dataA, dataB); 
	} 
	catch(error) {
		console.log('async function error', error);
	}
}

陣列的方法 - sort、reduce

sort 這邊考的是，一個物件陣列如何透過某個 key 的 value 去做排序?
reduce 我忘記題目考什麼了。

sort() 基本概念是，如果沒有指定一個比較功能的參數，它會將每個元素轉成字串之後，第一個字元的 Unicode 編碼位置去排序。reduce() 基本概念是，他可以不斷地跟上一個回傳的值再作運算，最後回傳該值。跟 map 相比不同的是，map 是回傳一個新陣列。

// sort()
// 簡單定義一個隨意排列的物件陣列
const sortArr = [
	{name: 'Alex', age: 33},
	{name: 'Hubert', age: 34},
	{name: 'Chris', age: 32}
]

// 依造每個元素的年齡大小去遞增排序
const sortResult = sortArr.sort((a, b) => {
	return a.age > b.age ? 1 : -1;
})

// result
[
    {name: 'Chris', age: 32},
    {name: 'Alex', age: 33},
    {name: 'Hubert', age: 34}
]

// reduce()
// 基本語法

array.reduce((accumulator, currentValue) => { do something... },  initialValue)

// example
const array = [1, 2, 3, 4];

// 0 + 1 + 2 + 3 + 4
const sumWithInitial = array.reduce((accumulator, currentValue) => accumulator + currentValue,  0);

// Expected output: 10
console.log(sumWithInitial);

參考MDN - Array.prototype.sort()
參考MDN - Array.prototype.reduce()

型別的運算比較，比如經典的 1<2<3 以及 3>2>1

console.log以下狀況的結果，這邊牽扯 JavaScript 的各種運算子在運算時，如果是不同型別會做甚麼處理以及回傳什麼結果。

1<2<3：可以先判斷 1<2 是 true，重點就變成 true<3 會回傳什麼呢?
3>2>1：可以先判斷 3>2 是 true，重點就變成 true>1 會回傳什麼呢?
true+'xyz'： true 是布林值，那重點就變成布林值+字串會變成什麼呢?

上述幾點就需要先了解 JavaScript 的強制轉型別的概念(很雞婆？)

{key: "value"}：理論上會把物件印出來沒錯，只是很有可能一般實務上物件console出來的值未必是如自己所想的那樣！

物件的console-bug，詳情可以看看Huli大大的文章

面試反省

我覺得我每次面試的時候都有點嘴笨，太過緊張都有點詞不達意，比如面試官問我有沒有處理過什麼複雜的資料結構，當下心裡想的是，應該都還可以，不管接收到什麼樣的格式，看實務需求需要怎麼重新整理跟排列就去處理。結果我跟面試官說我沒有處理過什麼太複雜的資料結構(面試官應該很驚恐?!)，其實應該先確認一下複雜的定義是什麼再作回答才對。

然後討論 reduce() 的用法時，也問了面試官說 reduce() 很常用到嗎？但我意思其實是很常只透過 reduce() 處理好某筆資料，還是說會寫比較多行，比如說先 filter() 再 map() 之類的，讓整段 code 雖然變冗長，但是可讀性變高呢？

之後參加任何面試應該要多思考，緩一點回答才好，想不出來的慢慢想，最後讓面試官打斷思考也沒關係，不要都不思考XD

平常心平常心吧，Hubert QQ。

附上那天面試大致上考題的 CodePen 參考

面試日記 - 和接案公司面對面，案子如繁星點點。

Mon, 22 May 2023 00:00:00 GMT

今天去面試的大略狀況

是台北的一間接案公司，台中也有辦公室，專門解決客戶提出的需求。

面試過程是在 2023.05.22 先透過 Google Meet 和人資小姐姐一面，彼此以討論聊天的形式，了解一下公司大致上有哪幾種專案、有哪些團隊的組成，以及了解一下我的職涯目標與人生規劃。 2023.05.29 的時候和技術長二面，主要問實務開發上遇到的一些問題要怎麼排除，或是如果有哪些狀況要怎麼解決。

面試結果

Get Offer

筆試題目複習

題目沒有完全記得很清楚，我大致上描述，盡量還原題型。

請描述一下，假設有一個按鈕按下去會發出一個請求，那如果使用者短時間內反覆點擊，要如何確保能正確取得 Response

一開始我是先向面試官確認，在什麼情況下會用一個按鈕一直對同一個接口連續發請求？一般不是會在點擊按鈕觸發請求取得回應的過程中，透過Loading狀態去做一些判斷，避免按鈕能夠被使用者連續按？　

這邊可能問的不是很好，主要是想確認說，是不是希望我描述如何透過防抖或節流的方式，去防止使用者不斷地送出請求，以我自己實際應用過的例子來舉例，比如在監聽Scroll事件時，防止一滾動就一直重複觸發事件，影響效能！或是input輸入時，有時要依據輸入內容做請求，假設是a、b、c，每次字元KEY完都發請求的話，也會發送太多請求，所以可以透過節流的方式，當短時間內觸發的同一請求，就以最後(最新)觸發的為原則去送出請求。

太晚才回來補面試的過程，很多細節忘記了，但大多數是圍繞在這一題上討論，自己後續在新公司工作其實也常常在思考一些效能上的問題，像是如何避免撈取重複的資料，然後相同的請求只要在A頁面拉取一次，B頁面也能共用，等等的課題，都是前端工程師後期應該多考慮的點。

// 簡單的防抖(debounce)概念
var timer; // 全域 Timer
function debounce(fn, delay){
    if(timer){
        clearTimeout(timer)
    }
    
    timer = setTimeout(function(){
        fn();
    }, delay);
}
window.onscroll = function(){
    debounce(test, 1000)
}
function test(){
    console.log('滾動停止')
}

2026 年回頭補正：上面這段是「防抖(debounce)」不是「節流(throttle)」，當年把兩個名詞混著用了。

差別在於：防抖是每次觸發都把計時器歸零，只有停下來超過 delay 才執行一次，所以是「最後一次說了算」；節流是不管你觸發幾次，一段時間內最多只執行一次，是「固定頻率」。上面第二段講的「以最後(最新)觸發的為原則」其實就是防抖的行為。

回到面試那題（按鈕連點）：上面這種「停下來才執行」的防抖，用在送出按鈕上會讓使用者點完還要等 delay 才真的送出，體驗其實不好。更直接的做法就是這篇一開始自己講的：用 loading 狀態把按鈕鎖起來。防抖與節流比較適合 scroll、resize、輸入即時搜尋這類會連續觸發的事件，也就是原文舉的那兩個例子。

請描述一下，CSS排版時，要如何做垂直置中

經典題目，大部分公司都會問一下，確認一下基本切版的知識。

我大致上描述可能有哪幾種方法：

{
    display:flex;
    justify-content:center;
    align-items:center;
}

{
    position: absolute;
    left: 50%;
    top: 50%;
    transform: translate(-50%, -50%);
}

{
    display: grid;
    place-content: center;
}

前端知識 - React的生命週期：一元復始，萬象更新。

Thu, 18 May 2023 00:00:00 GMT

React的生命週期

Mount(創建): 元件被渲染到畫面上(渲染後的節點加入DOM)
Update(更新): 元件的內容因為資料的更動而重新渲染(比較虛擬DOM和實際DOM之間那些地方有變化 - Re-Rendered)
Unmount(銷毀): 元件從畫面上消失，移除這個元件

Mounting

在元件一開始 Mount 的時候，初始化會先經過建構子 Constructor，Constructor 會完成所有必要的 initial 過程，像是初始化state、初始化ref物件等等。

constructor()
render()
componentDidMount()

Updating

當元件的 props 或 state 更新，重新渲染 (re-rendered) DOM 時會觸發。

static getDerivedStateFromProps()
shouldComponentUpdate()
render()
getSnapshotBeforeUpdate()
componentDidUpdate()

Unmounting

註銷元件，當元件從 DOM 中被移除時會觸發。

componentWillUnmount()

附上 React 生命週期簡易 Demo，大家可以從 Console 看看每個生命週期的 Method 是如何被調用的

// Destructuring assignment
const { Component, Children, PropTypes, useState, useEffect } = React

// Class Component
class MessageClassComponent extends Component {

    // 初始化狀態、屬性
    constructor(props) {
        super(props);

        this.state = {
            message: 'Welcome guest, this message in the Class Component.'
        };
    }

    // static 靜態函數，因此無法操作 class 中的屬性 (ex. this.state)。
    // 在每次 re-rendering 前會被調用，
    static getDerivedStateFromProps(props, state) {
        console.log('在每次 re-rendering 之前會調用 getDerivedStateFromProps');
        return null;
    }

    // 元件Render完成時，調用一次
    componentDidMount() {
        console.log('元件Render完成，調用一次 componentDidMount()');
    }

    // 如果 props 或 state 發生變化，re-rendering 前會調用， 回傳 false 會阻止按鈕點擊
    shouldComponentUpdate(nextProps, nextState, nextContext) {
        console.log('props 或 state 發生變化， shouldComponentUpdate() 回傳true / false');
        return true;
    }

    // 要和 componentDidUpdate 一起使用
    getSnapshotBeforeUpdate(prevProps, prevState) {
        console.log('getSnapshotBeforeUpdate， 更新前取得原本狀態');
        return null
    }

    // 元件屬性或狀態改變，調用一次
    componentDidUpdate(prevProps, prevState, snapshot) {
        // console.log('prevProps', prevProps);
        // console.log('prevState', prevState);
        // console.log('snapshot', snapshot);

        if (this.state.message !== prevState.message) {
            console.log('State Change!, componentDidUpdate invoked.');
        }
    }

    // 在 component 即將從DOM中移除之前，componentWillUnmount
    componentWillUnmount() {
        console('組件即將移除，componentWillUnmount invoked once.');
    }

    handleMessage = () => {
        this.setState({
            message: 'Hey guy, you change this message.'
        })
    }

    render () {
        const { message } = this.state;

        return (
            <div className="block">
                <h2>{ message }</h2>

                <button onClick={() => this.handleMessage()}>
                    改變文字
                </button>
            </div>
        )
    }
}

// Functionl Component
const MessageFunctionlComponent = () => {
    const [message, setMessage] = useState('Welcome Guest, this message in the Functionl Component.');

    // 每次 render 結束時，觸發 useEffect
    useEffect(() => {
        console.log(`message will be ==> ${message}`);
    });

    return (
        <div>
            <h2>
                { message }
            </h2>

            <button onClick={() => setMessage('Hey guy, you change this message.')}>
                改變文字
            </button>
        </div>
    )
}

後端知識 - 前端工程師的Spring Boot成長日記。

Wed, 17 May 2023 00:00:00 GMT

開發環境設定

Mac OS

Homebrew

$ /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
$ brew install git //安裝git

oh-my-zsh

$ sh -c "$(curl -fsSL https://raw.github.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"

$ brew tap AdoptOpenJDK/openjdk
$ brew install --cask adoptopenjdk11

Windows開發環境設定

Create New Project

Prederences - Spring Initializr + Project SDK Java 11

基本專案結構以及了解SpringBoot特性

src/main - 放我們要寫的Code
src/main/java - 放Java Code
src/main/resource - 放Spring Boot設定檔
src - test - 放測試用的Code

package com.example.helloworld;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;

@SpringBootApplication <= 加在Class上的註解，使電腦能夠運行SpringBoot的程式
public class HelloWorldApplication { 

    public static void main(String[] args) {
        SpringApplication.run(HelloWorldApplication.class, args);
    }

}

Spring IoC(Inversion of Control) 控制反轉

主要概念 - 將Object的控制權交給外部的Sprint Container來保管

優點

Loose coupling 鬆耦合
Lifecycle Management 生命週期管理
More Testable 方便測試程式

範例

public class Teacher {

    private Printer printer = new HpPrinter();
    
    public void teach() {
        printer.print("I am a Teacher");
    };
    
}

------ 改成以下這樣 ------

public class Teacher {

    private Printer printer;
    
    public void teach() {
        printer.print("I am a Teacher");
    };
    
}

說明

@Component 用法 (@RestController類似)

用法：只能加在class上
用途：將該class變成由Spring容器管理的Object(Bean)

@Component <= 將該class變成由Spring容器管理的Object(Bean hpPrinter)
public class HpPrinter implements Printer {
    
    @Override
    public void print(String message) {
        System.out.println("HP印表機: " + message);
    }
    
}

透過依賴注入 Dependency Injection
@Component
public class Teacher {
    
    @Autowired
    private Printer printer;
    
    public void teach() {
        printer.print("I am a Teacher");
    };
    
}

Spring IoC 專有名詞整理

IoC=Inversion of Control (控制反轉)
DI=Dependency Injection (依賴注入)
Bean=存放在Spring容器裡的Object
@Component註解=加在class上，將該class變成由Spring容器管理的bean
@Autowired註解=加在變數上，取得Spring容器中的bean

@Autowired以及@Qualifier 詳解

兩種註解寫法沒有順序性

@Autowired

用法：通常是加在class變數上
用途：根據變數的類型，去Spring容器中尋找有沒有符合類型的bean
變數的類型盡量使用Interface

@Qulifier

用法：通常是加在class變數上，會跟@Autowired一起使用
用途：指定要載入的bean的名字

小結

@Autowired：根據變數的類型，去Spring容器中尋找有沒有符合類型的bean
@Qulifier：輔助@Autowired，指定要載入的bean的名字

創建Bean的方法

在Class上加上 @Component註解
使用 @Configuration + @Bean 註解
兩種方法可以混用

@Configuration

用法：只能加在class上
用途：Spring中的設定用註解，表示這個class是拿來設定Spring用的


@Configuration
public class MyConfiguration { // class的名字不重要
    // do something
}

@Bean

用法：只能加在帶有@Configuration class 的方法上
用途：在Spring容器中創建一個Bean


@Configuration
public class MyConfiguration { // class的名字不重要
    
    @Bean
    public Printer myPrintr() {
        return new HpPrinter();
    }
}

Spring容器中產生的bean的預設名字會是方法的名字 myPrinter
如果是@Bean("xxx") 產生的bean的名字就會是xxx

Bean的初始化

@PostConstruct

用法：加在方法上
細節：使用@PostConstruct的時候
- 方法：public
- 返回類型：void
- 方法名稱：任意取名但不含參數 e.g. init()

@Component
public class HpPrinter implements Printer {

    private int count;

    @PostConstruct
    public void initialize() {
        count = 5;
    }

    @Override
    public void print(String message) {
        count--;
        System.out.println("HP印表機： " + message);
        System.out.println("剩餘使用次數： " + count);
    }
}

實現@InitializingBean 這個 Interface

用法：實現 Interface
細節：使用@InitializingBean的時候，必須要再實現裡面的afterPropertiesSet()方法

@Component
public class HpPrinter implements Printer, InitializingBean{

    private int count;
        
    @Override
    public void afterPropertiesSet() throws Exception {
        count = 5;
    }
    

    @Override
    public void print(String message) {
        count--;
        System.out.println("HP印表機： " + message);
        System.out.println("剩餘使用次數： " + count);
    }
}

Bean的生命週期

創建Bean => 初始化Bean => Bean可以被使用
有多個Bean的話，要每一個Bean都可以正常被使用才能運行成功
Bean之間的依賴關係 e.g. myController依賴於Printer
避免以下循環依賴類型寫法

@Component
public class A {

    @Autowired
    private B b; // A依賴於B
}

@Component
piblic class B {

    @Autowired
    private A a;
    
}

小結
- Bean的生命週期：創建->初始化->可以被使用
- 創建時若有依賴其他Bean，則Spring會回過頭去「創建 + 初始化」那個被依賴的Bean
- 不要寫出循環依賴的Code

Bean的生命週期讀取Spring Boot設定檔 - application.properties + @Value

Spring Boot設定檔 - application.properties

用法：使用properties語法(key=value)
用途：存放Spring Boot的設定值
細節：檔名一定是application

# example
count=5
my.name=Hubert
my.age=33

@Value

用法：加在Bean或是設定Spring用的class裡面的變數上
用途：讀取Spring Boot設定檔(application.properties)中指定的key的值

# application.properties
count=5
my.name=Hubert
my.age=33

public class MyBean {

    @Value("${count}")
    private Integer number; // number=5
}

Spring IoC總結

IoC = Inversion of Control (控制反轉)
- 將object的控制權交給外部的Spring容器管理
- 存放在Spring容器裡的object，稱為Bean
DI = Dependency Injection (依賴注入)
- 和IoC相輔相成
創建Bean的方法
- @Component
- @Configuration + @Bean
初始化Bean的方法
- @PostConstruct
- 實現InitializingBean interface
注入Bean的方法
- @Autowired
- 多個Bean可以搭配@Qualifier
Bean的生命週期
- 創建 -> 初始化 -> 可以被使用
- 創建時若有依賴其他bean，則Spring會回過頭去「創建+初始化」那個被依賴的bean
- 不要寫出循環依賴的code
讀取Spring Boot設定檔(application.properties)的值的方法
- application.properties+@Value

Spring AOP(Aspect-Oriented Programming) 切面導向程式設計

基本概念

將每個方法內重複執行的共同邏輯，設計成一個切面貫穿所有方法，由切面統一做處理。

// pom.xml 新增設定
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-aop</artifactId>
</dependency>

Example

用法：加在class上，需和@Component一起使用
用途：宣告這個class是一個切面
換言之這個class必須成為一個bean才能夠成為切面

@Aspect
@component
public class MyAspect {
    // do something
}

@before

用法：加在切面的class上
用途：在切入點的方法執行前執行

@Aspect
@component
public class MyAspect {
    
    @Before("execution(* com.example.demo.HpPrinter.*(..))") // 切入點(Pointcut)
    public void before() {
        System.out.println("I am before");
    }
}

@After

用法：加在切面的class上
用途：在切入點的方法執行後執行

@Aspect
@component
public class MyAspect {
    
    @After("execution(* com.example.demo.HpPrinter.*(..))") // 切入點(Pointcut)
    public void before() {
        System.out.println("I am before");
    }
}

@Around

用法：加在切面的class上
用途：在切入點的方法執行前後都執行

@Aspect
@component
public class MyAspect {
    
    @Around("execution(* com.example.demo.HpPrinter.*(..))") // 切入點(Pointcut)
    public Object around(ProceedingJoinPoint pjp) throws Throwable {
        System.out.println("I am around before");
        Object obj = pjp.proceed(); // 去執行原本切入點的方法
        System.out.println("I am around after");
        return obj;
    }
}

Spring AOP提供的註解

常用
- @Before：在切入點的方法執行前執行
- @After：在切入點的方法執行後執行
- @Around：在切入點的方法執行前後都執行
不常用
- @AfterThrowing：在切入點的方法拋出異常之後執行
- @AfterReturning：在切入點的方法執行成功之後執行

常見的切入點表達式

execution(* com.example.demo.HpPrinter.*(..))：切入點為com.example.demo package裡的HpPrinter class裡的所有方法
execution(* com.example.demo.*(..))：切入點為com.example.demo package裡的所有class的所有方法
execution(* com.example.demo..*(..))：切入點為com.example.demo package以及所有子package裡的所有class的所有方法
execution(* com.example.demo.HpPrinter.print())：切入點為com.example.demo.HpPrinter class裡的print()方法
@annotation(com.example.demo.MyAnnotation)：切入點為帶有@MyAnnotation的方法

Spring AOP的發展

權限驗證 / Spring Security
統一的Exception / @ControllerAdvice
Log紀錄

Spring AOP的總結

AOP = Aspect-Oriented Programming (切面導向程式設計)
創建切面的方法
- @Aspect + @Component
可使用的切面註解
- 常用：@Before、@After、@Around
- 不常用：@AfterThrowing、@AfterReturning
Spring AOP的發展
- 權限驗證 / Spring Security
- 統一的Exception / @ControllerAdvice
- Log紀錄

Spring MVC

HTTP協議

負責規定資料的傳輸格式，讓前端和後端能夠有效的進行資料溝通
可以分成Request(請求)和Response(回應)兩個部分
Http Request(請求)
- Method
  - GET
  - POST
  - PUT
  - DELETE
  - ...
- Url
  - http://localhost:8080/test -> 出現在瀏覽器中的網址
- Request header
  - 放一些通用的資訊
- Request body
  - 放請求參數
  - 只有在使用POST以及PUT時才能使用
Http Response(回應)
- Status Code(Http狀態碼)
  - 1xx：資訊
  - 2xx：成功 e.g. 200(Success)
  - 3xx：重新導向
  - 4xx：前端請求錯誤 e.g. 404(找不到網頁)
  - 5xx：後端處理有問題
- Response header
  - 放一些通用的資訊 e.g. Content-type：text/plain
- Response body
  - 很重要，放後端返回的數據

URL路徑對應

協議/域名/路徑 e.g. http://localhost:8080/test
@RequestMapping
- 用法：加在class上或方法上，小括號裡填寫url路徑
  - 使用@RequestMapping時，class上ㄧ定要加上@Controller或是@RestController
- 用途：將url路徑對應到方法上
- 運行原理：
```
@RestController
public class MyController {
    
    @RequestMapping("/test")
    public String test() {
        System.out.println("Hi");
        return "Hello World";
    }
}
```
@Controller / @RestController
- 用法：加在class上
- 用途：將該class變成bean，並且可以使用@RequestMapping
  - 可以思考成 @Component的加強版

結構化的呈現數據 Json

Json

一種輕量級的資料交換格式，易於讀寫
目的：結構化的呈現數據

{
    "id": 3345678,      // "key": value
    "name": "Hubert",   // "key": value
    "inervice": true    // "key": value
}

回傳Json格式 @RestControler、@Controller + @ResponseBody

Spring Boot使用Jackson library去轉換Java class和Json格式

public class Student {
    String name;

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }
}


@RequestMapping("/detail")
@RestController
public class MyController {

    @RequestMapping("/user")
    public Student user() {
        Student student = new Student();
        student.setName("Hubert");
        return student;
    }
}

Http method - GET和POST

有多種可以選，每一種的特性不同
常用的http method
- GET
- POST
- PUT
- DELETE
- ...

GET

最常使用的http method
類似於明信片的概念，傳遞的參數會被別人看見

http://localhost:8080/test?id=123&name=Hubert

POST

常使用的http method
類似於信封的概念，傳遞的參數不會被別人看見，安全性較高

http://localhost:8080/test

// Request Body
{
    "id": 123,
    "name": "Hubert"
}

取得前端請求參數

@RequestParam
@RequestBody
@RequestHeader
@PathVariable

@RequestParam

用法：只能加在方法的參數上
用途：取得url裡面的參數 query parameter

http:localhost:8080/test1?id=123&name=Hubert

public class MyController {
    
    public String test1(@RequestParam Integer id
                        @RequestParam String name) {
        // do something
    }
}

@RequestParam 可使用的設定

name(or value)：指定url參數的名字，不常使用

http:localhost:8080/test1?testId=123

public class MyController {
    
    public String test1(@RequestParam(name = "testId") Integer id) {
        // do something
    }
}

required：是否是必須的參數？
- 預設是true，可以改成false

http:localhost:8080/test1?id=123&name=Hubert

public class MyController {
    
    public String test1(@RequestParam(required = false) Integer id) {
        // do something
    }
}

defaultValue：提供預設值，最常使用
- 可以想成required=false的加強版，提供預設值

http:localhost:8080/test1?id=123&name=Hubert

public class MyController {
    
    public String test1(@RequestParam(defaultValue = "10", required = false) Integer id) {
        // do something
    }
}

@RequestBody

用法：只能加在方法的參數上
用途：取得request body裡面的參數(將Json轉為Java object)

    // class物件
    public class Student {
        Integer id;
        String name;

        public Integer getId() {
            return id;
        }

        public void setId(Integer id) {
            this.id = id;
        }

        public String getName() {
            return name;
        }

        public void setName(String name) {
            this.name = name;
        }
    }
    
    // example
    @RequestMapping("/test2")
    public String test2(@RequestBody Student student) {
        System.out.println("student id: " + student.getId());
        System.out.println("student name: " + student.getName());
        return  "Hello test2";
    }

@RequestHeader

用法：只能加在方法的參數上
用途：取得request header裡面的參數，跟RequestParam很類似

    // request header
    info:hello
    
    // example
    @RequestMapping("/test3")
    public String test3(@RequestHeader String info) { // hello

    }

@RequestHeader 可使用的設定

name(or value)：指定url參數的名字，經常使用

http:localhost:8080/test1?testId=123

public class MyController {
    
    public String test1(@RequestParam(name = "Content-Type") String contentType) {
        // do something
    }
}

required：是否是必須的參數？
- 預設是true，可以改成false
defaultValue：提供預設值，最常使用
- 可以想成required=false的加強版，提供預設值

http:localhost:8080/test1?id=123&name=Hubert

public class MyController {
    
    public String test1(@RequestParam(defaultValue = "10", required = false) Integer id) {
        // do something
    }
}

常見的 request header

Content-Type：表示request body的格式
- application/json(Json格式，最常用)
- application/octet-stream(用於上傳文件)
- multipart/form-data(用於上傳圖片)
Authorization：用於身份驗證

@PathVariable

用法：只能加在方法的參數上
用途：取得url路徑的值

    http:localhost:8080/test4/123/Hubert
    
    // example
    @RequestMapping("/test4/{id}/{name}")
    public String test4(@PathVariable Integer id, @PathVariable String name) { // 123

    }

@RequestParam 與 @PathVariable 的差異

@RequestParam：把參數放在url的最後面

    http:localhost:8080/test1?testId=123

@PathVariable：把參數放在url的裡面

    http:localhost:8080/test4/123

RESTful API的設計

取得商品列表的API

Http Request（請求）

GET /getProducts

Name	type	Description	Required
size	Integer	要取得幾個商品	yes
search	String	查詢的商品關鍵字	no

Http Response (回應)

Sample response body
{
  "productList": [
    {
      "id": 123,
      "name": "apple",
      "price": 30
    }
  ] 

}

http://localhost:8080/getProducts?size=10

@RequestMaping("/getProducts")
public Product getProducts(@RequestParam Integer size, 
                           @RequestParam(required = false) String search) {
    // do something...
}

API常見說法

這個getProducts API怪怪的，可以幫我看一下嗎？

@RequestMaping("/getProducts")
public Product getProducts(@RequestParam Integer size, 
                           @RequestParam(required = false) String search) {
    // do something...
}

你可以call getProducts API / 打 getProducts API
可以提供API文件嗎？

REST風格

目的：簡化溝通成本
如果你所設計的API符合REST風格，那麼你所設計的API就是RESTful API
- Beauty -> Beautiful
- Peace -> Peaceful
規範：使用http method表示動作，去對應資料庫的CRUD(增查改刪)

Http method	對應的資料庫操作	說明
POST	Create(新增)	新增一個資源
GET	Read(查詢)	取得一個資源
PUT	Update(修改)	更新一個已存在的資源
DELETE	Delete(刪除)	刪除一個資源

使用url路徑描述資源之間的階層關係

Http method	說明
GET/users	取得所有user
GET/users/123	取得user id為123的user
GET/users/123/articles	取得user id為123的user所寫的所有文章
GET/users/123/articles/456	取得user id為123的user所寫的、article id為456的文章

response body返回json或是xml格式
To REST or Not To REST ?
- REST風格只是一種約定俗成的習慣，不是標準規範
- 選擇最洽當的做法即可

實作 RESTful API

// 利用@NotNull註解就不用像以前一樣，如下
if(student.getId() == null) {
    throw new RuntimeException("id 不可以是 null");
}

驗證請求參數(常用)

@NotNull：不能為null
@NotBlank：不能為null、且不能為空白的字串，用在驗證String類型的參數上
@NotEmpty：不能為null、且size必須>0，用在驗證集合類型(List、Set、Map)的參數上
@Min(value)：值必須>=value，用在驗證數字類型的參數上
@Max(value)：值必須<=value，用在驗證數字類型的參數上

使用@RequestBody時，要在該參數上加上@Valid註解，才能讓這個class裡的驗證請求參數的註解生效

@PostMapping("/students")
public String create(@RequestBody @Valid Student student) {
    return "執行資料庫的Create操作";
}
    
public class Student {

    @NotNull
    Integer id;

    @NotBlank
    String name;
}

驗證請求參數(不常用)

@Size(min,max)：min <= 字串長度or集合的size <= max，可以只設max or min
@Email：必須符合電子郵件的格式
@Pattern(regexp)：必須符合正規表達式regexp
@Past：必須比當前時間早，也就是被註解的參數必須是以前的時間
@Future：必須比當前時間晚，也就是被註解的參數必須是未來的時間
@AssertTure：必須為true，用在驗證boolean類型的參數上
@AssertFalse：必須為false，用在驗證boolean類型的參數上
@Null：必須為null

使用@RequestParam、@RequestHeader、@PathVariable時，要在Controller上加上@Validated註解，才能夠讓驗證請求參數的註解生效


@RestController
@Validated
public class StudentController {

    @PostMapping("/students/{studentId}")
    public String create(@PathVariable @Min(100) Integer studentId) {
        return "執行資料庫的Create操作";
    }
}
    
public class Student {

    @NotNull
    Integer id;

    @NotBlank
    String name;
}

Http status code (Http狀態碼)

用來表示這次http請求的結果為何
可以根據首位數字分成五大類
- 1xx：資訊
  - 無常見的狀態碼
- 2xx：成功
  - 200 Ok：請求成功
  - 201 Create：請求成功且新的資源成功被創建，通常用在POST的response
  - 202 Accepted：請求已經接受，但尚未處理完成
- 3xx：重新導向
  - 301 Moved Permanently：永久性重新導向，新的url應放在response header的"Location"中返回，通常會用在網頁搬家上
  - 302 Found：臨時重新導向，新的臨時性的url應放在response header的"Location"中返回
- 4xx：前端請求錯誤
  - 400 Bad Request：前端的請求參數有錯誤(例如：前端傳給後端的參數名稱不同、請求的格式有問題)
  - 401 Unauthorized：沒有通過身份驗證
  - 403 Forbidden：請求被後端拒絕，通常是權限不足導致的
- 5xx：後端處理有問題
  - 500 Internal Server Error：後端在執行程式時發生錯誤，可能是程式內有bug導致的
  - 503 Service Unavailable：由於臨時維護或著流量太大，後端目前沒有辦法處理請求
  - 504 Gateway Timeout：請求超時

ResponseEntity<>

用法：作為方法的返回類型
用途：自定義回傳的http response的細節

@RestController
public class MyController {

    @RequestMapping("/test")
    public String test() {
        return "Hello World";
    }
}


@RestController
public class MyController {

    @RequestMapping("/test")
    public ResponseEntity<String> test() {
        return ResponseEntity.status(HttpStatus.ACCEPTED) 
                .body("Hello World");
    }
}

@ControllerAdvice

用法：只能加在class上，通常會和@ExceptionHandler一起用
用途：將這個class變成一個bean，並且可以在內部使用@ExceptionHandler

@ExceptionHandler

用法：只能加在方法上，通常會和@ControllerAdvice一起用
用途：去catch方法所噴出的Exception

使用@ControllerAdvice的好處 - 統一管理Exception

底層由Spring AOP所實作

// Java基礎

// 系統錯誤，不需處理
Throwable - Error - OutOfMemoryError

// 程式有錯誤，需要處理
Throwable - Exception - RuntimeException - IllegalArgumentException
Throwable - Exception - IOException

// 原生處理方式 try catch

public String test1() {
    try {
        throw new Runtime
    } catch () {
    
    }
}

// 503 exsample
// MyController && MyExceptionHandle

@RestController
public class MyController {

    @RequestMapping("/test1")
    public ResponseEntity<String> test() {
        throw new RuntimeException("This is test1 error");
    }
}

@ControllerAdvice
public class MyExceptionHandler {

    @ExceptionHandler(RuntimeException.class)
    public ResponseEntity<String> errorHandle(RuntimeException exception) {
        return ResponseEntity.status(HttpStatus.SERVICE_UNAVAILABLE).body("RuntimeException: " + exception.getMessage());
    }
    
    @ExceptionHandler(IllegalArgumentException.class)
    public ResponseEntity<String> errorHandle(IllegalArgumentException exception) {
        return ResponseEntity.status(HttpStatus.BAD_REQUEST)
                .body("IllegalArgumentException: " + exception.getMessage());
    }
}

攔截器Interceptor

// Controller
@RestController
public class MyController {

    @RequestMapping("/test1")
    public String test1() {
        System.out.println("執行 test1 方法");
        return "hello test1";
    }

    @RequestMapping("/test2")
    public String test2() {
        System.out.println("執行 test2 方法");
        return "hello test2";
    }
}


// MyInterceptor 
@Component
public class MyInterceptor implements HandlerInterceptor {

    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
        System.out.println("執行 MyInterceptor 的 preHandle 方法");
        return false;
    }
}

Spring MVC總結

Http 協議
- 規定前後端之間的資料傳輸格式
  - Http Request
  - Http Response
URL路徑的對應
- URL格式
- @RequestMapping
結構化的呈現數據
- Json的格式
- @RestController、@Controller + @ResponseBody
Http method
- GET
- POST
取得請求參數的方法
- @RequestParam
- @RequestBody
- @RequestHeader
- @PathVariable
如何設計 RESTful API
- REST風格：簡化溝通成本
實作 RESTful API
- @GetMapping
- @PostMapping
驗證請求參數的方法
- @NotNull、@NotBlank、@NotEmpty
- @Valid、@Validated
常見的Http狀態碼
- 依照首位數字分成五大類
- ResponseEntity<>
Controller層統一的Exception處理
- @ControllerAdvice + @ExceptionHandler
- 底層使用Spring AOP機制
攔截器Interceptor
- preHandle方法的返回值：true=允許通過，false=拒絕

Spring JDBC、Spring Data JPA

簡介：如何操作資料庫
Spring JDBC：在SpringBoot中執行原始的SQL語法，去操作資料庫
Spring Data JPA：使用ORM的概念，透過操作Java object的方式，去操作資料庫

使用IntelliJ 管理資料庫的數據

取代MySQL Workbench
- new DataSource => MySQL

# SQL Console 

CREATE DATABASE myjdbc

CREATE table student (
    id INT PRIMARY KEY ,
    name VARCHAR(30)
)

# 新增
INSERT INTO student(id, name) value(1, 'Hubert')

# 查詢
SELECT * FROM student

# 更新
UPDATE student SET name = 'Adam' WHERE id = 1

# 刪除
DELETE FROM student WHERE id = 1

資料庫連線設定

// pom.xml 新增設定 讓SpringBoot可以使用jdbc的功能
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-jdbc</artifactId>
</dependency>

// pom.xml 新增設定 添加MySQL Driver讓SpringBoot可以連線到MySQL資料庫
// Google maven mysql
<!-- https://mvnrepository.com/artifact/mysql/mysql-connector-java -->
<dependency>
    <groupId>mysql</groupId>
    <artifactId>mysql-connector-java</artifactId>
    <version>8.0.22</version>
</dependency>

// application.properties
// google database timezone
spring.datasource.driver-class-name=com.mysql.cj.jdbc.Driver
spring.datasource.url=jdbc:mysql://localhost:3306/myjdbc?serverTimezone=Asia/Taipei&characterEncoding=utf-8
spring.datasource.username=root
spring.datasource.password=springboot

設定完之後運行SpringBoot Spring JDBC會自動創建 NamedParameterJdbcTemplate這個Bean

使用NamedParameterJdbcTemplate(SpringBoot Bean) / INSERT、UPDATE、DELETE

根據sql語法分成兩類
- update()可執行的SQL語法
  - INSERT
  - UPDATE
  - DELETE
- query()、queryForObject()
  - SELECT

update(String sql, Map<String, Object> map) 基本用法

@RestController
public class StudentController {

    @Autowired
    private NamedParameterJdbcTemplate namedParameterJdbcTemplate;

    @PostMapping("/students")
    public String insert(@RequestBody Student student) {

        String sql = "INSERT INTO student(id, name) VALUE (:studentId, :studentName)";

        Map<String, Object> map = new HashMap<>();
        map.put("studentId", student.getId());
        map.put("studentName", student.getName());

        namedParameterJdbcTemplate.update(sql, map);

        return "執行 INSERT SQL";
    }

    @DeleteMapping("/students/{studentId}")
    public String delete(@PathVariable Integer studentId) {

        String sql = "DELETE FROM student WHERE id = :studentId";

        Map<String, Object> map = new HashMap<>();
        map.put("studentId", studentId);

        namedParameterJdbcTemplate.update(sql, map);

        return "執行 DELETE SQL";
    }
}

update(String sql, Map<String, Object> map) 進階用法

當table 的 id會自動增加時，要如何去取得id的值

@PostMapping("/students")
    public String insert(@RequestBody Student student) {

        String sql = "INSERT INTO student(name) VALUE (:studentName)";

        Map<String, Object> map = new HashMap<>();
        map.put("studentName", student.getName());

        KeyHolder keyHolder = new GeneratedKeyHolder();

        namedParameterJdbcTemplate.update(sql, new MapSqlParameterSource(map), keyHolder);

        int id = keyHolder.getKey().intValue();

        System.out.println("mysql 自動生成的 id 為： " + id);

        return "執行 INSERT SQL";
    }

要如何大量的執行一批 INSERT/UPDATE/DELETE sql


@PostMapping("/students/batch")
public String insertList(@RequestBody List<Student> studentList) {

    String sql = "INSERT INTO student(name) VALUE (:studentName)";

    MapSqlParameterSource[] parameterSources = new MapSqlParameterSource[studentList.size()];

    for(int i=0; i<studentList.size(); i++) {
        Student student = studentList.get(i);

        parameterSources[i] = new MapSqlParameterSource();
        parameterSources[i].addValue("studentName", student.getName());
    }

    namedParameterJdbcTemplate.batchUpdate(sql, parameterSources);

    return "執行一批 INSERT sql";
}

// 在update()內使用for迴圈也可達成一樣的效果，但是使用batchUpdate()效能較好
// 需要執行大量sql的時候，需考慮效能問題

for(int i=0; i<studentList.size(); i++) {
    Student student = studentList.get(i);

    Map<String, Object> map = new HashMap<>();
    map.put("studentName", student.getName());

    namedParameterJdbcTemplate.update(sql, map);
}


MapSqlParameterSource[] parameterSources = new MapSqlParameterSource[studentList.size()];

for(int i=0; i<studentList.size(); i++) {
    Student student = studentList.get(i);

    parameterSources[i] = new MapSqlParameterSource();
    parameterSources[i].addValue("studentName", student.getName());
}

namedParameterJdbcTemplate.batchUpdate(sql, parameterSources);

query(String sql, Map<String, Object> map, RowMapper<T'> rowMapper) 基本用法

第一個參數放的是要執行的sql語法

"SELECT id, name FROM student"

第二個參數放的是sql語法裡面變數的值
第三個參數 RowMapper 放的是將資料庫查詢出來的數據，轉變成Java object，最重要的參數
在寫SELECT sql時，不要使用*號
- 會產生效能問題，會花費額外的網路流量
- 無法提升資料庫查詢的速度
RowMapper：一次只能取得一條row，無法取得到其他row的資訊
ResultSetExtractor：一次可以取得到所有row的資訊，可以自由的組合不同row的數據

// StudentController
@GetMapping("/students")
public List<Student> select() {

    String sql = "SELECT id, name FROM student";

    Map<String, Object> map = new HashMap<>();

    List<Student> list = namedParameterJdbcTemplate.query(sql, map, new StudentRowMapper());

    return list;
}

// RowMapper
public class StudentRowMapper implements RowMapper<Student> {
    
    // 右鍵 Genertate implements 方法
    @Override
    public Student mapRow(ResultSet resultSet, int i) throws SQLException {

        Student student = new Student();
        student.setId(resultSet.getInt("id"));
        student.setName(resultSet.getString("name"));

        return student;
    }
}

query方法重點回顧

在SpringBoot裡寫SELECT sql時，不要使用*，要一一列舉想要查詢的column
query方法永遠會回傳一個List
- List裡面有可能有多筆數據、或是只有一筆數據、或是完全沒有任何數據
- 取得List中的數據前，記得要先判斷內部是否有數據
RowMapper
- 用途：將資料庫查詢出來的數據，轉換成Java object
- 可使用resultSet.getXxx(String column)取得column名字的值(推薦使用)
- 可使用resultSet.getXxx(int index)取得第幾順位的column的值
- resultSet所包含的column，就是SELECT sql中所查出來的那些column
ResultSetExtractor
- 和RowMapper用途一樣，只是比較強大，可以組合不同row之間的數據
- 較少用

MVC架構模式 Controller-Service-Dao 三層式架構

軟體工程(Software Engineering)

面對一個大型的系統，工程師們需要如何分工合作，一起去解決問題？
- Git版本控制：管理多位工程師所寫的程式

MVC架構模式是軟體工程中的一種軟體架構

用途：將系統拆分成Model、View、Controller三個部分，每個部分各自負責不同的功能
好處
- 職責分離，更容易維護程式
- 使程式結構更直覺，有利於團隊分工
- 可重複使用寫好的程式

MVC架構模式 in Spring Boot

MVC架構模式是抽象的概念
實際套用到Spring Boot時，會轉化為Controller-Service-Dao三層式架構

Controller-Service-Dao三層式架構

前端發出Request => Controller接收並且驗證請求參數是否正確

Controller接收並且驗證請求參數是否正確 =Call=> Service負責業務邏輯

Service負責業務邏輯 =Call=> Dao(Data Access Object)負責和資料庫溝通(與資料庫存取數據)

實作Controller-Service-Dao 三層式架構

// Controller
@GetMapping("/students/{studentId}")
public Student select(@PathVariable Integer studentId) {
    return studentService.getById(studentId);
}

// Service
@Component
public class StudentServiceImpl implements StudentService{

    @Autowired
    private StudentDao studentDao;

    @Override
    public Student getById(Integer studentId) {
        return studentDao.getById(studentId);
    }
}

// Dao
@Component
public class StudentDaoImpl implements StudentDao{

    @Autowired
    private NamedParameterJdbcTemplate namedParameterJdbcTemplate;

    @Override
    public Student getById(Integer studentId) {
        String sql = "SELECT id, name FROM student WHERE id = :studentId";

        Map<String, Object> map = new HashMap<>();
        map.put("studentId", studentId);

        List<Student> list = namedParameterJdbcTemplate.query(sql, map, new StudentRowMapper());

        if (list.size() > 0) {
            return list.get(0);
        } else {
            return null;
        }
    }
}

交易 Transaction

交易(Transaction) 是資料庫的一種用法
用途：可以在一個交易裡包含多個資料庫操作，這些資料庫操作，要馬一起成功，要馬一起失敗
- 也就是All or Nothing 原則
Rollback(回滾)
- 撤銷已執行的資料庫操作，確保數據恢復原狀

@Transactional

用法：加在class上或方法上(通常是加在方法上)
用途：使用交易來管理這個方法中的資料庫操作

@Component
public class MyService {
    
    @Transactional (Transaction加上al變成形容詞，形容這個方法是具有交易特性的)
    public void transfer() {
        //...
    }

}

多個資料庫的連線設定

// application.properties
# 多個資料庫的連線設定
spring.datasource.test1.driver-class-name=com.mysql.cj.jdbc.Driver
spring.datasource.test1.jdbc-url=jdbc:mysql://localhost:3306/test1?serverTimezone=Asia/Taipei&characterEncoding=utf-8
spring.datasource.test1.username=root
spring.datasource.test1.password=springboot

spring.datasource.test2.driver-class-name=com.mysql.cj.jdbc.Driver
spring.datasource.test2.jdbc-url=jdbc:mysql://localhost:3306/test2?serverTimezone=Asia/Taipei&characterEncoding=utf-8
spring.datasource.test2.username=root
spring.datasource.test2.password=springboot

# 單個資料庫的連線方式
spring.datasource.driver-class-name=com.mysql.cj.jdbc.Driver
spring.datasource.url=jdbc:mysql://localhost:3306/myjdbc?serverTimezone=Asia/Taipei&characterEncoding=utf-8
spring.datasource.username=root
spring.datasource.password=springboot

// DataSourceConfiguration
@Configuration
public class DataSourceConfiguration {

    // 連線到 test1 資料庫的 DataSource 和 NamedParameterJdbcTemplate
    @Bean
    @ConfigurationProperties(prefix = "spring.datasource.test1")
    public DataSource test1DataSource() {
        return DataSourceBuilder.create().build();
    }

    @Bean
    public NamedParameterJdbcTemplate test1JdbcTemplate(
            @Qualifier("test1DataSource") DataSource dataSource) {
        return new NamedParameterJdbcTemplate(dataSource);
    }


    // 連線到 test2 資料庫的 DataSource 和 NamedParameterJdbcTemplate
    @Bean
    @ConfigurationProperties(prefix = "spring.datasource.test2")
    public DataSource test2DataSource() {
        return DataSourceBuilder.create().build();
    }

    @Bean
    public NamedParameterJdbcTemplate test2JdbcTemplate(
            @Qualifier("test2DataSource") DataSource dataSource) {
        return new NamedParameterJdbcTemplate(dataSource);
    }
}

Spring Jdbc 總結

使用Intellij管理資料庫的數據
- console編輯區
- 圖形化介面
資料庫連線設定
- 連線資訊寫在Spring Boot的設定檔 - application.properties裡面
NamedParameterJdbcTemplate的用法
- update() - 執行INSERT、UPDATE、DELETE sql
- query() - 執行SELECT sql
MVC架構模式
- Model、View、Controller
- 軟體工程：當很多工程師一起做很大的Project時，就很需要注重軟體工程
- Controller-Service-Dao 三層式架構
  - Controller：負責接收Http Request、驗證請求參數
  - Service：負責業務邏輯
  - Dao：負責和資料庫溝通

Spring Data JPA

簡介

Spring JDBC：執行原始的SQL語法，去操作資料庫
Spring Data JPA：使用ORM的概念，透過操作Java object的方式，去操作資料庫

ORM

全名為Object-Relational Mapping
用途：將Java object，去對應到資料庫的table，所以對Java object的操作，就是對資料庫的操作

JPA

全名為Java Persistence API，定義要如何去操作資料庫
JPA提供了很多註解讓我們使用，像是@Entity、@Table、@Column...
Hibernate
- 一種ORM框架，去實現JPA
- 負責自動生成SQL語法

Spring JDBC VS Spring Data JPA

Spring JDBC
- 是以SQL為中心
- 需要自己寫SQL語法，去操作資料庫
- 開發效率較低
- 效能較好
- 可寫出較為複雜的SQL語法
- 一開始比較難上手，但上手後就不會有什麼問題
Spring Data JPA
- JPA是以Java Object為中心
- 不需要自己寫SQL語法，Hibernate會自動生成SQL語法去操作資料庫
- 開發效率較高
- 效能較差
- 很難寫出複雜的查詢
- 容易上手，但需要能妥善處理後續帶來的問題

資料庫連線設定

// pom.xml 新增設定 讓SpringBoot可以使用data-jpa的功能
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-data-jpa</artifactId>
</dependency>

// pom.xml 新增設定 添加MySQL Driver讓SpringBoot可以連線到MySQL資料庫
// Google maven mysql
<!-- https://mvnrepository.com/artifact/mysql/mysql-connector-java -->
<dependency>
    <groupId>mysql</groupId>
    <artifactId>mysql-connector-java</artifactId>
    <version>8.0.22</version>
</dependency>

// application.properties
// google database timezone
spring.datasource.driver-class-name=com.mysql.cj.jdbc.Driver
spring.datasource.url=jdbc:mysql://localhost:3306/myjdbc?serverTimezone=Asia/Taipei&characterEncoding=utf-8
spring.datasource.username=root
spring.datasource.password=springboot

設定完之後運行SpringBoot Spring JDBC會自動創建 NamedParameterJdbcTemplate這個Bean

第一個Spring Data JPA 程式

// Student Class 

@Entity
@Table(name = "student")
public class Student {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    @Column(name = "id")
    Integer id;

    @Column(name = "name")
    String name;

    public Integer getId() {
        return id;
    }

    public void setId(Integer id) {
        this.id = id;
    }

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }
}

// StudentRepository interface
public interface StudentRepository extends CrudRepository<Student, Integer> {
    // ...
}

// StudentController
@RestController
public class StudentController {

    @Autowired
    private StudentRepository studentRepository;

    @PostMapping("/students")
    public String insert(@RequestBody Student student) {

        studentRepository.save(student);

        return "執行資料庫的 Create操作";
    }
}

Spring Data JPA提供的Interface

CrudRepository：基本的CRUD操作 => 最常用
PagingAndSortingRepository：新增分頁和排序的操作 => extends CrudRepository
JpaRepository：能力最強，新增了JPA相關的flush操作 => extends PagingAndSortingRepository

CrudRepository 基本用法

@RestController
public class StudentController {

    @Autowired
    private StudentRepository studentRepository;
        
    // CREATE
    @PostMapping("/students")
    public String insert(@RequestBody Student student) {

        studentRepository.save(student);

        return "執行資料庫的 Create操作";
    }
        
    // READ
    @GetMapping("/students/{studentId}")
    public Student read(@PathVariable Integer studentId) {

        Student student = studentRepository.findById(studentId).orElse(null);

        return student;
    }
    
    // UPDATE
    @PutMapping("/students/{studentId}")
    public String update(@PathVariable Integer studentId,
                         @RequestBody Student student) {

        Student s = studentRepository.findById(studentId).orElse(null);

        if (s != null) {
            s.setName(student.getName());
            studentRepository.save(s);

            return "執行資料庫的 Update操作";
        } else {
            return "Update失敗，數據不存在";
        }

    }
    
    // DELETE
    @DeleteMapping("/students/{studentId}")
    public String delete(@PathVariable Integer studentId) {

        studentRepository.deleteById(studentId);

        return "執行資料庫的 Delete操作";
    }


}

自定義查詢條件 - findByXxx的命名規則

public interface StudentRepository extends CrudRepository<Student, Integer> {

List<Student> findByName(String name); 
=> SELECT * FROM Student WHERE name = ?(String name)
=> 返回的類型通常是返回Student或是List<Student>

Student findByIdAndName(Integer id, String name);
=> SELECT * FROM Student WHERE id = ? AND name = ?(Integer id, String name)

}

原生SQL查詢 @Query

目的：用來解決findByXxx無法寫出複雜的查詢邏輯的問題
用途：在Spring Data JPA中，執行原生的SQL語法
用法：加在方法上

public interface StudentRepository extends CrudRepository<Student, Integer> {
    
    @Query(value = "SELECT id, name FROM student WHERE id = ?1 AND name = ?2, nativeQuery = true")
    Student test1(Integer id, String name);

}

@Query vs findByXxx
- 優先使用findByXxx的命名規則
- 複雜的邏輯才使用@Query

Spring Data JPA 總結

建立ORM對應關係
- @Entity
- @Table、@Column、@Id
CrudRepository的用法
- save()：新增/修改
- findById()：查詢
- deleteById()：刪除
自定義查詢條件
- findByXxx的命名規則
- @Query執行sql語法

單元測試

目的：自動化測試程式的正確性
所謂單元測試，就是一次只測試一個功能點，一個單元(Unit)可以是一個method，或是一個API
其他軟體測試
- 整合測試(Integration Testing)
- 端對端測試(End-To-End Testing)

// pom.xml
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-test</artifactId>
    <scope>test</scope>
</dependency>

// class
public class Calculator {
    
    public int add(int x, int y) {
        return x + y;
    }
}

// test/classTest
public class CalculatorTest {

    @Test 
    public void test() {
        Calculator calculator = new Calculator();
        int result = calculator.add(1, 2);

        assertEquals(3, result);
    }
}

單元測試的特性

可以被自動化運行
各個單元測試互相獨立，彼此之間不能有依賴關係
測試的結果是穩定的，不受外部服務影響

單元測試的注意事項

測試的程式要放在test資料夾裡面
測試的class以「原class的名字加上Test做為結尾」來命名
測試的class的package，要跟原class的package保持一致

JUnit

JUnit是Java單元測試的必備工具
JUnit和SpringBoot的版本關係
- SpringBoot版本 <= 2.1
  - 僅能使用JUnit4
- SpringBoot版本 = 2.2、2.3
  - 能同時使用JUnit4和JUnit5
- SpringBoot版本 >= 2.4
  - 僅能使用JUnit5
只要在方法上加上@Test，即可生成一個單元測試
- 用法：加在方法上，可以生成一個單元測試，@Test只能在test資料夾底下使用，可以將該方法變成可執行的test case(測項)
- 細節：方法必須是public void，並且沒有任何參數

JUnit5的Assert用法

若是不符合assert斷言的預期結果，則為測試失敗

Assert	用途
assertNull(A)	斷言A為Null
assertNotNull(A)	斷言A不為Null
assertEquals(A, B)	斷言A和B相等，會使用equal()方法去判斷
assertTrue(A)	斷言A為True
assertFalse(A)	斷言A為False
assertThrows(exception, method)	斷言執行method時，會噴出exception

JUnit5的其它用法

@BeforeEach：、@AfterEach
- @BeforeEach：在每次@Test開始前，都會執行一次
- @AfterEach：在每次@Test結束後，都會執行一次
- @BeforeAll：在所有@Test開始前，執行一次 / public static void
- @AfterAll：在所有@Test結束後，執行一次 / public static void
- @Disabled：忽略該@Test不執行
- @DisplayName：自訂義顯示名稱

撰寫Service層、Dao層測試

@SpringBootTest、@Transactional
只要在測試的class上加上@SpringBootTest，則在運行單元測試時，SpringBoot就會去啟動Spring容器，創建所有的Bean出來

@SpringBootTest
public class DemoApplicationTests {
    
    @Autowired
    private StudentDao studentDao;
    
    @Test
    public void getById() {
        studentDao.getById(1);
    }
    
}

@SpringBootTest：不只是創建bean，所有的@Configuration設定也都會被執行，效果等同於直接運行起SpringBoot程式
@Transactional(for 單元測試)：單元測試運行完成之後，SpringBoot會去rollback這個單元測試裡面的所有資料庫操作
- 用法：可以加在方法上、也可以加在class上
- 用途：在單元測試結束後，rollback所有資料庫操作，將數據恢復原狀
- 在main資料夾（正常程式）
  - 交易管理
  - 程式運行中途發生錯誤的話，才rollback已經執行的資料庫操作，將數據恢復原狀
- 在test資料夾（單元測試）
  - 在該單元測試結束後，強制rollback所有執行的資料庫操作，將數據恢復原狀

撰寫Controller層測試 - MockMvc主要架構

目的：模擬前端的行為，測試API是否運行正確
不能直接注入bean來測試，需要透過模擬真實的API call來測試
MockMvc
- 用途：模擬真實的API call
- @SpringBootTest
- @AutoConfigureMockMvc

@SpringBootTest
@AutoConfigureMockMvc
public class StudentControllerTest {

    @Autowired
    private MockMvc mockMvc;

    @Test
    public void getById() throws Exception {
        RequestBuilder requestBuilder = MockMvcRequestBuilders
                .get("/students/{studentId}, 3");
        
        // Builder設計模式（建造者模式）
        mockMvc.perform(requestBuilder)
                .andExpect(MockMvcResultMatchers.status().is(200));
    }
}

撰寫Controller層測試 - MockMvc常用寫法

@SpringBootTest
@AutoConfigureMockMvc
public class StudentControllerTest {

    @Autowired
    private MockMvc mockMvc;

    @Test
    public void getById() throws Exception {
        RequestBuilder requestBuilder = MockMvcRequestBuilders
                .get("/students/{studentId}", 3)
                .header("headerName", "headerValue")
                .queryParam("graduate", "true");

        MvcResult mvcResult = mockMvc.perform(requestBuilder)
                .andDo(print())
                .andExpect(status().is(200))
                .andExpect(jsonPath("$.id", equalTo(3)))
                .andExpect(jsonPath("$.name", notNullValue()))
                .andReturn();

        String body = mvcResult.getResponse().getContentAsString();
        System.out.println("返回的 response body 為: " + body);
    }

    @Test
    public void create() throws Exception {
        RequestBuilder requestBuilder = MockMvcRequestBuilders
                .post("/students")
                .contentType(MediaType.APPLICATION_JSON)
                .content("{\n" +
                        "  \"name\": \"Hank\",\n" +
                        "  \"score\": 14.6,\n" +
                        "  \"graduate\": false\n" +
                        "}");

        mockMvc.perform(requestBuilder)
                .andExpect(status().is(201));
    }
}

Mock測試 - Mockito

目的：避免為了測試某一個單元測試，而去構建了整個bean的dependency
做法：創造一個假的Bean，去替換掉Spring容器中原有的Bean

Mockito

在SpringBoot中進行Mock測試的工具
功能：
- 模擬方法的返回值
  - when...thenReturn...
  - doReturn...when...
- 模擬拋出Exception
  - when...thenThrow...
  - doThrow...when...
- 紀錄方法的使用次數、順序
  - Mockito.verify(studentDao, Mockito.times(2)).getById(Mockito.any());
- 限制：
  - 不能mock static方法
  - 不能mock private方法
  - 不能mock final class
@MockBean：產生一個假的Bean，替換掉Spring容器中的Bean
- 沒有定義的方法，預設返回null

@SpringBootTest
public class StudentServiceImplMockTest {

    @Autowired
    private StudentService studentService;

    @MockBean
    private StudentDao studentDao;

    @Test
    public void getById() {
        Student mockStudent = new Student();
        mockStudent.setId(100);
        mockStudent.setName("I'm mock");

        Mockito.when(studentDao.getById(Mockito.any())).thenReturn(mockStudent);
        Mockito.doReturn(mockStudent).when(studentDao).getById(Mockito.any());

        Student student = studentService.getById(2);
        assertNotNull(student);
        assertEquals(100, student.getId());
        assertEquals("I'm mock", student.getName());
    }
}

SpyBean：Spring容器中的Bean仍舊是正常的bean，只替換其中幾個方法
- 沒有定義的方法，預設使用真實的方法

使用H2資料庫

H2是一種嵌入式資料庫
用途：可以在啟動SpringBoot時被生成出來，在運行結束時被銷毀，用完即丟
常用在單元測試，降低程式對實體資料庫的依賴
- 也就是說，任何一台電腦，不需要安裝任何軟體，都可以運行該單元測試
在test/resources中的application.properties需要和main/resources中的application.properties同步，不然運行測試會失敗
在test/resources中新增schema.sql、data.sql，並且添加SQL語法

// application.properties setting
spring.datasource.driver-class-name=org.h2.Driver
spring.datasource.url=jdbc:h2:mem:testdb
spring.datasource.username=sa
spring.datasource.password=sa

// 如果是使用Spring Data Jpa的方式要另外添加這行
spring.jpa.hibernate.ddl-auto=none

// schema.sql + IF NOT EXISTS 避免H2資料庫重複創建Table
CREATE TABLE IF NOT EXISTS student (
     id INT PRIMARY KEY AUTO_INCREMENT,
     name VARCHAR(30),
     score DOUBLE,
     graduate BOOLEAN,
     create_date TIMESTAMP
);

// data.sql
INSERT INTO student (name, score, graduate, create_date) VALUES ('Amy', 90.3, true, '2021-09-01 10:20:33');
INSERT INTO student (name, score, graduate, create_date) VALUES ('Rom', 34.6, false, '2021-08-10 17:21:14');
INSERT INTO student (name, score, graduate, create_date) VALUES ('Judy', 100.0, true, '2021-09-05 12:19:48');
INSERT INTO student (name, score, graduate, create_date) VALUES ('Mike', 87.2, true, '2021-09-03 15:01:15');

Spring Boot補充特性

Convention over Configuration（約定大於配置 || 慣例優於設定）
- 不需添加任何設定，只要知道運作規則，就能直接使用
- 所有project遵循一致的標準化設定
Spring Boot出現的意義就是為了簡化Spring開發

我們真的需要單元測試嗎

單元測試的數量不是越多越好
- 單元測試也是程式，程式越多，就表示維護成本越高
- 單元測試的重要程度＝影響使用者的程度，使用頻率越高的功能越需要單元測試
要加多少單元測試
- 比如在金融業或是博弈業：能測多細就多細，有關金錢是很重要的
- 在一般軟體業：
  - 使用MockMvc測試各API是否運作正常
  - 重要的Service層可以加一些專屬的單元測試
  - Dao層比較少測，但如果有複雜的sql語法，可以額外添加測試

如何寫出好的單元測試

在寫單元測試時，要從使用者的角度去思考
- 不要在實作完直接寫單元測試，可以沈澱一下再回頭寫，以免鑽牛角尖
一定要記得測試Error Case
- 在測試getById方法時，可以測試當id不存在時怎麼處理？當id的長度超過限制怎麼處理？
- 實作Error Handling是開發中最難的一部分
善用Run Test With Coverage，查看單元測試覆蓋的範圍
- 不要為了單純提升測試覆蓋率而寫單元測試，而是要思考是否有哪些使用場景沒考慮到
- 不要被數字迷惑，並不是一定要100%覆蓋率才是完美，要確保的是重要的功能有被測試到
如果測試中使用的@SpyBean過多，表示功能切分的不夠好
- 盡量從功能面去區分Service，譬如說ProductService、OrderService、UserService
- 和外部服務有關的API call，獨立成一個Service
  - 譬如說和Youtube有關的API call，就統一放在YoutubeService裏
- 靠經驗多累積

學單元測試的四個心裡階段

新手期：寫測試太花時間了，感覺沒什麼用，不如多解另外一個bug
被逼著寫期：公司開始要求測試覆蓋率，只能開始試著寫
領悟期：測試越寫越熟練，也測出越來越多bug，開始覺得寫測試真的有用
開導他人期：督促新進工程師寫測試，邁入正向循環

測試驅動開發 Test-Driven Development

全稱 Test-Driven Development，常稱TDD
貫徹「先寫測試、再寫開發」的精神
大致上分五個步驟
- 選擇一個功能，先寫單元測試
- 單元測試失敗（紅燈）
- 實作功能程式
- 單元測試成功（綠燈）
- 持續重構程式

單元測試總結

單元測試的特性和注意事項
- 可以被自動化運行
- 單元測試彼此獨立
- 測試結果穩定，不受外部服務影響
Junit5用法
- @Test
- assert斷言方法
- @BeforeEach、@AfterEach、@BeforeAll、@AfterAll
- @Disabled、@DisplayName
如何測試Spring Boot程式
- Service、Dao層的測試
  - @SpringBootTest
  - @Transaction
- Controller層的測試
  - MockMvc
  - 主架構：RequestBuilder、mockMvc.perform()、andExpect()
隔絕外部服務的依賴
- Mock測試 - Mockito
  - @MockBean、@SpyBean
  - 模擬方法的返回值：when...thenReturn、doReturn...when
  - 模擬噴出Exception：when...thenThrow、doThrow...when
- 使用H2資料庫
  - schema.sql：放創建table的sql
  - data.sql：放插入數據的sql
前輩經驗談
- 單元測試的數量不是越多越好
- 記得要測試Error Case
- 善用Intellij的Run Test With Coverage功能
測試驅動開發
- Test-Driven Development（TDD）
- 先寫測試、再寫開發

Spring 常用功能

Maven

Maven是在SpringBoot開發中，負責Library管理和Project構建的工具

Maven - Library管理

用途：管理這個SpringBoot project可以使用哪些功能
用法：透過pom.xml檔案進行管理

Maven - Project構建

用途：對SpringBoot project進行編譯、測試、運行、清理、打包
用法：透過maven指令操作

Maven Repository（Maven倉庫）

用途：儲存SpringBoot project依賴的Library（jar檔）
可以分為Local Repository（本地倉庫）和Remote Repository（遠端倉庫）

Maven指令

Clean：刪除src底下的target資料夾
Compile > Test > Package > Install > Deploy

針對不同環境做不同的設定

application-dev.properties
application-test.properties

Intellij右上角設定 > Active profiles:dev / test

Log的級別與規範

private final static Logger log = LoggerFactory.getLogger(StudentController.class);

log.info("取得 student {}", studentId);
log.warn();
log.error();

Json字串和Java Object互相作轉換

ObjectMapper

用途：將Json字串和Java Object互相作轉換
使用條件：只要確保pom.xml中有加上spring-boot-starter-web即可
用法：
- writeValueAsString()：Java Object -> Json字串
- readValue()：Json字串 -> Java Object

// 過濾掉null的key
@JsonInclude(JsonInclude.Include.NON_NULL)

// 在Json字串轉換成User的過程中，發現有一些key不存在的話，就忽略
@JsonIgnoreProperties(ignoreUnknown = true)
public class User {

    Integer id;
    String name;

    // 將現有變數對應到名字如有不同的key上
    @JsonProperty("contact_email")
    String contactEmail;

    public String getContactEmail() {
        return contactEmail;
    }

    public void setContactEmail(String contactEmail) {
        this.contactEmail = contactEmail;
    }

    public Integer getId() {
        return id;
    }

    public void setId(Integer id) {
        this.id = id;
    }

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }
}

在SpringBoot中發起Http請求 - RestTemplate

RestTemplate
- 用途：在SpringBoot中，發起一個REST風格Http請求
  - 即是可以發起GET、POST、PUT、DELETE的Http請求
  - 並且可以將收到的reponse body中的Json字串，轉換成Java object
- 使用條件：只要確保pom.xml中有加上spring-boot-starter-web即可

@RestController
public class RestTemplateController {

    @GetMapping("/getForObject")
    public String getForObject() {

        RestTemplate restTemplate = new RestTemplate();

        Student student = restTemplate.getForObject(
                "https://mocki.io/v1/7eda2b1b-d2a8-408e-a228-0cfe6bd6bec6",
                Student.class);

        System.out.println("Student 的 id 值為: " + student.getId());
        System.out.println("Student 的 name 值為: " + student.getName());
        System.out.println("Student 的 phone 值為: " + student.getContactPhone());


        return "getForObject success";
    }


    @GetMapping("/getForObjectWithParam")
    public String getForObjectWithParam() {
        RestTemplate restTemplate = new RestTemplate();

        Map<String, Object> queryParamMap = new HashMap<>();
        queryParamMap.put("graduate", true);

        Student student = restTemplate.getForObject(
                "https://mocki.io/v1/77f69435-224e-4c90-b7cd-53f07bbf5604",
                Student.class,
                queryParamMap
        );

        return "getForObject with param success";
    }


    @GetMapping("/getForEntity")
    public String getForEntity() {
        RestTemplate restTemplate = new RestTemplate();

        ResponseEntity<Student> studentEntity = restTemplate.getForEntity(
                "https://mocki.io/v1/b7a68eb2-f77c-43cf-bffe-8c647e9a2514",
                Student.class
        );

        System.out.println("http 狀態碼為: " + studentEntity.getStatusCode());

        Student student = studentEntity.getBody();

        System.out.println("student 的 id 值為: " + student.getId());
        System.out.println("student 的 name 值為: " + student.getName());
        System.out.println("student 的 phone 值為: " + student.getContactPhone());

        return "getForEntity success";
    }


    @GetMapping("/postForObject")
    public String postForObject() {
        RestTemplate restTemplate = new RestTemplate();

        Student studentRequestBody = new Student();
        studentRequestBody.setName("John");

        Student result = restTemplate.postForObject(
                "https://mocki.io/v1/b7a68eb2-f77c-43cf-bffe-8c647e9a2514",
                studentRequestBody,
                Student.class
        );

        return "postForObject success";
    }

    @GetMapping("/postForEntity")
    public String postForEntity() {
        RestTemplate restTemplate = new RestTemplate();

        Student studentRequestBody = new Student();
        studentRequestBody.setName("John");

        ResponseEntity<Student> responseEntity = restTemplate.postForEntity(
                "https://mocki.io/v1/b7a68eb2-f77c-43cf-bffe-8c647e9a2514",
                studentRequestBody,
                Student.class
        );

        return "postForEntity success";
    }


    @GetMapping("/exchange")
    public String exchange() {

        RestTemplate restTemplate = new RestTemplate();

        // 使用 exchange 發起 GET 請求
        HttpHeaders requestHeaders = new HttpHeaders();
        requestHeaders.set("header1", "123");

        HttpEntity requestEntity = new HttpEntity(requestHeaders);

        Map<String, Object> queryParamMap = new HashMap<>();
        queryParamMap.put("graduate", true);

        ResponseEntity<Student> getStudentEntity = restTemplate.exchange(
                "https://mocki.io/v1/b7a68eb2-f77c-43cf-bffe-8c647e9a2514",
                HttpMethod.GET,
                requestEntity,
                Student.class,
                queryParamMap
        );



        // 使用 exchange 發起 POST 請求
        HttpHeaders requestHeaders2 = new HttpHeaders();
        requestHeaders2.set("header2", "456");
        requestHeaders2.setContentType(MediaType.APPLICATION_JSON);

        Student studentRequestBody = new Student();
        studentRequestBody.setName("John");

        HttpEntity requestEntity2 = new HttpEntity(studentRequestBody, requestHeaders2);

        ResponseEntity<Student> postStudentEntity = restTemplate.exchange(
                "https://mocki.io/v1/b7a68eb2-f77c-43cf-bffe-8c647e9a2514",
                HttpMethod.POST,
                requestEntity2,
                Student.class
        );

        return "exchange success";
    }
}

前端模板引擎 - Thymeleaf

用途：SpringBoot中的前端模板引擎，支援Html頁面的開發和渲染
使用條件：在pom.xml中加上spring-boot-starter-thymeleaf
其他常見SpringBoot前端模板引擎
- JSP
- Freemarker

Intellij的Debug用法

Debug模式

用途：
- 可以新增斷點，一行一行的執行程式
- 可以馬上知道運行中的變數的值

Intellij的實用技巧

第一類：一定要背的
第二類：學了可以有效去提高開發效率的
- 刪除多餘的import：Ctrl + Option + O
- 如何快速美化程式排版：Command + Option + L
- 查詢某個class或是檔案在哪裡：Shift連續按兩下
第三類：有趣的，不學也不會怎樣的

Lombok

用途：透過添加註解去自動生成對應的程式，讓程式碼變得更簡潔
使用條件：
- 在pom.xml中加上lombok
- 在Intellij中安裝lombok插件

import lombok.Getter;
import lombok.Setter;

@Getter
@Setter
public class Student {

    Integer id;
    String name;
}


@Data -> 包含許多方法
public class Student {

    Integer id;
    String name;
}

@RestController
public class StudentController {

    @GetMapping("/test")
    public Student test() {
        Student student = new Student();
        student.setId(1);
        student.setName("Hubert");

        return student;
    }
}

自我思考 - 為什麼老是覺得自己不夠好？

Tue, 16 May 2023 00:00:00 GMT

我覺得我辦不到？

過往失敗的經驗累積，影響了現在的自信

過去在人生中遇到一些任務時，比如工作上的任務難度較高，沒完成的很好或是出了差錯，再比如轉換職務找工作面試，遇到筆試卻寫不出來交白卷，想約心儀的妹子吃飯結果被拒絕，很容易就會覺得自己怎麼這麼糟糕、這麼失敗。爾後再遇到類似的挑戰時，就會退縮、害怕、自我懷疑。

逃避雖可恥但有用，但會後悔

遇到壓力時，想放棄跟想逃走都是很正常的，大部分人其實都是這樣，你並不孤單，只是在這種時候一定要想想，當初為什麼會選擇這條路，也許是很喜歡這件事，也許是這工作的收入可以提升你的生活品質，可怕的下場跟後果大多都是自己想像出來的，雖然失敗或是被拒絕的確心裡會很難受，但要告訴自己，不管最後是甚麼結果，只要有結果就是好事，勇敢走下去就對了。

如何阻止自己逃避

去大吃大喝或者好好出去旅遊一趟，這世界很大你的工作只是滄海一粟。
客觀去分析你自身遇到的問題，比如硬實力不足就多花一點時間學習，而不是總是在追劇。
對自己要有信心，不要害怕失敗。

培養自信，建立自己的知識映射

知識映射這名字是我亂取的

明明工作上能夠應用，但每次面試考題都不知道怎麼描述，這代表你知道這件事情怎麼處理，但沒辦法靠反射動作就處理好，就像打籃球三步上籃，不熟練的人老是同手同腳，常常不小心多走一步就變成走步，不然就是力道過猛或不足而沒投進，畢竟人家傳球給你，要你上籃的目的就是投進並且得分，結果你沒做到，旁邊的人想當然就認為你，就是"不會上籃"。

那回到工程師的職場上，很多時候我們的確會應用一些技術，不論是查看文件或是Google都有相當多的範例可以參考，如果遇到一時半會查不到的問題，現在還有ChatGPT的幫助，一下子就能解決，但深層的原理如果沒搞懂的話，下次有人問起，要描述或是解說的話多半又講不出來。畢竟會用跟真的懂可能是用來判斷你到底屬不屬於資深工程師的依據。(來自筆者面試常常交白卷的反省)

拆解問題或任務的三大步驟

遇到超出自己能力範圍的任務或問題時，先不要太慌張

工作上其實很常遇到突然要使用沒用過的新技術，或者換新工作時通常每間公司的開發方式跟慣用技術都不同，遇到超出自己能力範圍的任務或問題，先不要慌張就急著到處問人，先試著把問題或任務拆解成小步驟，然後照著先能動再優化的想法去執行，不要一口氣就要做到最美好的情況，內心壓力也會小一點，也能在逐步完成的過程中，獲得成就感。

Make it work.
Make it right.
Make it fast.

前端知識 - Cookie、SessionStorage、LocalStorage。

Mon, 15 May 2023 00:00:00 GMT

瀏覽器提供本地端儲存資料的方式有三種

Cookie
LocalStorage
SessionStorage

Cookie

可設定失效時間，沒設定的話預設是瀏覽器關閉後失效。

第一次用戶端瀏覽器在發送請求後，伺服器端會在回應的標頭中，添加一個 Set-Cookie 的選項並將 cookie 放入到回應中，送回用戶瀏覽器端後，會儲存在用戶端本地。此外 cookie 會在用戶瀏覽器下一次發送請求時，一同被攜帶並發送回伺服器上。

大小約 4kb
每次請求時都會在 header 帶上

Domain - 指定網域可以使用，預設是當前網域但不包含子網域。

Path - 作用範圍，指定路徑可以使用這個 cookie，預設是都可存取。

Expires - 有效期限，該 cookie 過期的時間，值為Date.toUTCString() 格式的時間字串。

Max-Age - 有效期限，該 cookie 可以留存的時間，單位為秒。如果同時設定 Max-Age 以及 Expires，則 Max-Age 優先。

Secure - 安全性，是否只能在 https 下傳遞，格式為 boolean 值。

HttpOnly - 安全性，此 cookie 只能從 web server 訪問，以避免不正確的進入來取得竄改。

LocalStorage以及SessionStorage

SessionStorage : 關閉頁面或是關閉瀏覽器後失效。
LocalStorage : 基本上永久保存，除非手動去清除。

LocalStorage以及SessionStorage是HTML5提供兩種在客戶端儲存資料的方法，彌補了cookie儲存量小、不適用於大量資料本地儲存的問題。

大小約 5mb (依各瀏覽器會有些許不同)
都藉由key-value的方式去儲存資料
僅能儲存字串的資料型態，可以將陣列或物件透過 JSON.stringify 轉JSON字串儲存， JSON.parse 將JSON字串轉回原本物件取出。

// localStorage 存入數據
localStorage.setItem('keyName', value);

// localStorage 讀取數據
localStorage.getItem('keyName');

// sessionStorage 存入數據
sessionStorage.setItem('keyName', value);

// sessionStorage 讀取數據
sessionStorage.getItem('keyName');

// 刪除指定數據
localStorage.removeItem('keyName');
sessionStorage.removeItem('keyName');

// 刪除全部數據
localStorage.clear();
sessionStorage.clear();

常見應用

工程師在開發網站時，在瀏覽器儲存資料的應用滿廣泛的，最常見的當然就是會員登入狀態，購物車資料暫存或者分步驟表單驗證等等。

Cookie 比較常用的場景就是判斷用戶是否登錄，針對登錄過的用戶，服務器端會在他登錄時，往 Cookie 插入一段加密過的辨識碼，下次只要讀取這個值就可以判斷用戶是否登錄。

SessionStorage 如果遇到一些內容特別多的表單，為了提升用戶體驗，可能要把表單頁面拆分成多個子頁面，然後按照步驟引導用戶。SessionStorage 這時候就可以發揮出效用。

LocalStorage 除了可以用來代替 Cookie 做購物車的資料保存，也能做會員登入狀態的持久化。或者在電商網站、遊戲通常會產生一些使用者數據，這時就很適合用 LocalStorage 來保存這些數據。

Hubert Hsieh

後端知識 - 我以為 JS 會先印 B。

同一個實驗，寫兩次

「JS 一定是 A B C」

一個永遠等不完的 Promise

多包一層 Task.Run

還控制權，不是換人

順帶收掉的兩筆債

關掉 ImplicitUsings

.slnx 和 .csproj 的分工

同一個觀念，換一個語言再跑一次

後端知識 - Equals 說相等，== 說不相等。

先分清楚兩種相等

比內容，到底比多深

Equals 根本沒被叫到

override Equals，== 不會跟著來

常見應用：什麼時候會真的踩到

後端知識 - MapGet 不是在執行，是在登記。

第一個端點長這樣

註冊，不是執行

編譯期、啟動期、請求期

跳進原始碼，然後迷路

放錯位置的 record

親手做出一個 race condition

Day 1 結束時，我真的會的是什麼

自我思考 - 我叫 AI 不准幫我寫程式。

為什麼要綁住一個很會寫程式的工具

我給 AI 的規則，比給自己的還多

第一天就被抓到用補全

同一個錯，我犯了三次

最毒的 bug，是數字剛好對

預計四週，停在第二天

如果你也想這樣學

後端知識 - ANR 的真兇：一張沒設計索引的資料表。

我是在做開單系統的時候發現的

沒有索引，資料庫在做的事

這件事回頭看，其實是設計階段就該問的問題

前端知識 - React的生命週期：三年後，那篇文章有一半該重寫。

先承認那篇的問題

useEffect 不是「三個生命週期合體」

清理函式不是只在銷毀時跑

清理函式看到的是舊的值

deps=[] 那個從頭到尾沒動

沒有 shouldComponentUpdate 的等價物

StrictMode 下 effect 會跑兩次

那篇文章我不打算刪掉

自我思考 - 停更三年，回來才發現網站也壞了兩年。

最後一篇文章的日期，剛好在換工作前一週

然後我遇到了 ANR

從 ANR 追到 SQLite

三年前那篇文章，我自己變成了裡面的人

網站是怎麼安靜爛掉的

這次補的是機制，不是決心

所以呢

面試日記 - 一場自己講的七零八落的線上面試，真的也是種經驗。

今天去面試的大略狀況

面試結果

筆試題目複習

請描述一下 Box-Model 是什麼

請描述一下，CSS排版時，要如何做垂直置中

請描述一下 https 跟 http 的差異是什麼

請描述一下一個網頁如果 console 噴錯了，你大致上排除錯誤的流程會是如何？

過往有沒有遇過什麼狀況是自己排除不了，問了同事之後，甚至也問到主管之後，還是沒辦法解決的話，要怎麼處理？

有沒有遇過 CORS 的問題？怎麼處理的？

有客製化過什麼hook嗎？

面試反省

面試日記 - 當你被貓吵整晚不能睡，還要出發去面試跟筆試時。

正式面試前

今天去面試的大略狀況

筆試題目複習

CSS的原理及排版方式

margin 邊界重疊的三種解法

Function.call() / Function.apply() 的差異

Promise 語法

陣列的方法 - sort、reduce

型別的運算比較，比如經典的 1<2<3 以及 3>2>1

面試反省

面試日記 - 和接案公司面對面，案子如繁星點點。

今天去面試的大略狀況

面試結果

`useEffect` 不是「三個生命週期合體」

`deps=[]` 那個從頭到尾沒動

沒有 `shouldComponentUpdate` 的等價物

Bean的生命週期讀取Spring Boot設定檔 - application.properties + @Value