經過前兩天高強度的語法學習，今天我們可以稍微放鬆一下，從具體的程式碼中抽離出來，聊一些更「軟」但同樣重要的事情。

今天，我想分享兩件事：一是讓團隊合作更順暢的「程式碼風格指南」，二是如何更有效地使用我們的「AI 家教」。

為什麼我們需要「程式碼風格指南 (Coding Guidelines)」？

• 困惑點：程式碼只要能跑，不就好了嗎？為什麼還需要管它長什麼樣子？變數要用駝峰式命名、括號要不要換行，有這麼重要嗎？

• AI 協作

  • 我的 Prompt：我是一個程式新手，請用一個簡單的比喻，告訴我為什麼遵守一個團隊的 Coding Guidelines 很重要？

  AI 的回答

  好的，身為程式新手，這是一個絕佳的問題！

  試著想像一下：一個團隊要合力建造一棟樂高城堡。

  如果開始動工前，沒有人討論施工規則，會發生什麼事？

  • 小明 喜歡用「紅色」的樂高當牆壁。
  • 小華 堅持牆壁應該是「灰色」的，而且他喜歡一次用兩顆樂高疊起來，覺得比較快。
  • 小美 則認為窗戶應該要用「透明」的零件，但小明卻拿了「藍色」的零件來做窗戶。
  • 更糟的是，每個人蓋好的部分要組合起來時，發現彼此的卡榫方向、地基高度都不一樣，根本接不起來，或是接起來後歪七扭八，非常不穩固。

  結果就是，雖然每個人都很努力，但最後這座城堡看起來會像個拼裝怪物，顏色混亂、結構脆弱，甚至輕輕一碰就可能倒塌。如果要修改其中一部分（例如把窗戶加大），可能會牽一髮動全身，導致更大範圍的崩壞。

  ---

  Coding Guidelines 就是這座樂高城堡的「建築藍圖和施工規範」。

  它會事先規定好：

  1. 牆壁要用什麼顏色、什麼尺寸的樂高？
     • 對應程式碼： 變數要如何命名（例如：用 camelCase 駝峰式還是 snake_case 蛇形命名法）、要用 tab 還是 space 來縮排。
  2. 每層樓要蓋多高？地基要怎麼打才穩固？
     • 對應程式碼： 函式（Function）的長度不能超過多少行、檔案和資料夾的結構要如何組織。
  3. 窗戶和門要用哪種標準零件？
     • 對應程式碼： 處理錯誤的標準方法、註解的格式要怎麼寫、應該使用哪個版本的程式庫（Library）。

  為什麼遵守它很重要？

  • 一致性與可讀性 (Consistency & Readability): 就像你看一份設計統一的建築藍圖一樣，你看隊友寫的程式碼，會感覺像是自己寫的，能快速理解他的邏輯，反之亦然。你不用花時間去猜測「喔，原來他這個變數是指那個意思」。
  • 易於維護與協作 (Maintainability & Collaboration): 當城堡的一部分（某個功能）需要修改或擴建時，因為大家當初蓋的方法都一樣，任何人都可以快速接手，而不會破壞到其他結構。你不需要把原作者找來，問他：「你當初這塊奇怪的藍色積木是什麼意思？」
  • 減少錯誤 (Error Reduction): 統一的規範能避免許多常見的「低級錯誤」。就像規定了地基的蓋法，就能確保城堡不會輕易倒塌一樣。
  • 提升效率 (Efficiency): 當你不用再為「變數該叫 user_data 還是 userData」這種小事煩惱時，你就可以把所有精力專注在解決真正的核心問題上。團隊的程式碼審查（Code Review）也會更順暢，大家可以專注在邏輯本身，而不是一直在挑剔排版風格。

  結論

  遵守 Coding Guidelines，就像是讓整個團隊用共同的語言和方法來建造樂高。雖然一開始可能會覺得有些束縛，但它能確保最終的成品（軟體）是結構穩固、風格統一、且容易擴充和維護的。對於一個團隊來說，這遠比個人自由發揮來得更重要且更有效率。

  • 雖然現在是獨自學習，但養成好習慣要趁早。我上網查了幾個業界廣泛使用的 Swift 風格指南，也分享給大家：
    • Swift Style Guide ：Google 發布的官方風格指南，非常詳盡。
    • Kodeco (Ray Wenderlich) Swift Style Guide：非常知名的 iOS 開發教學網站的風格指南，很受社群推崇。
    • UI 元件（之後要實作出App一定會用到）
      • 以「元件名稱」＋「變數名稱」命名
        • Example(登入按鈕)：btnLogin

