# สัปดาห์ที่ 11: Quality Metrics, QA และ Code Review

## สารบัญ

1. [วัตถุประสงค์การเรียนรู้](#วัตถุประสงค์การเรียนรู้)
2. [ส่วนที่ 1: Process Metrics & Code Coverage](#ส่วนที่-1-process-metrics--code-coverage)
   - [1.1 ทำไมต้องวัด?](#11-ทำไมต้องวัด)
   - [1.2 Lines of Code (LOC)](#12-lines-of-code-loc)
   - [1.3 Cyclomatic Complexity](#13-cyclomatic-complexity)
   - [1.4 Code Coverage กับ Jest](#14-code-coverage-กับ-jest)
   - [1.5 Defect Density](#15-defect-density)
3. [ส่วนที่ 2: QA vs QC & มาตรฐานคุณภาพ](#ส่วนที่-2-qa-vs-qc--มาตรฐานคุณภาพ)
   - [2.1 QA vs QC — ความแตกต่างที่สำคัญ](#21-qa-vs-qc--ความแตกต่างที่สำคัญ)
   - [2.2 มาตรฐานคุณภาพซอฟต์แวร์](#22-มาตรฐานคุณภาพซอฟต์แวร์)
   - [2.3 Quality Gates](#23-quality-gates)
4. [ส่วนที่ 3: Static Analysis Tools & Peer Review](#ส่วนที่-3-static-analysis-tools--peer-review)
   - [3.1 ESLint — Static Analysis ระดับโค้ด](#31-eslint--static-analysis-ระดับโค้ด)
   - [3.2 SonarQube — ภาพรวม](#32-sonarqube--ภาพรวม)
   - [3.3 GitHub PR Code Review](#33-github-pr-code-review)
5. [D4 — Quality & Security Report คืออะไร](#d4--quality--security-report-คืออะไร)
6. [Activity 1: วิเคราะห์ Metrics จาก Case Study](#activity-1-วิเคราะห์-metrics-จาก-case-study-45-นาที)
7. [Activity 2: Quality Report Workshop](#activity-2-quality-report-workshop--เริ่มทำ-d4-45-นาที)
8. [สรุป](#สรุป)

---

## วัตถุประสงค์การเรียนรู้

เมื่อสิ้นสุดบทเรียนในสัปดาห์นี้ นักศึกษาจะมีความสามารถดังต่อไปนี้:

1. **วัดตัวชี้วัดกระบวนการ:** คำนวณและตีความค่า Lines of Code (LOC) ความซับซ้อนตามวัฏจักร (Cyclomatic Complexity) และความหนาแน่นของข้อบกพร่อง (Defect Density)
2. **วัดระดับการครอบคลุมการทดสอบ:** ใช้ Jest `--coverage` เพื่อวัดระดับการครอบคลุมและเข้าใจกลไกการวัดของ Istanbul
3. **แยกแยะระหว่าง QA และ QC:** อธิบายความแตกต่างระหว่าง Quality Assurance และ Quality Control พร้อมทั้งอ้างอิงมาตรฐาน ISO
4. **ใช้เครื่องมือวิเคราะห์โค้ด:** ตั้งค่า ESLint และเข้าใจการใช้งานแพลตฟอร์ม SonarQube
5. **ทำการตรวจสอบโค้ด:** ตรวจสอบโค้ดบนแพลตฟอร์ม GitHub PR โดยใช้กระบวนการที่เป็นระบบเพื่อประเมินด้านคุณภาพ

---

## ส่วนที่ 1: Process Metrics & Code Coverage

### 1.1 ความจำเป็นของการวัดตัวชี้วัด

**หลักการพื้นฐาน:** "สิ่งที่ไม่สามารถวัดได้ก็ไม่อาจปรับปรุงได้" — Tom DeMarco ผู้บุกเบิกสาขาวิศวกรรมซอฟต์แวร์

**ประโยชน์ของการวัดตัวชี้วัด:**

```
ประโยชน์:
  - ติดตามความก้าวหน้า: ระบุว่าคุณภาพของโค้ดปรับปรุงหรือลดลง
  - ระบุจุดเสี่ยง: ค้นหา modules ที่มีความเสี่ยงต่อการเกิดข้อบกพร่อง
  - ตัดสินใจอย่างเป็นระบบ: ขึ้นอยู่กับข้อมูลจริงแทนการคาดเดา
  - บังคับนโยบายคุณภาพ: ใช้ Quality gates ในระบบ CI เพื่อควบคุมการ merge โค้ด

ข้อจำกัด:
  - Metrics ไม่ใช่เครื่องมือแก้ปัญหาเพียงอย่างเดียว: ต้องวิเคราะห์บริบทประกอบด้วย
  - ความเสี่ยงจากการปลอมแปลงข้อมูล: นักพัฒนาอาจเขียนการทดสอบที่ไม่มีคุณภาพเพื่อเพิ่มค่า metrics
  - ต้องเลือกตัวชี้วัดที่เหมาะสม: ไม่ใช่ทุก metrics มีความหมายสำหรับทุก project
```

**Metrics Dashboard ตัวอย่าง:**

```
Metric                  Value  Target    Status
────────────────────────────────────────────────
Lines of Code (LOC)     2,450  -         ✓
Code Coverage (%)         73%  ≥ 80%     Low
Cyclomatic Complexity    4.2   ≤ 10      OK
Defect Density/KLOC      0.8   ≤ 1.0     OK
```

---

### 1.2 Lines of Code (LOC)

**นิยาม:** Lines of Code (LOC) หมายถึง จำนวนบรรทัดของโค้ดที่เขียน (ไม่รวมบรรทัดว่าง ข้อความอธิบาย และ header)

**ประโยชน์ของการวัด LOC:**

- วัดขนาดของระบบ: ทำให้ทราบจำนวนบรรทัดโค้ดทั้งหมดของ project
- เปรียบเทียบขนาดของส่วนประกอบ: เปรียบเทียบขนาดระหว่าง modules
- ประมาณความพยายามในการบำรุงรักษา: จำนวน LOC มากมายมักหมายถึง cost ของการบำรุงรักษาที่สูงกว่า

**วิธีการวัด:**

```bash
# ใช้เครื่องมือ cloc (Count Lines of Code)
npm install -g cloc

# นับ LOC ของ project
cloc src/

# Output ตัวอย่าง:
#    Language      Files    Blank    Comment    Code
#    JavaScript       12       89       145    2450
#    JSON              3        0         0     180
#    ──────────────────────────────────────────────
#    Total            15       89       145    2630
```

**ใช้ได้เมื่อ / ไม่ควรใช้เมื่อ:**

```
ใช้ได้เมื่อ:
   - วัดขนาดโดยรวมและความซับซ้อนของระบบ
   - เปรียบเทียบขนาดระหว่าง modules ต่าง ๆ
   - ประมาณการความพยายามและค่าใช้จ่ายในการบำรุงรักษา

ไม่ควรใช้เมื่อ:
   - ใช้เป็นตัวชี้วัดเดียวในการประเมินประสิทธิภาพโดยรวม
   - ใช้เป็นตัวชี้วัด KPI สำหรับนักพัฒนาเดี่ยว
   - LOC ไม่สามารถบ่งชี้คุณภาพของสถาปัตยกรรมหรือความถูกต้องของการออกแบบ
```

---

### 1.3 ความซับซ้อนตามวัฏจักร (Cyclomatic Complexity)

**นิยาม:** Cyclomatic Complexity (CC) หมายถึง จำนวนเส้นทางการดำเนินการ (execution path) อิสระภายในโค้ด

**สูตรทางคณิตศาสตร์:** CC = E − N + 2P
โดยที่ E = edges (เส้นเชื่อม), N = nodes (จุด), P = connected components
**การประมาณ:** CC ≈ (จำนวน if/else + while + for + case) + 1

**ระดับความซับซ้อนและความหมาย:**

```
CC Score   ระดับความซับซ้อน   รายละเอียด
──────────────────────────────────────────────────────
1-5        ง่าย             เข้าใจได้ง่าย ทดสอบง่าย
6-10       ปานกลาง          ปกติ แต่ต้องสร้าง test cases หลายชุด
11-20      ซับซ้อน          ยากต่อการทำความเข้าใจ แนะนำการเขียนใหม่
> 20       ซับซ้อนมาก      จำเป็นต้องเขียนใหม่โครงสร้าง
```

**ตัวอย่าง: BAD code (CC ≈ 8)**

```javascript
// BAD: High Cyclomatic Complexity
function processOrder(order, customer, warehouse, shipping) {
  if (order.items.length === 0) {
    return { error: "Empty order" };
  }

  if (customer.isActive) {
    if (customer.credit > order.total) {
      if (warehouse.hasStock(order.items)) {
        if (shipping.canDeliver(customer.address)) {
          // Process order...
          order.status = "confirmed";
        } else {
          return { error: "Cannot deliver" };
        }
      } else {
        return { error: "Out of stock" };
      }
    } else {
      return { error: "Credit limit" };
    }
  } else {
    return { error: "Inactive customer" };
  }
}
// CC = 5 nested if statements + 1 = 6
```

**ตัวอย่าง: GOOD code (CC = 2 per function)**

```javascript
// GOOD: Low Cyclomatic Complexity (Early Returns)
function processOrder(order, customer, warehouse, shipping) {
  // Validation: CC = 1
  if (!validateOrder(order)) {
    return { error: "Invalid order" };
  }

  if (!canProcess(customer, warehouse, shipping, order)) {
    return { error: getErrorReason(customer, warehouse, shipping) };
  }

  // If we reach here, process order
  order.status = "confirmed";
  return { success: true };
}

// Helper functions: each CC ≤ 3
function validateOrder(order) {
  if (order.items.length === 0) return false;
  if (order.total <= 0) return false;
  return true;
}

function canProcess(customer, warehouse, shipping, order) {
  if (!customer.isActive) return false;
  if (customer.credit <= order.total) return false;
  if (!warehouse.hasStock(order.items)) return false;
  if (!shipping.canDeliver(customer.address)) return false;
  return true;
}
```

**ความสำคัญของการรักษา CC ให้ต่ำ:**

```
ประโยชน์ของ CC ต่ำ:
   - เข้าใจได้ง่าย: โครงสร้างตรรมชาติของโปรแกรม
   - ทดสอบได้ง่าย: จำนวน path น้อย = จำนวน test case น้อย = บรรลุ coverage ได้สะดวก
   - บำรุงรักษาได้ง่าย: การแก้ไขข้อบกพร่อง = ความเสี่ยงต่ำ

ผลกระทบจาก CC สูง:
   - ต้องครอบคลุม 2^CC เส้นทาง (CC=8 = 256 เส้นทาง!)
   - ความยากในการบรรลุ coverage: แม้ 100% LOC test ก็ยังมี coverage ต่ำ
   - ความเสี่ยงสูง: การแก้ไขส่วนหนึ่งเสี่ยงต่อการสร้างข้อบกพร่องในส่วนอื่น
```

---

### 1.4 การวัดระดับการครอบคลุมการทดสอบ กับ Jest

**นิยาม:** Code Coverage หมายถึง สัดส่วนของโค้ดที่ถูกรันหรือตรวจสอบโดยชุดการทดสอบอัตโนมัติ

**สี่ประเภทของการวัด Coverage:**

```
ประเภท             ความหมาย                                     เป้าหมายต่ำสุด
────────────────────────────────────────────────────────────────────────
Statement Coverage  บรรทัดของโค้ดที่ต้องถูกรัน                    ≥ 80%
Branch Coverage    ทุก path ของคำสั่ง if/else ต้องทดสอบ         ≥ 70%
Function Coverage   ทุก function ต้องเรียกใช้อย่างน้อยครั้งเดียว   ≥ 80%
Line Coverage      ทุก line ต้องถูกรันอย่างน้อยครั้งเดียว         ≥ 80%
```

**ใช้ Jest --coverage:**

```bash
# รันทดสอบพร้อมสร้าง coverage report
npx jest --coverage

# ผลลัพธ์:
# ────────────────────────────────────────────────
# File          | % Stmts | % Branch | % Funcs | % Lines
# ────────────────────────────────────────────────
# budget.js     |   73.33 |   50.00  |  100.00 |  73.33
# customer.js   |   85.50 |   80.00  |  95.00  |  85.50
# ────────────────────────────────────────────────
# All files     |   79.42 |   65.00  |  97.50  |  79.42
```

**ตั้งค่า Jest threshold ใน package.json:**

```json
{
  "jest": {
    "collectCoverage": true,
    "coverageThreshold": {
      "global": {
        "branches": 70, // ทุก branch ≥ 70%
        "functions": 80, // ทุก function ≥ 80%
        "lines": 80, // ทุก line ≥ 80%
        "statements": 80 // ทุก statement ≥ 80%
      }
    },
    "coverageReporters": ["text", "lcov", "html"]
  }
}
```

**เมื่อ coverage ต่ำกว่า threshold:**

```
$ npm test

FAIL  src/budget.test.js
  Jest: "global" coverage threshold: 80.00% statements,
        but got 73.33%

CI Pipeline FAILS!
   → PR merge ถูกปฏิเสธ
   → บังคับ developer เขียน tests เพิ่มเติม
```

**เหตุผลของการตั้ง coverage threshold:**

```
ประโยชน์:
   - ระบบอัตโนมัติ: ไม่ต้องให้ผู้ตรวจสอบตรวจสอบ coverage ในแต่ละครั้ง
   - ลดความเสี่ยง: โค้ดที่ไม่มีการทดสอบไม่สามารถ merge ได้
   - ความสม่ำเสมอของทีม: ทุกคนเขียนการทดสอบตามมาตรฐานเดียวกัน

ข้อจำกัด:
   - Coverage 100% ≠ ปราศจากข้อบกพร่อง: ต้องประเมินคุณภาพของ tests ด้วย
   - Coverage 80% ≠ สมบูรณ์แบบ: ต้องมีการตรวจสอบโดยมนุษย์ด้วย
```

---

### 1.5 ความหนาแน่นของข้อบกพร่อง (Defect Density)

**นิยาม:** Defect Density หมายถึง จำนวนข้อบกพร่องทั้งหมด หารด้วย KLOC (1,000 บรรทัดของโค้ด)

**สูตรคำนวณ:**

```
ความหนาแน่นของข้อบกพร่อง = (จำนวนข้อบกพร่องทั้งหมด / LOC) × 1,000

ตัวอย่างการคำนวณ:
  LOC: 2,450 บรรทัด
  ข้อบกพร่อง: 8 issues

  ความหนาแน่น = (8 / 2,450) × 1,000 = 3.27 defects/KLOC

  เกณฑ์การประเมิน:
    ≤ 1.0  = ✓ ยอดเยี่ยม (พร้อมส่ง)
    1-2    = ยอมรับได้ (พอใจได้)
    > 2    = ต้องปรับปรุง (อย่าส่งยัง)
```

**วิธีการเก็บรวบรวมข้อบกพร่องจากแพลตฟอร์ม GitHub:**

```bash
# 1. เข้าไปที่ repository บน GitHub
# 2. เลือก Issues → Filter: label:bug
# 3. นับ issues ทั้ง open และ closed (ในช่วงเวลาที่กำหนด)

ตัวอย่างการใช้งาน GitHub CLI:
gh issue list --label bug --state all --json number \
  | grep number | wc -l
```

---

## ส่วนที่ 2: QA vs QC & มาตรฐานคุณภาพ

### 2.1 Quality Assurance กับ Quality Control — ความแตกต่าง

**บริบท:** หลายคนสับสนระหว่างคำศัพท์สองคำนี้ แม้ว่าจะมีความหมายแตกต่างกันอย่างชัดเจน

**ตัวอย่างการเปรียบเทียบจากด้านการทำอาหาร:**

- **QA (Quality Assurance)** = การออกแบบและบำรุงรักษาครัวให้สะอาด ตั้งค่าเครื่องมือให้เหมาะสม → ป้องกันไม่ให้เกิดการปนเปื้อน
- **QC (Quality Control)** = การตรวจสอบอาหารก่อนเสิร์ฟ → ตรวจเจอและแยกอาหารเสียออก

**การเปรียบเทียบโดยละเอียด:**

```
ลักษณะ              QA (Quality Assurance)       QC (Quality Control)
────────────────────────────────────────────────────────────────────
จุดประสงค์          ป้องกันข้อบกพร่องเกิดขึ้น     ตรวจเจอและจดทำบันทึก
ขอบเขตการทำงาน     กระบวนการทั้งวงจร SDLC      ผลลัพธ์และเอกสารส่งมอบ
ช่วงเวลา            ตลอดเวลาการพัฒนา           หลังจากการ implement
ตัวอย่างกิจกรรม    Code review, PR, CI/CD      Unit tests, UAT, การทดสอบด้วยตนเอง
บทบาท               ทีมทั้งหมด (Dev, QA, PM)   ผู้เชี่ยวชาญ QA/Tester
วัดจาก              ตัวชี้วัดกระบวนการ         ตัวชี้วัดผลผลิต
```

**ความสำคัญของการรวมกัน:**

```
QA มีประสิทธิภาพ → หลีกเลี่ยงข้อบกพร่องตั้งแต่ต้น
QC มีประสิทธิภาพ → จับข้อบกพร่องก่อนส่งถึงผู้ใช้
QA ไม่ดี แต่ QC ดี → ต้องแก้ไขข้อบกพร่องอย่างต่อเนื่อง (สิ้นเปลือง)
QA ดี แต่ QC ไม่ดี → ข้อบกพร่องไม่ถูกตรวจเจอ (อันตราย)
```

---

### 2.2 มาตรฐานคุณภาพของซอฟต์แวร์

**ISO/IEC 25010** — มาตรฐานสำหรับประเมินคุณภาพของผลิตภัณฑ์ซอฟต์แวร์ (แทนที่ ISO 9126)

ซอฟต์แวร์ที่มีคุณภาพดีต้องมีลักษณะเด่น 8 ประการดังนี้:

```
1. Functional Suitability     — ผลลัพธ์สอดคล้องกับความต้องการและถูกต้อง
2. Performance Efficiency     — ความเร็วของการตอบสนองและการใช้ทรัพยากร
3. Compatibility             — สามารถทำงานร่วมกับระบบอื่นได้
4. Usability                 — ใช้งานได้ง่าย และผู้ใช้สามารถเข้าใจได้
5. Reliability               — ระบบมีเสถียรภาพและไม่เกิด crash
6. Security                  — ปลอดภัยและไม่มีช่องโหว่
7. Maintainability           — สามารถปรับปรุง แก้ไข และเข้าใจโค้ดได้ง่าย
8. Portability               — สามารถทำงานได้ในสภาพแวดล้อมต่าง ๆ
```

**CMMI** — ตัวแบบการพัฒนาความสามารถและความเป็นผู้บุกเบิก (Capability Maturity Model Integration)

```
ระดับ 1: เบื้องต้น         — กระบวนการไม่เป็นระบบ
ระดับ 2: ผ่านการบริหาร     — มีกระบวนการพื้นฐาน สามารถปฎิบัติซ้ำได้
ระดับ 3: กำหนดแล้ว        — กระบวนการชัดเจน และจัดทำเป็นเอกสาร
ระดับ 4: ติดตามด้วยตัวเลข  — วัดและตรวจสอบตัวชี้วัดกระบวนการ
ระดับ 5: เพิ่มประสิทธิภาพ   — มีการค้นหาการปรับปรุงอย่างต่อเนื่อง

องค์กรขนาดใหญ่ (NASA, Boeing, Infosys) อยู่ที่ระดับ 3-5
```

**หมายเหตุสำหรับนักศึกษา:**

```
ไม่จำเป็น:
  - จดจำ ISO ทั้งฉบับ
  - เสนอถึง CMMI Level 5 สำหรับ project ขนาดเล็ก

แต่จำเป็น:
  - ทำความเข้าใจลักษณะเด่น 8 ประการของ ISO 25010
  - อ้างอิง 1-2 ลักษณะเด่นเมื่อพูดถึงคุณภาพ
  - ตระหนักว่า "มาตรฐานคุณภาพ" = ภาษาร่วมของทีมกับผู้ขอใช้งาน
```

---

### 2.3 Quality Gates

**นิยาม:** Quality Gate = เงื่อนไขที่ต้องผ่าน ก่อน code จะ merge เข้า main branch

**ตัวอย่างเงื่อนไข:**

```
Fail merge ถ้า:
  - Code coverage < 80%
  - ESLint errors > 0 (critical)
  - SonarQube quality gate ล้ม
  - PR reviews < 1 approval
  - CI tests fail

Pass merge ถ้า:
  - Coverage ≥ 80%
  - No ESLint critical errors
  - SonarQube green
  - ≥ 1 reviewer approval
  - All CI checks ✓ green
```

**ตั้งค่า Quality Gate ใน GitHub Actions:**

```yaml
name: Quality Gate Check

on: [pull_request]

jobs:
  quality:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-node@v3
        with:
          node-version: "18"

      - name: ติดตั้ง dependencies
        run: npm ci

      - name: ตรวจสอบ Code Coverage (Quality Gate)
        run: npx jest --coverage --coverageThreshold='{"global":{"lines":80}}'
        # หาก coverage < 80% → step fail → PR fail

      - name: ตรวจสอบ Linting
        run: npx eslint src/ --max-warnings=0
        # หาก warnings > 0 → step fail

      - name: รัน Tests
        run: npm test
```

**เมื่อ quality gate ล้ม:**

```
PR cannot be merged

GitHub comment:
  "Quality gate failed:
   - Code coverage: 73% < 80% target

   To fix:
   1. Add more tests
   2. Run: npm run test:coverage
   3. Update PR"
```

---

## ส่วนที่ 3: Static Analysis Tools & Peer Review

### 3.1 ESLint — Static Analysis ระดับโค้ด

**คืออะไร:** ESLint = ตรวจสอบ JavaScript/TypeScript code โดยไม่ต้องรันโปรแกรม (static analysis)

**ประเภทของ rules:**

```
🔴 Error     — ต้องแก้ (CI pipeline fail)
🟡 Warning   — ควรแก้ (CI อาจ fail ตามเงื่อนไข)
⚫ Off       — ปิด (ไม่ check)
```

**ตัวอย่าง: BAD code (ESLint violations)**

```javascript
// BAD: Multiple ESLint violations
function calculateTotal(items) {
  var total = 0; // use var (not const)
  var unused = 100; // unused-vars: unused ไม่ใช้

  for (var i = 0; i < items.length; i++) {
    total += items[i].price;
    console.log(total); // no-console: ห้าม console ใน prod
  }

  return total;
} // no-semicolon

// ESLint errors:
// Line 2: use const/let instead of var
// Line 3: unused variable 'unused'
// Line 6: console.log not allowed
// Line 9: missing semicolon
```

**ตัวอย่าง: GOOD code (clean)**

```javascript
// GOOD: ESLint clean
function calculateTotal(items) {
  let total = 0; // use let/const

  for (const item of items) {
    total += item.price; // no unused variables
  }
  // no console.log

  return total; // semicolon
}
```

**ตั้งค่า .eslintrc.json:**

```json
{
  "extends": ["eslint:recommended"],
  "env": {
    "node": true,
    "es2021": true
  },
  "rules": {
    "no-unused-vars": "error", // ห้ามมี unused vars
    "no-console": "warn", // warn: production ห้าม console
    "complexity": ["warn", 10], // warn: CC > 10
    "max-lines-per-function": ["warn", 50], // warn: function > 50 บรรทัด
    "semi": ["error", "always"], // error: ต้องมี semicolon
    "quotes": ["error", "single"] // error: ใช้ single quotes
  }
}
```

**รัน ESLint:**

```bash
# ตรวจสอบ
npx eslint src/ --format=stylish

# Output:
#   src/budget.js
#   2:7  error   'var' is deprecated  no-var
#   3:7  error   'unused' is assigned but never used  no-unused-vars
#
#   ✖ 2 errors found

# Fix อัตโนมัติ (ถ้าได้)
npx eslint src/ --fix
```

**ใช้เมื่อ / ไม่ควรใช้เมื่อ:**

```
ใช้เมื่อ:
   - ทุกโปรเจกต์ JavaScript/TypeScript
   - enforce coding standards อัตโนมัติ
   - ลด bugs จากไวยากรณ์และ typos

ไม่ควรใช้เมื่อ:
   - แทนที่ Code Review ทั้งหมด
   - ESLint ตรวจ syntax/style แต่ไม่ตรวจ business logic
   - ปิดไปซะแล้ว (rules ทั้งหมดปิด = ไม่มีประโยชน์)
```

---

### 3.2 SonarQube — ภาพรวม

**คืออะไร:** SonarQube = platform สำหรับ continuous code quality inspection

**ใช้โดย:** Netflix, Microsoft, Airbnb, Google, Samsung...

**ตรวจสอบอะไร:**

```
🐛 Bugs          — โค้ดที่น่าจะทำให้ runtime error
🔒 Vulnerabilities — ช่องโหว่ด้านความปลอดภัย
💩 Code Smells   — โค้ดที่เข้าใจยาก บำรุงรักษายาก
📋 Duplications  — โค้ดซ้ำซ้อน (copy-paste smell)
📊 Metrics       — Coverage, complexity, size, comments
```

**SonarCloud** (เวอร์ชันคลาวด์ - ง่ายสำหรับนักศึกษา)

```
- Free สำหรับ public GitHub repos
- ไม่ต้อง setup เซิร์ฟเวอร์เอง
- Connect GitHub → automatic scan on every push
- Dashboard แสดง quality metrics
```

**ตั้งค่า SonarCloud ใน GitHub Actions:**

```yaml
- name: SonarCloud Quality Scan
  uses: SonarSource/sonarcloud-github-action@master
  env:
    SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }} # เพิ่มใน GitHub Secrets
    GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
  # ผลลัพธ์:
  # - Dashboard → https://sonarcloud.io/projects/...
  # - Screenshot ใส่ D4 ได้เลย
```

**Output ตัวอย่าง:**

```
SonarCloud Results:
─────────────────────────────────────────────
Code Quality Grade:    C (ต่ำ)
Technical Debt:        2 days
Coverage:             73%
Security Hotspots:    2 (ช่องโหว่)
Code Smells:          15
Bugs:                  1
Duplications:         8%
```

---

### 3.3 GitHub PR Code Review

**เป้าหมาย:** Code review ไม่ใช่แค่ style — ต้องดู quality ด้วย

**PR Code Review Checklist — Quality Perspective:**

```
## ด้าน Correctness (ความถูกต้อง)
  [ ] Logic ถูกต้องตาม requirements?
  [ ] Edge cases ถูกจัดการหมด?
  [ ] Error handling ครบถ้วน?
  [ ] ไม่มี off-by-one bugs?

## ด้าน Code Quality
  [ ] Cyclomatic Complexity ≤ 10?
  [ ] Functions มี single responsibility?
  [ ] ไม่มี dead code / unused variables?
  [ ] Naming ชัดเจน (ตัวแปร/ฟังก์ชัน)?

## ด้าน Testing
  [ ] มี unit tests สำหรับ logic ใหม่?
  [ ] Coverage ไม่ลดลง?
  [ ] Test cases cover edge cases?

## ด้าน Security
  [ ] Input validation ครบ?
  [ ] ไม่มี hardcoded secrets (password, API keys)?
  [ ] SQL injection risk?
```

**ตัวอย่าง: BAD review comment**

```
BAD:
"โค้ดนี้ผิด ทำใหม่หน่อย"

ปัญหา:
  - ไม่ระบุปัญหา
  - ไม่มีข้อเสนอแนะ
  - Developer เสียใจ
  - ไม่ constructive
```

**ตัวอย่าง: GOOD review comment**

````
GOOD:
"Line 8-15: Function `calculateDiscount()` มี CC = 12 แนะนำให้แยกเป็น 2 functions:
  1. `validateCustomer()` — CC = 2
  2. `applyDiscount()` — CC = 3

เหตุผล: CC สูง → ต้อง test 2^12 = 4096 paths ทั้งหมด!

ตัวอย่าง refactor:
  ```javascript
  function calculateDiscount(customer) {
    if (!validateCustomer(customer)) return 0;
    return applyDiscount(customer);
  }
````

อย่างไรก็ตาม แนวคิดของ discount logic ดี"

เหตุผล:

- ระบุปัญหา + บรรทัด
- อธิบาย เหตุผล
- เสนอวิธีแก้ + ตัวอย่าง
- ชมส่วนดี
- Constructive tone

```

---

## D4 — Quality & Security Report คืออะไร

**D4 ขอบเขต:** Weeks 11-13, Due week 13 (5 points = 5% ของ grade)

**D4 ประกอบด้วย 3 ส่วน:**

```

Week 11: Quality Report ← สัปดาห์นี้เริ่ม
Week 12: Security Assessment
Week 13: Performance Report
(งานทั้งหมด + final submission)

```

**D4 Quality Report ที่ต้องทำสัปดาห์นี้:**

```

ส่วนที่ 1: Metrics Summary

- Lines of Code (LOC)
- Code Coverage %
- Cyclomatic Complexity (avg)
- Defect Density (bugs/KLOC)

ส่วนที่ 2: Code Coverage Report

- Screenshot / table จาก Jest --coverage
- เปรียบเทียบกับ target (≥ 80%)

ส่วนที่ 3: Static Analysis Results

- ESLint: errors, warnings count
- SonarQube/SonarCloud: quality gate pass/fail

ส่วนที่ 4: Code Review Evidence

- Link ≥ 2 GitHub PR ที่มี review comments
- Summary ของ findings และการแก้ไข

ส่วนที่ 5: Quality Improvement Plan

- สิ่งที่แก้ไขแล้ว
- Action items สำหรับ weeks 12-13

```

**ทำไม D4 ต้องการตัวเลขจริง:**

```

เหตุผล:

- Proof: แสดงว่า project มี quality จริง
- Improvement: รู้ว่าต้องปรับปรุงตรงไหน
- Learning: นักศึกษา ได้เห็น real metrics
- Professional: เตรียมสำหรับสมัครงาน (resume)

เห็นชอบไม่ได้:

- แต่งตัวเลข: อาจารย์ตรวจ screenshot + GitHub history ได้

````

---

## Activity 1: วิเคราะห์ Metrics จาก Case Study (45 นาที)

**เป้าหมาย:** ฝึก apply metrics framework เข้า real (ไม่ใช่โปรเจกต์จริง แต่จำลองสม)

**ขนาดทีม:** 3-4 คน

**Case Study: FinTrack App** — personal finance tracking application

```javascript
// FinTrack: src/budget.js
// นักศึกษา: หา issues ในฟังก์ชันนี้

function calculateBudget(income, expenses, savingsGoal, taxRate, bonuses, debts) {
  // High CC function (nested if/else 6 ชั้น)
  let budget = 0;

  if (income > 0) {
    if (taxRate > 0) {
      let afterTax = income * (1 - taxRate);

      if (bonuses > 0) {
        afterTax += bonuses;
      }

      if (debts > 0) {
        if (afterTax > debts) {
          afterTax -= debts;
        } else {
          return null; // Not enough to pay debts
        }
      }

      budget = afterTax - expenses;

      if (budget > savingsGoal) {
        // Side effect: console.log
        console.log('Budget surplus: ' + (budget - savingsGoal));
      }
    }
  } else {
    return null;
  }

  return budget;
}
````

**Case Study Data:**

- LOC: 3,000 บรรทัดทั้ง project
- Reported Bugs: 12 issues
- Current Coverage: 58% (from Jest)
- ESLint Errors: 5 errors, 12 warnings

---

### ขั้นตอน Activity 1

**Step 1: คำนวณ Metrics (10 นาที)**

Nักศึกษาทำ:

```
1. คำนวณ CC ของ calculateBudget():
   นับจำนวน if/else/while/for → CC = ?

2. คำนวณ Defect Density:
   Bugs = 12, LOC = 3,000
   Defect Density = ?
   สถานะ: OK / Acceptable / Poor

3. ประเมิน Coverage 58%:
   ดี / ปานกลาง / ต่ำ
```

**Step 2: ระบุปัญหา (15 นาที)**

นักศึกษาเขียน:

```
1. Code Smells ใน calculateBudget() ≥ 3 จุด:
   - สมบูรณ์ (nested if/else = CC สูง)
   - (อื่น)

2. Refactor proposal:
   - แยก validateInput() function
   - แยก applyTax() function
   - แยก applyDebts() function
   → ทำให้ CC ลดเหลือ ~3 per function

3. Missing tests:
   - Test case: income = 0 (return null)
   - Test case: debts > afterTax (return null)
   - Test case: bonuses calculated correctly
   → Coverage อาจเพิ่มจาก 58% → 75%
```

**Step 3: กรอก Metrics Summary (10 นาที)**

นักศึกษาเติม table:

```
Metrics Summary — FinTrack Budget Module
────────────────────────────────────────────────
Metric                  | Measured | Target | Status
────────────────────────────────────────────────
Lines of Code (LOC)     | 3,000    | -      | ✓
Code Coverage (%)       | 58%      | ≥ 80%  | Low
CC (avg)                | 6.2      | ≤ 10   | ✓ OK
Defect Density/KLOC     | 4.0      | ≤ 1.0  | High
ESLint Errors           | 5        | 0      | Fail
────────────────────────────────────────────────

Action Items:
───────────────────────────────────────────────────
Item                    Owner      Due      Status
───────────────────────────────────────────────────
Refactor calculateBudget Dev1       Week 11  TODO
Add 5+ tests            Dev2       Week 11  TODO
Fix ESLint errors       Dev3       Week 11  TODO
───────────────────────────────────────────────────
```

**Step 4: นำเสนอ (10 นาที)**

แต่ละกลุ่ม 2 นาที:

- Metrics ที่คำนวณได้
- ปัญหาที่พบ
- Action items

---

**Deliverable:**

- Metrics worksheet (กระดาษ A4 หรือ Google Doc)
- Class Participation points

---

## Activity 2: Quality Report Workshop — เริ่มทำ D4 (45 นาที)

**เป้าหมาย:** นักศึกษาทำ D4 Quality Report draft ของ real project ตัวเอง

**เตรียมการ (5 นาที):**

```
  - เปิด GitHub repo ของโปรเจกต์
  - เปิด VS Code + terminal
  - ตรวจสอบ Jest && ESLint ติดตั้งแล้ว (from D3)
```

---

### ขั้นตอน Activity 2

**Step 1: รัน และวัด (15 นาที)**

นักศึกษาแต่ละคน run:

```bash
# 1. วัด Code Coverage
npx jest --coverage 2>&1 | tee coverage-report.txt

# 2. รัน ESLint
npx eslint src/ --format=stylish | tee eslint-report.txt

# 3. นับ LOC (เลือกวิธีหนึ่ง)
# วิธี A: VS Code - Select all (Ctrl+A) → bottom bar แสดง Lines
# วิธี B: Terminal
npx cloc src/

# 4. นับ bugs จาก GitHub Issues
# GitHub repo → Issues → Filter: label:bug
# นับจำนวน open + closed (ไม่นับ feature requests)
```

**ตัวอย่างผลลัพธ์:**

```
COVERAGE RESULT:
  Statements   : 73.45%
  Branches     : 68.50%
  Functions    : 80.00%
  Lines        : 73.20%

ESLint RESULT:
  5 errors, 12 warnings

LOC:
  JavaScript: 2,450 lines

BUGS (from GitHub Issues):
  Total: 8 bugs
```

**Step 2: กรอก Metrics Summary (15 นาที)**

นักศึกษา fill template:

```
Project Metrics Summary — [ชื่อโปรเจกต์]
วันที่วัด: _____________

Metric               | Measured | Target | Status | Notes
─────────────────────────────────────────────────────────
LOC (Source)         |  2,450   | -      | ✓      |
Code Coverage (%)    |   73.45  | ≥ 80%  | Low    | ต่ำกว่า target
CC (avg/max)         |  4.2 / 8 | ≤ 10   | ✓      |
ESLint Errors        |    5     | 0      |     | ต้องแก้ก่อน merge
ESLint Warnings      |   12     | -      | warn   |
Defect Density/KLOC  |   3.27   | ≤ 1.0  |     | สูง — review bugs
Open Issues (bugs)   |    3     | 0      | warn   |
Closed Issues (bugs) |    5     | -      | -      |
─────────────────────────────────────────────────────────
```

**Step 3: เขียน Action Items (10 นาที)**

นักศึกษาตั้ง 2-3 action items:

```
Action Items for Quality Improvement

ID  Problem               Root Cause           Solution              Owner    Due Date   Priority
─────────────────────────────────────────────────────────────────────────────────────────────────
1   Coverage 73% < 80%   Missing unit tests   Add tests for:        Dev1     May 18     High
                                             - utils/date.js
                                             - auth/middleware.js
                                             Target: +8% coverage

2   ESLint errors (5)    Config rules not    Run npx eslint --fix  Dev2     May 15     High
                        enforced in PR       Update CI gate

3   Defect Density 3.27  More bugs need      Create bug hotspot    Dev3     May 20     Medium
    (target ≤ 1.0)      review & testing    analysis → add tests
─────────────────────────────────────────────────────────────────────────────────────────────────
```

**Step 4: หา PR Review Evidence (5 นาที)**

นักศึกษาค้นหาใน GitHub:

```
PR Review Evidence:
─────────────────────────────────────────────
1. PR #23: Add user authentication
   Link: https://github.com/.../pull/23
   Review comment:
   "High CC in login() = 12. Recommend refactoring."
   Status: Fixed ✓

2. PR #25: Payment integration
   Link: https://github.com/.../pull/25
   Review comment:
   "Missing error handling for timeout cases"
   Status: In progress
─────────────────────────────────────────────
```

---

**Deliverable Checklist:**

```
D4 Quality Section — สัปดาห์ 11 Draft:

[ ] 1 pt  — Metrics Summary table (LOC, Coverage, CC, Defect Density)
[ ] 1 pt  — Coverage report (screenshot / table จาก Jest)
[ ] 0.5 pt — ESLint results (errors, warnings count)
[ ] 0.5 pt — Defect Density calculation ชัดเจน
[ ] 1 pt  — Action Items ≥ 2 ข้อ (ปัญหา/สาเหตุ/แผน/ผู้รับผิดชอบ)
[ ] 1 pt  — PR review links ≥ 2 + summary findings

Total: 5 points (เป็นส่วนของ D4 งานทั้งหมด)

หมายเหตุ: ส่วนนี้ draft แล้ว weeks 12-13 จะเพิ่ม Security + Performance sections
```

---

## สรุป

**บทเรียนหลักของสัปดาห์ที่ 11:**

**1. ตัวชี้วัดกระบวนการ — การวัดคุณภาพด้วยข้อมูลเชิงตัวเลข:**

- Lines of Code (LOC) — ขนาดโดยรวมของระบบ
- Cyclomatic Complexity — ความซับซ้อนของโครงสร้างการแตกแขนง
- Code Coverage — สัดส่วนของโค้ดที่ได้รับการทดสอบ
- Defect Density — ข้อบกพร่องต่อ 1,000 บรรทัด
  → ตัวชี้วัดเหล่านี้เป็นเครื่องมือช่วยให้ตรวจสอบปัญหา ตัดสินใจอย่างเป็นระบบ และติดตามความก้าวหน้า

**2. Quality Assurance และ Quality Control — ต้องดำเนินการทั้งสองอย่าง:**

- Quality Assurance = การป้องกันข้อบกพร่องตั้งแต่ข้างต้น (กระบวนการ)
- Quality Control = การตรวจเจอและจัดการข้อบกพร่อง (ผลผลิต)
  → QA มีประสิทธิภาพ → ข้อบกพร่องเกิดน้อย | QC มีประสิทธิภาพ → จับข้อบกพร่องทันเวลา

**3. เครื่องมือและกระบวนการ — การทำให้เป็นอัตโนมัติตามความเหมาะสม:**

- ESLint: ตรวจสอบรูปแบบและไวยากรณ์โดยอัตโนมัติ
- SonarQube: ตรวจเจอข้อบกพร่อง ช่องโหว่ และโค้ดซ้ำซ้อน
- Jest --coverage: วัดระดับการครอบคลุมการทดสอบ
- GitHub PR + Code Review: องค์ประกอบของมนุษย์สำหรับตรรมชาติการดำเนินการที่เครื่องมือไม่สามารถจัดการได้
  → เครื่องมือ + มนุษย์ = ระบบการควบคุมคุณภาพที่มีประสิทธิภาพและเชื่อถือได้

**Quality Stack Pipeline:**

```
Developer Writes Code
        ↓
   ESLint           (auto-fix syntax issues)
        ↓
   Jest Coverage    (check test coverage ≥ 80%)
        ↓
   SonarQube        (scan for bugs & vulnerabilities)
        ↓
   GitHub PR        (human review: logic, best practices)
        ↓
   CI Pipeline      (all checks green)
        ↓
   Merge to main    (code is clean & tested)
        ↓
   D4 Evidence      (screenshot metrics for quality report)
```

**สัปดาห์หน้า (Week 12):** Security in Development — OWASP Top 10, Secure Coding, Security Assessment (ต่อจาก Quality Report)

---

**กำหนดส่งสำหรับสัปดาห์นี้:**

| Task                            | Due                    | Value                         |
| ------------------------------- | ---------------------- | ----------------------------- |
| Activity 1: Case Study Analysis | During class (Week 11) | Class participation           |
| Activity 2: D4 Quality Draft    | During class (Week 11) | 5 points (D4 week 11 portion) |
| D4 Quality Report (Final)       | Week 13                | 5 points total (Weeks 11-13)  |