COURSE 1145 204 SOPHOMORE PROJECT • WEEK 7 LECTURE DECK

Sprint 1 Development & Code Review

แนวทางการพัฒนา Core Modules ใน Sprint 1 ให้มีโครงสร้างสะอาดตามหลัก Clean Code และ SOLID พร้อมกระบวนการ Peer Code Review เวิร์กโฟลว์ Pull Request บน GitHub Projects และการแปลงข้อเสนอแนะจากอาจารย์ที่ปรึกษาเป็นหลักฐานการปรับปรุงที่วัดผลได้

เป้าหมายหลักสัปดาห์ที่ 7
Sprint 1 → PR Ready
Database + Auth + Core POS Logic
SLIDE 01 • WEEK 7 OVERVIEW

ทำไม "โค้ดที่รันผ่าน" จึงยังไม่พอสำหรับ Sprint 1

1145 204 Grocery POS
ประเด็นสำคัญประจำสัปดาห์: ในการพัฒนาโครงงานซอฟต์แวร์ระดับปี 2 เป้าหมายของ Sprint 1 ไม่ใช่เพียงการเขียนให้หน้าจอเปิดติด แต่คือการสร้างรากฐานสถาปัตยกรรมที่ทีมทุกคนอ่านเข้าใจ แก้ไขต่อได้ใน Sprint 2–3 และมีหลักฐานการทำงานบน Git ที่ตรวจสอบได้

5 หัวข้อหลักในสัปดาห์ที่ 7

ลำดับ หัวข้อการเรียนรู้ ผลลัพธ์ที่คาดหวังกับ Grocery POS
01 Core Module Development ออกแบบ Walking Skeleton ของฐานข้อมูล Auth และคลังสินค้า
02 Clean Code & SOLID แยกความรับผิดชอบ Controller / Service / Repository ลดโค้ดซ้ำซ้อน
03 Peer Code Review ตรวจหาจุดบกพร่อง Edge Case และความปลอดภัยก่อนรวมโค้ด
04 Pull Request Workflow ใช้ PR Template เชื่อม Issue และผ่าน CI Gate ก่อน Merge
05 Advisor Feedback Integration แปลงคำแนะนำอาจารย์เป็น Task พร้อมหลักฐาน Commit/PR ยืนยัน
SPRINT 1 MILESTONE
DB & Auth
วางโครงสร้างตาราง + สิทธิ์ผู้ใช้ ก่อนต่อยอดสู่ POS Screen
RUBRIC WEIGHT (ARCHITECTURE & CODE)
22–25 pts
ระดับดีเยี่ยม: Clean Code + Testing + Git Commit สม่ำเสมอ
สัดส่วนคะแนนรวมรายวิชา
Advisor 50% + Committee 50%

อาจารย์ที่ปรึกษาประเมินจากวินัยรายสัปดาห์ ประวัติ Git และคุณภาพ PR ระหว่าง Sprint

SLIDE 02 • CORE MODULE DEVELOPMENT

Walking Skeleton และสถาปัตยกรรมฐานข้อมูล Grocery POS

Sprint 1 Core

ตามแนวคิด User Story Mapping ทีมควรเริ่มจาก Walking Skeleton — ชุดโมดูลเล็กที่สุดที่ทำงานเชื่อมต่อกันได้ครบวงจร (Database → Backend API → Authentication → Core CRUD) แล้วจึงขยายสู่ Sprint 2 (หน้าจอคิดเงิน POS) และ Sprint 3 (แจ้งเตือนสต็อกใกล้หมด)

คลิกเลือกตารางเพื่อดูรายละเอียดโมดูลและสปรินต์ที่รับผิดชอบ
SLIDE 03 • SPRINT EXECUTION & KANBAN

การแตก User Story เป็น Task และวินัยบน GitHub Board

Scrum + Kanban
ตัวอย่าง User Story ของ Grocery POS (Sprint 1): “ในบทบาทของผู้จัดการร้าน (Store Manager) ฉันต้องการเพิ่มและปรับยอดสินค้าคงคลังพร้อมกำหนดจุดสั่งซื้อซ้ำ (Reorder Level) เพื่อให้ระบบแจ้งเตือนก่อนสินค้าหมดชั้นวาง”
กฎการแตก Task (Scrum Guide): แตก User Story ออกเป็น Subtasks ขนาดไม่เกิน 1 วัน เพื่อติดตามความคืบหน้าได้จริงใน Daily Scrum และเปิด PR ได้เร็ว
ESTIMATION & PRIORITY
ใช้โมเดล MoSCoW จัดลำดับ: Must Have (Auth, DB, Product CRUD) ลง Sprint 1 ส่วนงานรองเก็บไว้ใน Icebox
กระดานจำลอง Sprint 1: กดปุ่มย้ายการ์ดงานเพื่อดูเงื่อนไขแต่ละสถานะ (Definition of Done)
คลิกปุ่มลูกศรบนการ์ดงานเพื่อจำลองการเลื่อนสถานะจาก Todo → In Progress → Awaiting Review → Done
SLIDE 04 • CLEAN CODE & SOLID PRINCIPLES