• 雖然每個團隊程式碼風格都不一樣，但先養成好習慣，之後加入團隊時也可以更快知道程式碼在幹麻。這些東西可以先快速瀏覽一次，不需要全部背下來，之後要實作時可以把它當參考書放旁邊，慢慢對照。

我的 AI 家教使用心得：如何「問出好問題」？

在過去幾天的學習筆記中，大家看到我一直在用「AI 協作」。但這個過程，並非一開始就如此順利。

起初，我像對待一個無所不知的智慧長者那樣向它提問，結果卻常常得到一些文不對題、或過於空泛的答案。

我很快就學到了一課：AI 的能力上限，取決於我提問的品質下限。

您可以把 AI 想像成一位剛加入公司的「最強新人」。他天賦異稟、知識淵博、精力無限，但極度缺乏實務經驗與「察言觀色」的能力。你必須給他非常、非常明確的指令，他才能發揮出 100% 的實力。

經過這段時間的磨合，我摸索出了幾個能與這位「最強新人」有效溝通的原則，在這裡分享給大家。

原則一：給他明確的「任務清單」，而不只是「一個問題」

這是最重要的一點。模糊的問題，只會得到模糊的答案。

• (❌) 不好的提問：

  「什麼是迴圈？」

  (AI 可能會給你一段維基百科式的、冗長的理論解釋。)

• (✅) 好的提問：

  「請用 Swift 程式碼，示範一個「for-in 迴圈」，讓它印出 1 到 5 的數字。請為每一行程式碼加上註解，解釋它的作用。」

這個提問包含了三個清晰的指令：1. 用 Swift 寫。 2. 示範 for-in 迴圈印出 1-5。 3. 加上逐行註解。AI 在收到這樣明確的「任務清單」後，給出的答案通常會非常精準。

原則二：當遇到高牆時，請他「打個比方」

面對 Optional、Closure 這些抽象到令人頭痛的概念時，硬啃定義是沒有效率的。這時，我最喜歡的技巧就是要求 AI 打比方。

• (✅) 有效的提問：

  「請用一個生活中的比喻，解釋 Swift 的 Optional 是什麼，以及為什麼它很重要？」

  （這就是我們在 Day 3 用過的技巧。）

這個方法能強迫 AI 跳出純粹的技術定義，用人類的經驗來類比。

原則三：讓他「動手做」，而不是「動口說」

有時候，我需要的不是解釋，而是一個可以直接操作的範例。

• (✅) 有效的提問：

  「請幫我生成一組 Swift 資料：一個存放電影清單的 Array、一個記錄購物車的 Dictionary、一個儲存派對賓客的 Set。」

  （這也是我們在 Day 2 用過的技巧。）

讓 AI 直接產出結構化的資料或程式碼，再由我們自己去觀察、分析和總結，往往比看長篇大論的解釋來得更直接、更有效。
不過，在後面我們實際動手做 App 時，你會發現我的策略會有所轉變：我會先試圖向 AI 詢問可行的做法與原理，在自己理解完後，才會請它生成部分程式碼作為參考或加速開發，而不是直接索取完整的答案。

原則四：把他當成「程式碼重構」的夥伴

這是我最近發現的一個進階用法。當我寫完一段自己不太滿意的程式碼後，我會把它貼給 AI，請它幫忙「健檢」。

• (✅) 有效的提問：

  「這是我寫的一段 if-else if-else 程式碼，你覺得它有什麼可以改進的地方嗎？有沒有更符合 Swift 風格的寫法？」

這個提問，常常會引導 AI 建議我使用 switch 或其他語法，成為我優化程式碼、學習新寫法的重要助力。

好了，我們今天沒有寫程式碼，但卻把我們開發者的「工具箱」和「心法」都整理了一遍。

從明天開始，我們就要真正地打開 Xcode，創建我們的第一個專案，正式踏上 App 開發的建造之旅 。