💻 程式設計單元：開發程式碼 - 綜合學習筆記

各位未來的程式設計師，大家好！歡迎來到「開發程式碼」(Develop Code) 這個章節。在這裡，你之前學習過的規劃和演算法將會化身為實際運作的軟體！學習程式設計不只是輸入指令，更重要的是具備邏輯思維來解決問題，並確保你的解決方案穩定且可靠。

如果寫程式一開始讓你覺得有些困難，別擔心。把它想像成學習烹飪：你遵循食譜（演算法），混合各種食材（變數與輸入），最終就能做出美味的成品（程式）！

1. 軟體開發生命週期 (SDLC)

開發程式是一個結構化的過程。你不會在沒有藍圖的情況下建造摩天大樓！遵循這些階段能確保你的程式碼更有效率、沒有錯誤，且能滿足使用者的需求。

第一階段：規劃與分析
  • 確認問題並定義需求（程式必須完成什麼功能）。
  • 設計解決方案（建立演算法、結構圖等）。
第二階段：編碼與實作 (開發程式碼)
  • 使用合適的程式語言編寫程式碼。
  • 將演算法（例如流程圖）轉化為實際指令。
  • 注重程式碼的可讀性與可維護性（參見第 2 節）。
第三階段：測試與除錯
  • 執行程式碼並檢查運作是否正確。
  • 找出並修復出現的任何錯誤（臭蟲/Bugs）。
  • 使用各種類型的數據進行測試，確保程式具備穩健性 (Robustness)。
第四階段：評估與維護
  • 根據最初的需求評估最終成品。它是否符合規格？
  • 如有必要，在未來更新程式碼以修復新發現的錯誤或新增功能。

重點提示：開發程式碼並非單向直線進行！你通常會在編碼、測試和除錯之間循環，直到程式完美運作為止。

2. 優質程式碼的特性

寫出能執行的程式碼只是第一步；寫出簡潔、清晰且易於讓人（或未來的你自己！）理解的程式碼至關重要。這就是所謂的可維護程式碼 (Maintainable Code)。

A. 可讀性與結構
  • 有意義的變數名稱：與其將變數命名為 a 或 x1，不如使用具描述性的名稱，如 userAge 或 totalScore。這樣讀者一眼就能看出該變數儲存的是什麼資料。
  • 縮排與間距：使用一致的縮排（Tab 鍵）來顯示程式碼行數屬於哪個控制結構（例如 IF 語句或 FOR 迴圈）。這能讓程式結構一目了然。
  • 模組化 (Modularisation)：將大型任務拆解為較小且易於管理的區塊，稱為模組 (Modules)、程序 (Procedures) 或函式 (Functions)。比喻：閱讀一本長書時，拆分成章節閱讀會比閱讀一大段連綿不斷的文字容易得多。
B. 註解的重要性

註解 (Comments) 是程式碼中電腦會自動忽略的文字行。它們的存在完全是為了人類！

  • 註解說明複雜的程式碼區塊「如何」運作。
  • 說明重要變數或函式的用途。
  • 對於除錯和維護至關重要。當你在六個月後重新回來看程式碼時，註解能幫助你回想起當初的想法！

你知道嗎？專業的程式設計師花在閱讀和維護既有程式碼的時間，通常比編寫全新程式碼的時間還多！乾淨的程式碼能節省時間與金錢。

3. 了解錯誤 (Bugs)

錯誤 (Bug) 是指程式中導致其行為異常或崩潰的問題。尋找並修復這些錯誤（除錯/Debugging）是開發過程中非常重要的一部分。

三種錯誤類型

別擔心！每個人都會犯錯。關鍵在於知道如何辨識它們。

  1. 語法錯誤 (Syntax Errors)

    這是程式語言在語法或規則上的錯誤。程式無法理解該指令，因此無法執行。
    例如：在 Python 中，將 print 誤拼成 prnt，或是在 IF 語句中忘記打冒號 (:)。

    偵測方式：通常在程式執行前，程式開發環境 (IDE) 就會自動偵測出來。

    比喻：作文中的錯別字或語法錯誤。你的老師（電腦）無法理解你想表達的意思。

  2. 邏輯錯誤 (Logic Errors)

    程式碼語法正確且能成功執行，但執行的結果並非你預期。輸出結果是錯誤的。
    例如：你想計算兩個數值的平均值，卻誤用減法取代加法：average = (num1 - num2) / 2。

    偵測方式：這些最難發現！只能透過仔細測試，並將實際輸出與預期輸出進行核對來找出。

    比喻：食譜上寫「加入 2 湯匙鹽」，結果你只加了 2 茶匙。程式能跑，食物也能吃，但味道不對（輸出結果錯誤）。

  3. 執行時期錯誤 (Run-time Errors)

    這些錯誤在程式執行期間發生，通常是因為電腦在執行過程中遇到了無法處理的操作。程式通常會崩潰或卡死。
    例如：試圖將數字除以零（例如 \(10 / 0\)）。這在數學上是不可能的，會導致程式崩潰。

    偵測方式：只有在執行到該特定程式碼行時才會被偵測到。

