前言

一個優秀的 CI/CD 流程不應該只靠伺服器來把關，它的起點其實在工程師每天用的 IDE 裡面。在程式碼送出去之前，先在本地端建立好防護網（Local Guardrails），就能直接攔截掉 80% 的基本錯誤。這不但能減輕 CI 伺服器的負擔，還能讓工程師更快得到錯誤回饋。

今天我們要來聊聊，在 VS Code 或 Cursor 這類主流的開發環境中，該怎麼透過標準化的工具，打造出高品質又安全的開發基礎。

核心價值：Fast Feedback

與其等到程式碼推上去、等了幾分鐘才被 CI 伺服器通知報錯，不如在打字的當下就發現問題。這種「即時回饋」能確保每一行進到 GitHub 或 GitLab 的程式碼，都符合團隊的語法與安全標準，真正做到一次就把事情做好。

必備的 IDE 工具與自動化效益

1. 程式碼來龍去脈追蹤：GitLens / Git History

   • 透過即時的行內註解（Code Lens），工程師隨時能看出每一行程式碼是谁寫的、跟哪一張 Issue 有關、以及修改的歷史紀錄。

   • 在送出 Code Review 之前，自己先檢查一下這次修改有沒有偏離原本的需求，確保送出去的內容乾乾淨淨。

2. 安全漏洞提前抓：SonarLint

   • 這是 SonarQube 的本地版，會在寫程式的同時，默默幫你掃描潛在的安全漏洞、安全性熱點和壞習慣程式碼（Code Smells）。

   • 把品質檢測提前到 IDE 階段，確保程式碼在碰到 CI 流程前，已經有一定的健康度。

3. 容器與基礎設施檢查：Docker & Kubernetes 擴展

   • 針對 Dockerfile 跟 K8s 相關設定檔做即時的語法檢查，並提醒最佳實踐（像是不要用 Root 帳號跑程式、鎖定映像檔版本等）。

   • 避免因為設定檔寫錯導致部署失敗，讓基礎設施更穩定。

4. 風格統一小幫手：ESLint / Prettier / EditorConfig

   • 設定好嚴格的排版與語法規則，解決團隊裡大家寫code習慣不一樣的問題。

   • 利用存檔自動排版功能，確保進倉庫的程式碼風格完全一致，讓大家在做 Code Review 時可以專心看邏輯，不用浪費時間吵逗號或空格。

5. CI 腳本好幫手：GitHub Actions 插件

   • 提供 GitHub Actions YAML 檔的自動完成、語法檢查與驗證功能。

   • 降低維護 CI 腳本的難度，避免自動化設定本身寫錯。

團隊規模化：強制統一開發工具

為了避免「每個人的電腦環境都不一樣」的狀況，我們可以直接把推薦的 Extension 寫在專案裡。只要在專案根目錄建立 .vscode/extensions.json：

{
  "recommendations": [
    "eamodio.gitlens",
    "ms-azuretools.vscode-docker",
    "sonarsource.sonarlint",
    "esbenp.prettier-vscode",
    "dbaeumer.vscode-eslint",
    "github.vscode-github-actions"
  ]
}

• 為什麼要用 recommendations？ 當新同事把專案打開時，VS Code 會自動跳出提示問你要不要安裝這些插件，確保大家都在同一個起跑線上。

• 配合 SettingsSync：建議團隊成員開啟 IDE 的同步功能，並透過 .vscode/settings.json 設定好專案專屬的自動化行為。

結語

在本地端做好防護，是提升開發效率的關鍵。把檢查跟排版工具整合進 IDE 裡，我們就能建立一個讓問題Shift left 的流程。這不但能提升程式碼品質，也讓後續的 CI/CD 流程能專門去處理更複雜的打包與部署。

搞定 IDE 的防線之後，明天我們要往上一層，來聊聊在大規模開發時，該怎麼管理好 Git 倉庫的效能。