Don't Let the Sun Set on Bad Code: Refactoring ด้วย SOLID

Clean Architecture
SRP • SINGLE RESPONSIBILITY

1 คลาส 1 เหตุผลที่ต้องเปลี่ยน

แยก PriceCalculator (คำนวณราคารวม/ภาษี) ออกจาก InventoryRepository (คิวรีฐานข้อมูล) และ ReceiptFormatter

OCP • OPEN/CLOSED

ขยายได้โดยไม่แก้โค้ดเดิม

เพิ่มโปรโมชันสมาชิกหรือส่วนลดตามฤดูกาลผ่าน Strategy Interface โดยไม่ต้องแก้เงื่อนไข if-else ยาวในคลาสคิดเงิน

ISP & LSP • INTERFACE DISCIPLINE

แยกสิทธิ์และสัญญาให้ชัด

แคชเชียร์เรียกใช้เฉพาะเมธอดขายผ่าน IPosCheckout ไม่ถูกบังคับพึ่งเมธอดจัดการคลังของผู้ดูแลระบบ

DIP & DRY • DECOUPLING

พึ่ง Abstraction ไม่ผูก DB ตรง

Service ระดับสูงพึ่ง IStockStore ทำให้สลับ MySQL/PostgreSQL หรือใช้ Mock ทดสอบ Unit Test ได้ทันที 


          

        

      


      
      

        

          

            
SLIDE 05 • SPRINT 1 SECURITY & RELIABILITY

            
จุดเสี่ยงทางเทคนิค ของระบบ Grocery POS ใน Sprint 1

          

          

            Risk Mitigation
          

        


        

          

            
4 ข้อบังคับด้านความปลอดภัยและข้อมูล

            

              
                

                  หัวข้อ
                  ความเสี่ยงที่พบประจำ
                  วิธีป้องกันใน Sprint 1
                

              
              
                

                  Authentication
                  เก็บรหัสผ่าน Plaintext หรือส่ง password_hash กลับใน API
                  ใช้ bcrypt/argon2 และตัดฟิลด์ลับออกใน DTO response
                

                

                  Authorization
                  เช็กสิทธิ์แค่หน้า UI แต่ไม่ตรวจ role_enum บน API
                  บังคับ Role Middleware ทุก Endpoint (Cashier vs Manager)
                

                

                  SQL Injection
                  ต่อสตริง SQL ด้วย + เมื่อค้นหาบาร์โค้ดสินค้า
                  ใช้ Parameterized Query / ORM Prepared Statements เท่านั้น
                

                

                  Concurrency
                  ตัดสต็อกพร้อมกัน 2 เครื่องจนสินค้าเหลือติดลบ
                  ใช้ DB Transaction + Atomic Update (WHERE stock_qty >= qty)
                

              
            

          


          

            

              Serendipitous Decoupling (พลังของ Unit Testing):
              การเขียน Test ก่อนหรือเขียนคู่กับการพัฒนาโมดูล จะบังคับให้นักศึกษาแยกการคำนวณราคาและการตรวจสอบสต็อกออกจากฐานข้อมูลจริง ทำให้โครงสร้างโค้ดสะอาดขึ้นโดยอัตโนมัติ
            

            

              
ACCEPTANCE TEST RULE (XP)

              

                “เมื่อ Acceptance Test ของ User Story ใดผ่านแล้ว ให้บันทึกเป็นชุดทดสอบอัตโนมัติประจำระบบ และห้ามปล่อยให้พังซ้ำใน Commit ถัดไป”
              

            

            

              
EDGE CASES ที่ต้องมี TEST เสมอ

              
    
                
  • จำนวนสินค้าเป็น 0 หรือติดลบ (qty <= 0)
    • 
                
  • บาร์โค้ดซ้ำ / ไม่พบสินค้าในคลัง
    • 
                
  • การปัดเศษทศนิยมเงินตรา (หลีกเลี่ยง floating-point drift)
    • 
              

            

          

        

      


      
      

        

          

            