快速複習：錯誤類型

Syntax (語法) = Spelling/Grammar (拼字/文法錯誤，無法執行)
Logic (邏輯) = Lies/Wrong Answer (說謊/答案錯誤，能執行但輸出錯誤)
Run-time (執行時期) = Random Crash (隨機崩潰，執行時才發生)

4. 測試的藝術

測試是一種系統化的方式，用來檢查你的程式是否具備穩健性 (Robust)（能妥善處理錯誤數據）並輸出正確結果。在宣告程式完成前，必須使用不同類型的數據進行測試。

三種測試數據類型

為了確保穩健性，我們使用三類數據：

  1. 正常數據 (Normal Data / Valid Data)

    你預期使用者會輸入且程式必定會接受的數據。這些數據落在可接受的範圍內。
    例如：若程式接受 18 到 65 歲之間的年齡，正常數據可能是 30、45 或 50。

  2. 邊界數據 (Boundary Data / Extreme Data)

    落在可接受範圍邊緣或極限的數據。程式設計師常在處理極限時犯錯（例如：使用 < 而非 ≤）。測試邊界可確保極限處理正確。
    例如：針對 18 到 65 歲範圍，邊界數據即為 18 和 65。你也應該測試邊界外側的數字：17 和 66。

  3. 錯誤數據 (Erroneous Data / Exceptional Data)

    程式應該要拒絕的數據，通常會觸發錯誤訊息。這用來測試輸入驗證是否足夠穩健。
    例如：針對 18 到 65 歲範圍，錯誤數據可能是 -5、100，或輸入文字「二十」而非數字。

重點提示：只有在能正確處理上述三種數據（特別是錯誤數據）的情況下，程式才算具備穩健性。

5. 除錯技巧：追蹤表 (Trace Table)

當出現邏輯錯誤時，電腦不會告訴你錯在哪裡。你需要自己成為電腦！追蹤表 (Trace Table)（又稱乾跑/Dry Run）是一種強大的手動技術，用於追蹤演算法執行過程中，每個變數值的逐行變化。

如何使用追蹤表（偵探工具）

想像以下簡單的演算法：將輸入的數字加到總和中，但僅限於該數字大於 10 時。

追蹤表能幫助你手動檢查邏輯是否正確。

第一步：設定
為程式中使用的每個變數建立欄位，外加一個「輸出」欄和一個「條件」欄（用於 IF 語句或迴圈）。

第二步：執行
逐行檢查程式碼。每當變數值改變，就在表格中記錄新值。僅在程式顯示內容時記錄輸出欄。

追蹤表示例結構：

行號 輸入 (N) 總和 (Total) 條件 (N > 10) 輸出
1 - 0 - -
2 (輸入 5) 5 0 False -
2 (輸入 15) 15 0 True -
3 (若為 True) 15 15 (0 + 15) True -
4 (輸出) 15 15 - 總和是 15

透過追蹤步驟，你可以精確定位變數何時出現非預期的值，進而找出導致邏輯錯誤的程式碼行。如果最終輸出是 15 而你預期是 20，你便可以反向追蹤找出 5 是在哪個步驟被錯誤處理的。

追蹤表小撇步！

永遠從每個變數的初始值（通常為 0 或空值）開始，且切勿跳過任何步驟。如果該行變數沒有改變，請將舊值寫入下一步驟。

6. 常見的開發陷阱

在開發程式碼時，請留意這些常見錯誤：

  • 差一錯誤 (Off-by-one Errors)：這是一種經典的邏輯錯誤，迴圈執行次數多了一次或少了一次（例如：本應迴圈 9 次，卻執行了 10 次）。務必仔細檢查邊界條件！
  • 忽視輸入驗證：假定使用者總會輸入正確類型的數據。如果你要求輸入數字，就必須編寫代碼來處理使用者輸入文字的情況（錯誤數據）。
  • 忽視數據類型：混淆了數值類型（用於計算）與字串類型（用於文字）。例如：試圖將數字 5 加到文字「10」上。
  • 測試不足：只測試正常數據。這是危險的！你必須使用邊界數據和錯誤數據來找出那些隱晦的臭蟲。

本章提供了從設計演算法到構建可靠程式的必備工具。請持續練習你的追蹤與測試技巧！


*** 章節筆記結束 ***