reveal.js

# สัปดาห์ที่ 1

บทนำและการป้องกันข้อบกพร่องของซอฟต์แวร์

---

## เป้าหมายการเรียนรู้

- เข้าใจความหมายของการเขียนโปรแกรมขั้นสูง
- อธิบายคุณภาพซอฟต์แวร์ในมุมมองนักพัฒนาได้
- เห็นจุดเสี่ยงของ Bug ใน SDLC
- ใช้แนวคิด Bug Prevention ก่อนส่งงาน

---

## โปรแกรมที่ดีไม่ใช่แค่รันได้

| รันได้เท่านั้น | มีคุณภาพ |
|---|---|
| แก้เฉพาะให้ผ่านโจทย์ | ออกแบบให้ดูแลต่อได้ |
| ไม่ตรวจ input | ตรวจข้อมูลก่อนใช้ |
| ฟังก์ชันยาวและปนหลายหน้าที่ | แยกหน้าที่ชัดเจน |
| ทดสอบด้วยการลองเอง | มี test case ตรวจซ้ำได้ |

---

## Software Quality

```mermaid
mindmap
  root((Software Quality))
    Correctness
    Reliability
    Maintainability
    Security
    Scalability
```

---

## SDLC

```mermaid
flowchart LR
  A[Requirement] --> B[Design]
  B --> C[Coding]
  C --> D[Testing]
  D --> E[Deployment]
  E --> F[Maintenance]
```

---

## จุดเสี่ยงของ Bug

| ขั้นตอน | จุดเสี่ยง |
|---|---|
| Requirement | เข้าใจโจทย์ผิด |
| Design | เลือกโครงสร้างข้อมูลผิด |
| Coding | Logic ผิด ไม่ตรวจ input |
| Testing | Test case ไม่ครอบคลุม |
| Maintenance | แก้แล้วกระทบส่วนเดิม |

---

## ประเภทของ Bug

- Syntax Error: เขียนผิดกฎภาษา
- Runtime Error: รันแล้วเกิดข้อผิดพลาด
- Logic Error: รันได้แต่ผลลัพธ์ผิด
- Requirement Error: ทำงานไม่ตรงความต้องการ

---

## ตัวอย่าง Logic Error

```cpp
int calculateDiscount(int price) {
    if (price > 1000) {
        return price * 0.05;
    }
    return 0;
}
```

ถ้า requirement คือ "ครบ 1,000 บาทขึ้นไป" เงื่อนไขควรเป็น `price >= 1000`

---

## Bug Prevention Pipeline

```mermaid
flowchart LR
  A[Requirement] --> B[Design]
  B --> C[Coding Standard]
  C --> D[Static Analysis]
  D --> E[Code Review]
  E --> F[Test Case]
  F --> G[Refactor]
```

---

## Coding Standard

- ตั้งชื่อให้สื่อความหมาย
- จัดรูปแบบโค้ดสม่ำเสมอ
- แยกฟังก์ชันตามหน้าที่
- เขียน comment เมื่อช่วยอธิบายเหตุผล
- ลดโค้ดซ้ำ

---

## Code Review

Code Review ช่วยตรวจสิ่งที่ผู้เขียนอาจมองข้าม

- Logic ตรง requirement หรือไม่
- Input validation ครบหรือไม่
- ฟังก์ชันซับซ้อนเกินไปหรือไม่
- มีผลกระทบกับส่วนอื่นหรือไม่

---

## Static Analysis

ตรวจโค้ดโดยไม่ต้องรันโปรแกรม

- Warning จาก compiler
- Unused variable
- Pattern ที่เสี่ยงต่อ null หรือ memory leak
- Style ที่ไม่ตรงมาตรฐาน

---

## Test Case Design

| ประเภท | ตัวอย่าง |
|---|---|
| Normal case | ข้อมูลถูกต้องทั่วไป |
| Edge case | ค่าขอบเขต เช่น 0, 1, 1000 |
| Invalid case | ข้อมูลว่าง ผิดชนิด เกินขอบเขต |

---

## Checklist ก่อนส่งงาน

- โปรแกรมตรงโจทย์ทุกเงื่อนไข
- ตรวจ input แล้ว
- ชื่อไฟล์ ตัวแปร ฟังก์ชันอ่านเข้าใจ
- ไม่มีฟังก์ชันที่ทำหลายหน้าที่เกินไป
- มี test case ครอบคลุม
- ผ่านการ review หรืออ่านทวนแล้ว

---

## Workshop

วิเคราะห์โค้ดที่มีข้อผิดพลาด

1. ระบุ Bug อย่างน้อย 5 จุด
2. จัดประเภทของ Bug
3. อธิบายสาเหตุและผลกระทบ
4. เสนอแนวทางป้องกัน
5. ปรับปรุงโค้ดโดยไม่เปลี่ยนผลลัพธ์ที่ต้องการ

---

## ชิ้นงาน

รายงานวิเคราะห์ Bug 1-2 หน้า

- ประเภทของ Bug
- สาเหตุและผลกระทบ
- แนวทางป้องกัน
- โค้ดก่อนและหลังปรับปรุง

---

## คำถามทบทวน

- Compiler ตรวจ Logic Error ได้หรือไม่
- ทำไม Bug ที่เกิดจาก Requirement จึงอันตราย
- Checklist ก่อนส่งงานควรมีอะไรบ้าง