---
tags: 
aliases: 
date: 2025-08-04 
time: 16:49:36
description: 
---

# 核心設計原則
本課程遵循3Rs架構：
1. 可讀性（Readability）：讓程式碼易於理解和維護
2. 可重用性（Reusability）：減少重複程式碼，提高開發效率
3. 可重構性（Refactorability）：支援模組化設計和持續改進

# 第一階段：基礎理論與核心原則
- **Clean Code定義與重要性**
    - 什麼是Clean Code：易讀、易懂、易維護的程式碼
    - 技術債務的概念與影響
    - 童子軍規則：讓程式碼比接手時更乾淨

Good code:
```python
def calculate_doubled_value_plus_one(input_value):
    """計算輸入值的兩倍加一"""
    OFFSET = 1
    
    if input_value <= 0:
        raise ValueError("Input value must be positive")
    
    doubled_value = input_value * 2
    result = doubled_value + OFFSET
    return result
```

Bad code:
```python
def f(x):
if x > 0:
    y = x * 2
    # TODO: fix this later
    z = y + 1  # magic number
    return z
else:
    return -1
```

- **有意義的命名規範**
    - 使用具描述性且明確的變數名稱
    - 函式命名：動詞片語表達動作意圖
    - 類別命名：名詞表達實體概念
    - 避免縮寫和神秘數字

Good code:
```javascript
// 良好的命名
let elapsedTimeInDays;
let activeUsers = [];
let calculateTotalPrice = (price, quantity) => price * quantity;
```

```python
def fetch_user_profile():
    return user_profile_data

def validate_user_credentials():
    # 驗證使用者憑證
    codes.....
```

Bad code:
```javascript
// 糟糕的命名
let d;  // 經過的天數
let u = [];  // 使用者列表
let calc = (a, b) => a * b;
```

```python
def data():
    return user_info

def process():
    # 處理某些東西
    pass
```

- **函式設計原則**
    - 單一職責原則：一個函式只做一件事
    - 函式長度控制：目標在20行以下
    - 參數管理：最多3個參數的建議
    - 避免副作用與Flag參數

## 一個函式只做一件事
Good code:
```python
# 遵循單一職責的函式
def validate_user_data(user_data):
    """僅負責驗證使用者資料"""
    if not user_data.get('email'):
        raise ValueError("Email required")
    return True

def save_user_to_database(user_data):
    """僅負責儲存資料"""
    database.save(user_data)

def send_welcome_notification(email):
    """僅負責發送歡迎郵件"""
    email_service.send_welcome_email(email)

def log_user_registration(username):
    """僅負責記錄日誌"""
    logger.info(f"User {username} registered successfully")
```

Bad code:
```python
# 違反單一職責的函式
def process_user_data(user_data):
    # 驗證資料
    if not user_data.get('email'):
        raise ValueError("Email required")
    
    # 儲存到資料庫
    database.save(user_data)
    
    # 發送通知郵件
    email_service.send_welcome_email(user_data['email'])
    
    # 記錄日誌
    logger.info(f"User {user_data['name']} processed")
```
        
- **程式碼組織結構**
    - 降層原則：由上到下的閱讀順序
    - 錯誤處理：使用例外處理取代錯誤碼
        
- **註解最佳實踐**
    - 何時需要註解，何時不需要
    - 讓程式碼自我說明
    - 有效註解的撰寫技巧
        
- **程式碼格式化**
    - 一致性的重要性
    - 縮排與空白字元的運用
    - 程式碼區塊的邏輯分組

# 第二階段：進階設計原則
- **五大SOLID原則詳解**
    - **S**：單一職責原則（SRP） 
    - **O**：開放封閉原則（OCP）
    - **L**：里氏替換原則（LSP）
    - **I**：介面隔離原則（ISP）
    - **D**：依賴反轉原則（DIP）
- **實務應用案例**
    - 每個原則的程式碼範例
    - 違反原則的常見問題

- **常用設計模式**
    - 工廠模式：封裝物件創建
    - 策略模式：演算法替換
    - 觀察者模式：事件處理    
    - 裝飾者模式：功能擴展
        
- **重構基本概念**
    - 重構定義：改善內部結構不影響外部行為
    - 重構時機：三次法則與預備性重構
    - 安全重構：依賴測試確保正確性
        
- **常用重構手法**
    - 提取方法（Extract Method）
    - 封裝成員變數（Encapsulate Field）
    - 方法更名（Rename Method）
    - 消除重複程式碼
        
# 第三階段：實戰應用
- **TDD基本概念與流程**
    - 紅燈-綠燈-重構循環
    - 單元測試的撰寫技巧
    - 測試覆蓋率與品質指標

- **專案案例分析**
    - BMI計算機Clean Code版本實作
    - 購物車系統的Clean Code改造
    - 登錄註冊系統的重構實戰
        
- **程式碼審查流程**
    - 審查清單建立
    - 給予建設性回饋的技巧
    - 處理團隊中程式碼品質分歧
        

# 第四階段：進階實踐
- **效能最佳化考量**
    - 何時最佳化？
    - Clean Code與效能的權衡
    - 常見效能反模式避免

- **建立個人程式碼品質標準**

# 參考來源