ที่มาของระบบต้อนรับนักศึกษาใหม่ มข.

ผมทำระบบต้อนรับนักศึกษาใหม่ของมหาวิทยาลัยขอนแก่นมา สี่ครั้ง — ปีละครั้งตั้งแต่รุ่น KKU60 ถึง KKU63 และไม่มีสักครั้งที่เริ่มจากผมเป็นคนเสนอตัวเอง

ไม่มีใครจ้างให้ทำ มีแต่คนชวนให้ช่วย

ครั้งแรกมาจากรุ่นพี่ที่รู้จักกันตอนเป็นอนุกรรมการองค์การนักศึกษา ครั้งต่อมาเป็นน้องที่เจอกันในค่าย แล้ววันหนึ่งน้องคนนั้นเข้าองค์การนักศึกษาเองและกลับมาชวน หลังจากนั้นมันก็กลายเป็นสิ่งที่ผมทำทุกปีไปโดยปริยาย

ทั้งสี่ครั้งเริ่มจากมีคนมาชวน ไม่ใช่จากผมเดินไปเสนอ

เหตุผลที่รับทุกครั้งธรรมดากว่าที่คิด — ตอนเข้ามาเรียนผมเห็นว่าเว็บและระบบของมหาวิทยาลัยยัง ล้าสมัย และอยากเป็นแรงหนึ่งที่ช่วยขับเคลื่อนให้ดีขึ้น งานอาสาระบบรับน้องคือจุดที่เริ่มได้ใกล้ตัวที่สุด

สี่รุ่น เขียนใหม่สี่รอบ

แต่ละปีเป็น repository ใหม่ ไม่ใช่ของปีก่อนที่เปลี่ยนแค่เลข commit แรกของทุกปีตกอยู่ราวเดือนพฤษภาคม–มิถุนายน เพราะกำหนดส่งคือวันรับน้อง และวันนั้นเลื่อนไม่ได้

1. KKU60 · 2023 — วิซาร์ด 5 ขั้น กรอกข้อมูล เลือกกิจกรรม ยืนยัน แล้วโหลด e-ticket ใช้ Chakra UI, Formik + Yup, Redux Toolkit
2. KKU61 · 2024 — ย้ายหน้าตาไป MUI และย้ายโค้ดเข้าโฟลเดอร์ตามฟีเจอร์ เหลือสองงานหลักคือสะสมแต้มกับลงทะเบียนกิจกรรม
3. KKU62 · 2025 — เน้นมือถือเป็นหลัก และเป็นปีแรกที่มีฝั่งสตาฟจริง ๆ ทั้งเช็กอิน จัดกลุ่ม และรายงานแยกตามอาหาร สุขภาพ คณะ ชมรม
4. KKU63 · 2026 — สองภาษา ล็อกอินผ่านระบบบัญชีของมหาวิทยาลัยโดยตรง และแยกเป็นสิบหกโดเมนย่อยในแอปเดียว

ดูเป็นตัวเลข

ที่กระโดดจาก 2025 ไป 2026 ไม่ใช่เพราะอยากทำให้ใหญ่ แต่เป็นปีที่แอปเลิกเป็นฟอร์มลงทะเบียนที่แปะฟีเจอร์เพิ่ม แล้วกลายเป็นหลายฟีเจอร์ที่บังเอิญใช้ล็อกอินเดียวกัน

Stack เปลี่ยนเกือบทุกปี

มีแค่สองอย่างที่อยู่ครบทั้งสี่ปี — Next.js กับ Firebase นอกนั้นถูกเปลี่ยนอย่างน้อยหนึ่งครั้ง

• ฟอร์ม — Formik + Yup (2023) → แทบไม่ใช้อะไร (2024) → React Hook Form + Zod (2025 เป็นต้นมา) ข้อดีของ Zod คือใช้ schema ตัวเดียวกันทั้งตอนตรวจฟอร์มและตอนเขียนลงฐานข้อมูล
• UI — Chakra UI (2023) → MUI (2024 เป็นต้นมา) และใช้ MUI X สำหรับตารางกับกราฟที่ฝั่งสตาฟต้องใช้
• State — Redux Toolkit (2023–24) → เลิกใช้ พอถึงปี 2025 แทบทุกอย่างเป็น server state และปี 2026 ใช้ TanStack Query ทำงานนั้นแทนโดยไม่ต้องมี store

โครงโฟลเดอร์ก็เปลี่ยนตาม

2023  src/{components,hooks,redux,services,styles}
2024  src/features/{collect-points,events-registration} + src/shared
2025  src/modules/{freshmen,participant,staff} + src/shared
2026  src/app/[locale] + src/app/api + src/modules/core/{...16}

เป็นการเปลี่ยนชื่อความคิดเดิมสามรอบ แต่ละรอบผิดน้อยลงหน่อย features/ ดีกว่า components/ แบบแบน ๆ และ modules/ ดีกว่า features/ ตอนที่โมดูลหนึ่งเริ่มต้องมี model, schema และ hook ของตัวเอง ไม่ใช่แค่หน้าจอ

ปี 2026 ทำอะไรบ้าง

ตัวปัจจุบันให้นักศึกษาล็อกอินผ่านระบบบัญชีของมหาวิทยาลัยเลย แทนที่จะให้ตั้งรหัสผ่านใหม่อีกชุด:

/api/auth/kku/login      → ส่งต่อไปหน้าล็อกอินของมหาวิทยาลัย
/api/auth/kku/callback   → กลับมาแล้วออก session
/api/auth/session        → ตรวจว่าใครล็อกอินอยู่ ฝั่งเซิร์ฟเวอร์
/api/recaptcha/verify    → กันบอทตอนลงทะเบียน

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

หน้าตาเป็นแบบนี้

นักศึกษาส่วนใหญ่เปิดจากมือถือ ไม่ใช่โน้ตบุ๊ก เลย์เอาต์บนมือถือจึงเป็นตัวที่ออกแบบก่อนและทดสอบหนักที่สุด และปี 2025 คือปีที่เรื่องนี้เลิกเป็นของแถม

สี่ปีนี้สอนอะไร

ส่วนที่ยากไม่เคยเป็นโจทย์ที่ ยาก แต่เป็นการกลับไปอ่านโค้ด — ส่วนใหญ่คือโค้ดของตัวเองเมื่อปีก่อน — แล้วพบว่าคอนเวนชันที่เขียนไว้ในเอกสารไม่ได้ถูกใช้จริง นั่นคือเหตุผลส่วนใหญ่ที่ทำให้ทุกวันนี้ผมให้ค่ากับเรื่องน่าเบื่ออย่างการตั้งชื่อ การ รีวิวโค้ด และการเขียนบันทึกว่า ทำไม มากกว่า ทำอะไร

และเป็นเหตุผลที่ปี 2026 เป็นปีแรกที่มีเทสต์ และมีเอกสารอธิบายโครงโค้ดวางไว้ข้าง ๆ โค้ดในชื่อ AGENTS.md

รายละเอียดของแต่ละปีอยู่ใน หน้าโปรเจกต์ ครับ