SLIDE 06 • PEER CODE REVIEW GUIDELINES

            
Collective Code Ownership: ศิลปะการตรวจโค้ดเพื่อนร่วมทีม

          

          

            Interactive Lab
          

        


        

          

            [Blocker] ต้องแก้ไขก่อน Merge
            
ช่องโหว่ความปลอดภัย, Bug คำนวณเงิน/สต็อกผิด, ไม่มี Test หรือ CI ไม่ผ่าน

          

          

            [Suggestion] ข้อเสนอแนะเชิงออกแบบ
            
จุดที่ผิด SRP, ชื่อตัวแปรคลุมเครือ, หรือควรแยกฟังก์ชันเพื่ออ่านง่ายขึ้น

          

          

            [Nit / Praise] รายละเอียดย่อยและคำชม
            
การจัดรูปแบบเล็กน้อย (ไม่ขวางการ Merge) และชื่นชมเทคนิคที่ดีของเพื่อน

          

        


        

          

            

              
แบบฝึกหัดในชั้นเรียน: คลิกเลือกบรรทัดที่มีจุดบกพร่องในฟังก์ชัน Sprint 1 (มี 4 จุด)

              

                
                
              

            

            

              
            

          


          

            
REVIEWER BENCHMARK

            
คำแนะนำการรีวิว

            

              ลองสวมบทบาทเป็น Peer Reviewer ของทีม เลือกบรรทัดที่มีความเสี่ยงด้านความปลอดภัย Clean Code หรือ Edge Case แล้วกด ตรวจคำตอบ
            

          

        

      


      
      

        

          

            
SLIDE 07 • PULL REQUEST WORKFLOW & CI

            
6 ขั้นตอน Pull Request จาก Branch สู่ Main อย่างปลอดภัย

          

          

            GitHub Projects
          

        


        

          

            
วงจรมาตรฐานของ 1 Pull Request

            

              
                

                  ขั้น
                  กิจกรรม
                  เครื่องมือบน GitHub
                

              
              
                

                  01
                  แตก Branch จาก main ตาม Task
                  feat/auth-login, fix/stock-lock
                

                

                  02
                  Commit ย่อยพร้อมข้อความชัดเจน + เขียน Test
                  Git commit history
                

                

                  03
                  เปิด PR ด้วย Template และผูก Issue
                  ?template=feature_pr_template.md
                

                

                  04
                  ตั้ง Reviewers & ย้ายการ์ดไป Awaiting Review
                  Sidebar: Development + Reviewers
                

                

                  05
                  ผ่าน CI (Build + Test + Lint) และ Peer Approve
                  GitHub Actions / Review Comments
                

                

                  06
                  Merge PR และปิด Issue อัตโนมัติ → Done
                  github-project-automation
                

              
            

          


          

            
ตัวจำลอง PR Gate Checker

            

              ตรวจสอบความพร้อมก่อนกด Merge PR ของทีมในสัปดาห์ที่ 7:
            

            

              
              
              
              
            

            

              สถานะ PR: รอการตรวจสอบ (0 / 4 เงื่อนไข)
            

          

        

      


      
      

        

          

            
SLIDE 08 • ADVISOR FEEDBACK INTEGRATION

            
เปลี่ยนคำแนะนำอาจารย์ที่ปรึกษา เป็น Actionable Backlog

          

          

            PDCA + QA Loop
          

        


        

          

            
1. MIRRORING & ACKNOWLEDGING

            

              ทวนความเข้าใจข้อเสนอแนะของอาจารย์ด้วยคำพูดของทีม (หลักการสัมภาษณ์ AUN-QA) เพื่อยืนยันว่าเข้าใจปัญหาตรงกันก่อนแก้ไข
            

          

          

            
2. CONVERT TO GITHUB ISSUE

            

              แตกความเห็นเป็น Issue พร้อมติด Label (advisor-feedback, refactor, bug) และกำหนด Assignee
            

          

          

            
3. EVIDENCE-BASED CLOSURE

            

              ปิดงานด้วยหลักฐานจริง: ลิงก์ PR ที่แก้แล้ว ผลการรัน Test และเดโมในคาบถัดไป (ตอบโจทย์ PDCA Check → Act)
            

          

        


        

          

            
