終於來到 Day 30！
這 30 天寫的，其實不是一套完整的 C# 教學。
比較像是把我進公司三個月後，真的卡過、查過、問過、驗證過的東西，一點一點整理成一張地圖。
一開始打開企業專案，我看到的是：
.sln
Controllers
Models
Views
Services
wwwroot
一堆 .cs
一堆 .cshtml
後來又接著遇到：
Git
Branch
Commit
Push
Azure DevOps
Work Item
Pull Request
Pipeline
每一個都很陌生。
所以這個系列從一開始就不是：
30 天精通 C#
寫到 Day 30，我也不覺得自己已經「學完 C# MVC」。
但這三個月有一件事真的變得比較不一樣：
我開始建立一套
處理陌生企業專案的方法。
這篇就不再介紹新的工具。
最後把前面 29 天真正串起來。
假設今天收到：
Task：
詳細資料頁新增部門名稱
我現在不會第一個就開始改程式。
而是先把問題拆開。
這是哪一張 Work Item？
我要在哪個 Branch 做？
這個畫面怎麼進去？
網址是什麼？
是哪個 Controller？
是哪個 Action？
最後是哪支 View？
View 用哪個 ViewModel？
資料在哪一層組出來？
要怎麼驗證？
最後要怎麼交出去？
原本看起來是一個很大的需求。
拆開後就變成：
很多個可以一個一個確認的小問題
而這大概就是我這三個月最常做的事情：
把一個看不懂的大問題
拆成可以處理的小問題
開始開發前，我會先確認：
Task
Repository
Branch
也就是：
我到底在處理哪一張工作單？
現在在哪個 Repository？
目前 Checkout 的 Branch 對不對？
因為後來才發現：
程式改對了
但改在錯的 Branch
一樣會造成麻煩。
這些事情看起來不像「寫 Code」。
但真的進到團隊開發後，才會發現它本來就是開發的一部分。
假設需求是在：
詳細資料頁
我會先真的把功能操作一次。
先看：
這個頁面怎麼進去？
網址長什麼樣子？
現在畫面有哪些資料？
問題發生在哪個操作？
例如網址是：
/User/Detail/10
就可以先往：
UserController
↓
Detail()
找。
接著看到：
public IActionResult Detail(int id)
{
...
}
如果最後是：
return View(model);
再往：
Views
↓
User
↓
Detail.cshtml
找。
這樣就可以先把：
URL
↓
Route
↓
Controller
↓
Action
↓
View
串起來。
企業專案很大，不可能一打開就全部看懂。
但只要先找到入口，就有地方可以開始往下走。
企業專案裡很常看到：
var model = _userService.GetDetail(id);
Controller 自己沒有太多邏輯。
真正的處理可能在：
Service
Repository
DBService
Database
這時我會用：
F12
繼續往下追。
可能變成：
Controller
↓
Service
↓
Repository / DBService
↓
Database
所以現在看陌生程式時，我不會要求自己一開始就理解每一行。
會先搞清楚：
誰呼叫誰？
資料從哪裡進來？
最後送去哪裡？
只要先把呼叫關係和資料流抓出來，整個專案就會比較有輪廓。
這三個月另外一個很重要的改變，是開始真的使用 Debug 工具。
因為：
程式寫在這裡
不代表這次真的有跑到這裡
所以如果不確定：
Action 有沒有進來？
Service 有沒有被呼叫？
資料現在到底是什麼？
就可以直接下：
Breakpoint
再搭配：
Locals
Watch
Call Stack
我現在排錯時，很常用一個很簡單的想法：
最後一個正常的位置在哪？
第一個開始不正常的位置在哪？
例如：
Repository
DepartmentName 有值
↓
Service
DepartmentName 沒有值
那問題範圍就可以縮小。
這時就不需要：
View
SQL
Controller
全部一起亂改
而是先集中看中間那一段。
這比一直猜問題在哪裡有效很多。
以前很容易把所有問題都統稱成：
壞了
但後來發現，不同問題看的地方其實不一樣。
如果：
Build 不過
就先看：
Error List
Output
如果程式跑起來之後才出錯：
Exception
Stack Trace
如果完全沒有錯誤訊息，但結果不對：
Breakpoint
Locals
Watch
所以排錯的第一步，反而不是立刻修。
而是先問：
這是 Build Error？
Runtime Exception？
還是 Logic Error？
先分類，才知道下一步要去哪裡找。
功能完成後，還要確認自己到底改了什麼。
所以我會再看：
Git Changes
Diff
確認：
改了哪些檔案？
有沒有不相關的修改？
有沒有測試資料？
有沒有 Debug 用的程式沒清掉？
有沒有不小心動到設定檔？
有沒有漏掉新增檔案？
我後來滿認同一件事：
不要太相信自己記得改了什麼 XD
Diff 比記憶可靠。
這也是我慢慢開始理解：
會改程式
和
能把修改安全地交進團隊
其實不是同一件事。
前面幾天分開學的：
Branch
Commit
Push
Pull Request
Review
Pipeline
Merge
現在可以串成：
建立工作 Branch
↓
修改
↓
確認 Diff
↓
Commit
↓
Push
↓
Pull Request
↓
Review
↓
Pipeline
↓
Merge
其中：
Commit
是在本機留下版本。
Push
才是把 Commit 送到 Remote。
Pull Request
則是把修改正式交給團隊 Review，準備整合進目標 Branch。
所以 Pull Request 不只是：
最後按一個按鈕
而是在告訴團隊：
這次改了什麼
對應哪張工作單
從哪個 Branch 合到哪裡
有哪些內容需要 Review
這整段流程也讓我開始理解：
團隊開發不只是
「我的電腦可以跑」
還包含：
修改可追蹤
內容可 Review
問題可以回查
版本可以安全整合
這個系列名稱裡有 AI，所以寫到最後還是想把它收回來。
Day 1 的時候，我寫過：
AI 幫我跨過「完全看不懂」的第一道牆。
但最後答案能不能真的用，
還是要靠自己回到專案裡驗證。
寫到 Day 30，我覺得這句話還是完全成立。
剛開始遇到陌生名詞時，我真的什麼都問：
這是什麼？
這個要幹嘛？
為什麼放這裡？
可以再講白話一點嗎？
AI 對我來說很像：
可以無限追問的程式翻譯機
先把：
Controller
Service
Repository
Dependency Injection
ViewModel
Route
Razor
這些陌生名詞翻成我聽得懂的話。
這一步很有用。
因為剛開始最大的問題，很多時候甚至不是：
不知道答案
而是：
連自己到底不懂什麼
都還說不清楚
AI 可以先幫我把問題拆開。
Day 1 的我其實已經知道：
AI 不一定是對的
但真正困難的是：
那我要怎麼知道它對不對？
寫到 Day 30，我至少多了一些實際工具。
如果 AI 說：
這個方法應該會被呼叫
我可以：
下 Breakpoint
如果它說：
這個類別應該從某個 Service 來
我可以：
F12
真的追進去。
如果它說：
ViewModel 應該有資料
我可以看：
Locals
Watch
如果它說：
這個問題可能是 Build 失敗
我可以回去看：
Error List
Output
如果 AI 建議我修改程式，最後還可以看：
Git Diff
確認自己到底改了什麼。
所以 Day 1 那條流程：
先問 AI
↓
用自己的話重新理解
↓
回到專案實際操作
↓
用執行結果確認
↓
發現不對再修正
到 Day 30 其實還是沒有變。
只是現在：
「回到專案驗證」
這件事開始有具體的方法了。
如果要整理 AI 在整個開發流程裡的位置，我會放成：
AI
↓
協助理解概念
協助拆問題
提供可能方向
↓
實際專案
↓
提供真正的上下文
↓
Debug / Build / Git
↓
提供驗證證據
↓
開發者
↓
做最後判斷
所以 AI 對我最有幫助的，不是：
直接幫我完成整個工作
而是：
在我完全看不懂的時候
幫我跨過第一道牆
在我查到一半的時候
幫我縮小問題範圍
但最後：
公司實際架構
真正執行流程
資料到底長什麼樣子
團隊規範
版本流程
還是要回到專案本身確認。
而企業專案裡的：
帳號
密碼
Token
Connection String
使用者資料
內部系統資訊
敏感程式碼
也不能因為 AI 很方便，就全部直接貼出去。
如果只看技術名詞，這系列有：
Visual Studio
MVC
Razor
Layout
View
Controller
Service
Breakpoint
Git
Azure DevOps
但如果再往上一層看，我覺得真正練到的是這幾件事。
閱讀既有專案
理解基本資料流
拆解問題
追呼叫關係
使用 Debug 驗證假設
根據錯誤訊息縮小範圍
確認修改影響
使用 Git 管理版本
跟著團隊流程交付程式
這些能力不一定只能用在 C# MVC。
未來如果換成：
React
API
WinForms
其他 .NET 專案
其他公司的架構
工具可能會變。
但很多思考方式還是可以留下來。
例如：
遇到陌生系統
↓
先找入口
不知道呼叫關係
↓
往下追
不確定有沒有執行
↓
驗證
資料不對
↓
找最後一個正常位置
發生錯誤
↓
先分類再找原因
修改完成
↓
確認影響和 Diff
準備交付
↓
照版本與 Review 流程走
這些我覺得比單純記住：
某個按鈕在哪裡
更值得帶走。
現在大概會是：
收到 Task
↓
確認需求
↓
確認 Repository / Branch
↓
操作畫面找入口
↓
URL / Route
↓
Controller / Action
↓
View / ViewModel
↓
F12 追 Service / Repository
↓
Breakpoint 驗證執行流程
↓
Locals / Watch 看資料
↓
找出問題範圍
↓
修改
↓
Build / Test
↓
Error List / Output / Exception
↓
Git Changes / Diff
↓
Commit
↓
Push
↓
Pull Request
↓
Review / Pipeline
↓
Merge
三個月前如果直接看到這張圖，我大概只會覺得：
這也太多了吧？
但現在至少知道：
每一步為什麼存在
遇到什麼問題時
可以回去哪一步確認
這張流程圖，大概就是這 30 天真正整理出來的成果。
進公司以前，我對工程師工作的想像比較接近：
把功能寫出來
真的進到企業專案後，才慢慢發現還包含：
理解需求
閱讀別人寫的程式
理解既有架構
追資料流
找問題
驗證自己的判斷
評估修改影響
管理版本
接受 Review
跟團隊一起把程式整合進去
所以我現在會覺得：
工程能力
不只是「會不會寫出答案」
還包含：
怎麼理解
怎麼驗證
怎麼維護
怎麼交付
怎麼協作
這可能是這三個月對我來說，最重要的一個認知改變。
這 30 天當然沒有把所有東西學完。
後面還有很多：
C#
LINQ
Entity Framework
SQL
Authentication
Authorization
API
Dependency Injection
Logging
Testing
CI/CD
部署
架構設計
舊系統維護
每一個都可以再挖很深。
但現在我比較不會覺得：
一定要先全部學完
才能開始。
因為這三個月已經讓我知道：
很多東西其實是
真的遇到之後
再一個一個往下拆。
所以如果未來再碰到一個完全不同的專案，我希望自己還能保留這套方法：
先找入口
搞清楚流程
確認呼叫關係
用工具驗證
縮小問題範圍
再修改
最後確認影響
這才是我覺得真正可以帶去下一個技術、下一個專案，甚至下一份工作的東西。
我不會只說：
我學過 C# MVC。
我會更想說：
我實際參與過 C# MVC 企業專案的開發與維護。
能從既有畫面、URL、Controller、View、Service
往下追查功能與資料流，
會使用 Visual Studio 的 F12、Breakpoint、
Locals、Watch、Call Stack、Error List、Output
協助除錯與驗證，
也實際走過 Git Branch、Commit、Push、
Azure DevOps Work Item、Pull Request、
Review 與版本整合流程。
遇到陌生技術時，我會使用 AI 協助理解與拆解問題，
但會回到實際程式、執行結果與團隊規範中驗證。
這些東西可能都不是什麼：
超高深技術
但它們是我真的在企業專案裡走過的流程。
對我來說，也比單純寫：
熟悉 C#
更接近目前真正具備的能力。
Day 1 的時候，我寫：
希望這些踩坑紀錄
可以讓跟我一樣的人少一點：
蛤？
寫到最後，我發現：
「蛤？」
其實不會消失。
未來還是一定會一直遇到新的：
蛤？
但這三個月讓我開始知道：
看不懂
↓
先拆小
不知道名詞
↓
問 AI
不知道程式在哪
↓
F12
不知道有沒有執行
↓
Breakpoint
不知道資料哪裡不對
↓
一層一層找
不知道錯在哪
↓
先分類，再看 Error / Output / Exception
不知道自己改了什麼
↓
看 Diff
不知道怎麼交出去
↓
照團隊 Git / PR 流程走
所以如果真的只能替這 30 天留下一句話，我還是會選：
看不懂沒關係，
先找到自己現在在哪一層。
AI 幫我跨過第一道：
完全看不懂
的牆。
而這三個月真正讓我累積起來的，是：
怎麼找到答案
怎麼驗證答案
怎麼確認自己的修改
怎麼把修改交進團隊
我沒有在這 30 天裡突然變成一個什麼都會的工程師。
但至少現在再面對一個陌生專案，我不會只停在：
蛤？
而是開始知道：
第一步，可以先從哪裡看。
如果未來再遇到下一個完全陌生的技術，我希望自己還能記得這件事：
不用一開始就全部看懂。
先找到入口。
再一步一步把它走通。
我想這大概就是這 30 天，對我來說最實際的收穫。
也是接下來繼續走工程師這條路時，我想帶著走的方法。
Day 30，完～
iThome鐵人賽
看影片追技術