LOG ADVISOR FEEDBACK

            
บันทึกข้อเสนอแนะเข้าสู่ Sprint Backlog

            

              

                
                
              

              

                

                  
                  
                

                

                  
                  
                

              

              

                
                
              

              

                
              

              

            

          


          

            

              
รายการติดตามผล Advisor Feedback (บันทึกอัตโนมัติ)

              0 รายการ
            

            

              

                
                  

                    ประเด็น
                    ประเภท
                    ผู้รับผิดชอบ / หลักฐาน
                    สถานะ
                  

                
                
                  
                
              

            

          

        

      


      
      

        

          

            
SLIDE 09 • ASSESSMENT RUBRIC & SELF-AUDIT

            
เชื่อมโยงงาน Sprint 1 กับเกณฑ์ประเมินสถาปัตยกรรมและโค้ด (25 คะแนน)

          

          

            Rubric 25 pts
          

        


        

          

            
เกณฑ์ประเมินคุณภาพซอฟต์แวร์และสถาปัตยกรรม

            

              
                

                  ระดับคะแนน
                  เกณฑ์พิจารณาหลัก
                

              
              
                

                  ดีเยี่ยม (22–25)
                  ออกแบบ Architecture, API, DB Schema ถูกต้องตามหลักวิศวกรรม เขียนโค้ดตาม Clean Code มี Unit/Integration Test ครอบคลุม และมี Git Commit สม่ำเสมอ
                

                

                  ดี (18–21)
                  โครงสร้างสถาปัตยกรรมและฐานข้อมูลถูกต้อง เชื่อมต่อ Front/Back ได้ดี โค้ดอ่านง่าย ผ่านการทดสอบในฟังก์ชันหลัก
                

                

                  พอใช้ (14–17)
                  สถาปัตยกรรมมีข้อผิดพลาดบางจุด โครงสร้างโค้ดขาดความเป็นระเบียบ หรือผลการทดสอบไม่ครอบคลุม
                

                

                  ปรับปรุง (0–13)
                  โครงสร้างไม่ถูกต้อง ไม่ตรงหลักวิศวกรรม ไม่มีเอกสาร/ผลการทดสอบ หรือไม่มีประวัติการทำงานบน Git
                

              
            

          


          

            

              

                
TEAM SELF-AUDIT (WEEK 7)

                
ตรวจสุขภาพโค้ดของทีมก่อนจบสัปดาห์ที่ 7

              

              
0 / 25

            


            

              
              
              
              
              
            


            

              ระดับปัจจุบัน: ปรับปรุง (0–13 คะแนน) — เริ่มเช็กรายการที่ทีมทำสำเร็จแล้ว
            

          

        

      


      
      

        

          

            
SLIDE 10 • WRAP-UP & ACTION PLAN

            
5 ภารกิจก่อนเข้า Sprint 2 และส่งออกบันทึกความก้าวหน้า

          

          

            Ready for Sprint 2
          

        


        

          

            
Checklist สิ่งที่ต้องทำให้เสร็จภายในสัปดาห์นี้

            

              
                

                  ข้อ
                  งานที่ต้องส่งมอบ
                  หลักฐานบน GitHub / รายงาน
                

              
              
                

                  01
                  Freeze โครงสร้าง DB Schema (Users, Products, Inventory)
                  ไฟล์ SQL Migration + ER Diagram ใน Repo
                

                

                  02
                  ตั้งค่า .github/PULL_REQUEST_TEMPLATE/
                  ไฟล์ feature_pr_template.md และ bugfix_pr_template.md
                

                

                  03
                  ทุก Task ต้องผ่าน Peer Review อย่างน้อย 1 Approve
                  PR History ที่มี Review Comment จริง
                

                

                  04
                  รัน Automated Test ผ่านกรณี Edge Case หลักของ Auth & Stock
                  ผล Test Log / CI Badge สีเขียว
                

                

                  05
                  บันทึก Advisor Feedback Log และเตรียมเดโมหน้าจอขาย Sprint 2
                  ตาราง Advisor Feedback + Sprint 1 Retrospective
                

              
            

          


          

            

              
EXPORT WORKSPACE DATA

              
ส่งออกสรุปผลประจำสัปดาห์

              

                ดาวน์โหลดผล Self-Audit และ Advisor Feedback Log ของกลุ่มเป็นไฟล์ CSV เพื่อนำไปแนบในรายงานสัปดาห์ที่ 7
              

              

                
                
              

              

            


            

              
SOURCE ATTRIBUTION

              

                เรียบเรียงจากเอกสารประกอบรายวิชา 1145 204 Sophomore Project (POS Student Deliverables & Rubric), Agile Principles, Patterns, and Practices in C#, Lean Software Development, The Scrum Guide, Using GitHub Projects for Agile (McMaster Research Software), และแนวทางประกันคุณภาพ AUN-QA