สร้าง frontend systems ที่ยังอ่านง่ายและดูแลง่ายหลังขึ้นใช้งานจริง

Architecture จะเห็นชัดที่สุดหลังระบบเปิดใช้จริง

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

ผมเจอสถานการณ์นี้จากการดูแล React และ Next.js ในงาน production หลายแบบ ทั้งระบบแนว exchange, AI SaaS, e-commerce และแพลตฟอร์มเรียนออนไลน์ หน้าจอแตกต่างกันมาก ตั้งแต่ wallet, withdrawal, chatbot configuration, checkout ไปจนถึง HLS player แต่ปัญหาหลังบ้านคล้ายกันเสมอ ถ้าขอบเขตไม่ชัด state จะถูกเก็บซ้ำ API detail จะกระจายเข้า component และ error ที่ผู้ใช้เจอจะตามหาได้ยากในฝั่งทีมพัฒนา

เป้าหมายของผมจึงไม่ใช่ “clean code” ในเชิงรูปแบบ แต่เป็นระบบที่ยังอธิบายได้ตอนมีแรงกดดันจริง เช่น backend เปลี่ยน contract, payment ค้าง, SSE หลุด หรือมีคนใหม่ต้องเพิ่มฟีเจอร์โดยไม่ต้องไล่อ่านทั้ง repository ก่อน

แบ่งระบบตามความสามารถของโปรดักต์

โครงสร้างที่ดีควรใช้ภาษาชุดเดียวกับโปรดักต์ ในระบบ financial ผมมอง wallet, deposit, withdrawal, convert และ kyc เป็น boundary ที่มีความหมายกว่าโฟลเดอร์รวม hooks, modals และ services ทั้งหมด ส่วนแพลตฟอร์มเรียนออนไลน์อาจแบ่งเป็น player, course-progress, live-class และ assessment เพราะ design, backend และ product เข้าใจคำเหล่านี้ร่วมกันได้

หนึ่ง feature ควรดูแล route-level UI, component เฉพาะงาน, query, mutation, schema และ test ของตัวเอง ส่วน button, dialog, form field และ layout primitive ที่ไม่รู้จัก business rule จึงค่อยอยู่ใน shared UI ขณะที่ authentication, HTTP transport, analytics และ localization เป็น platform concern ทิศทาง dependency ควรอ่านง่าย: feature เรียกใช้ platform หรือ shared layer ได้ แต่ shared component ไม่ควรย้อนกลับไป import กฎของ feature

ตัวอย่างที่พบบ่อยคือ modal ที่เริ่มจากตั้งใจให้ reusable แต่ภายหลังรู้ทั้ง withdrawal limit, สิทธิ์เข้าเรียน และเงื่อนไขโปรโมชั่น เมื่อเป็นแบบนั้นมันไม่ใช่ shared component แล้ว แต่เป็น business module ที่ซ่อนอยู่ ทางแก้คือเก็บเฉพาะ dialog shell ไว้กลางระบบ แล้วนำ decision กลับไปอยู่กับ feature เจ้าของเรื่อง

State แต่ละชนิดควรมีเจ้าของเพียงแห่งเดียว

ความซับซ้อนมักเกิดเมื่อข้อเท็จจริงเดียวกันอยู่หลาย store ผมแยก state ตามที่มาและอายุการใช้งานดังนี้

• Server state มาจาก API และ cache ผ่าน data-fetching layer เช่น React Query
• URL state คือสิ่งที่ควรแชร์ลิงก์หรืออยู่ต่อหลัง refresh เช่น filter, tab และ pagination
• Form state คือ draft ที่ผู้ใช้กำลังแก้ มี validation และ submission lifecycle
• Ephemeral UI state เช่น dialog ที่เปิดอยู่ แถวที่ขยาย หรือ selection ชั่วคราว
• Session state เก็บ authenticated-user context เท่าที่จำเป็นระหว่าง route

ใน AI console ข้อมูล workflow และ knowledge source ควรอยู่ใน query cache ส่วน node configuration ที่ยังไม่กดบันทึกเป็น state ของ editor เมื่อมี execution event จาก SSE ก็อัปเดต cache ชุดเดิม ไม่สร้าง global store อีกชุดที่ค่อยตาม sync กันภายหลัง สำหรับ video player ค่า playback position เปลี่ยนถี่จึงควรตอบสนองใน local state แล้ว persist resume progress เป็น checkpoint ไม่ใช่ยิงทุก timeupdate เข้า server state

Redux, Zustand, Context และ React Query มีจุดเหมาะสมต่างกัน คำถามสำคัญไม่ใช่ว่าจะเลือกตัวไหนเป็นมาตรฐานเดียว แต่คือทีมตอบได้หรือไม่ว่า value นี้มี source of truth อยู่ที่ไหน และ event ใดมีสิทธิ์เปลี่ยนมัน

ให้ API contract หยุดอยู่ที่ boundary

Component ไม่ควรเพิ่งค้นพบรูปแบบ response ระหว่าง render ผมวาง transport และ normalization หลัง typed client แล้วให้ feature ใช้งานผ่าน query/mutation hooks รายละเอียดอย่าง header, token refresh, response envelope และการแปลง error ไม่ควรกระจายอยู่ใน page component

ลองดู withdrawal flow หนึ่งหน้าจออาจต้องรู้ eligibility, balance, destination validation, fee, OTP state และผลยืนยันสุดท้าย ข้อมูลเหล่านี้ควรมี request/response type ชัดเจน ถ้าเป็นข้อมูลภายนอกที่เปลี่ยนได้ง่ายก็ควร validate ที่ boundary แล้ว map backend error ให้เหลือ UI outcome ที่ผู้ใช้เข้าใจ เช่น 401 ไปสู่ session recovery, pre-check ไม่ผ่านต้องบอกสิ่งที่ต้องแก้ และ unknown error ต้องไม่ล้าง draft พร้อมเปิดทางให้ retry อย่างปลอดภัย

หลัง mutation สำเร็จ การ invalidate wallet balance และ transaction history ตรง ๆ อ่านง่ายกว่าการไล่แก้ state หลายหน้าจอ Optimistic update เหมาะเมื่อ rollback เชื่อถือได้เท่านั้น ผมจะไม่แสดงว่าธุรกรรมทางการเงินหรือ payment สำเร็จก่อน server ยืนยันเพียงเพื่อให้ UI ดูเร็ว

หลักเดียวกันช่วยระบบสองภาษาได้ดี identifier และ status enum จาก backend ควรเป็นกลาง ส่วนคำแปลเกิดที่ presentation edge วิธีนี้ทำให้ business data ไม่ปนกับ label ภาษาไทยหรืออังกฤษ และลดความคลาดเคลื่อนระหว่าง locale

Observability ต้องตาม user journey ได้

การมองเห็นปัญหาใน production ควรเริ่มจาก event ที่บอกว่าผู้ใช้พยายามทำอะไร ไม่ใช่ console.log กระจัดกระจาย สำหรับ checkout อาจติดตาม checkout_started, payment_submitted, payment_confirmed และ payment_failed ส่วน streaming ควรเห็น manifest load, playback start, buffering, recovery และ fatal player error สำหรับ AI workflow ค่าอย่าง connection status, execution ID, terminal state และจำนวน reconnect มีประโยชน์กว่าการ dump SSE payload ทุกก้อน

Telemetry ควรมี context พอเชื่อม frontend กับ backend เช่น request หรือ execution ID, route, feature, release version และ error category ที่ sanitize แล้ว แต่ต้องไม่เก็บ access token, OTP, private prompt, รายละเอียด wallet หรือ request body ทั้งชุด Validation error ที่คาดหมายได้ควรถูกแยกจาก defect เพื่อไม่ให้ alert สะท้อนความผิดพลาดของผู้ใช้เหมือนระบบล่ม

UI เองก็เป็นส่วนหนึ่งของ observability ต้องออกแบบ loading, empty, partial, stale, unauthorized และ failed state ให้ครบ ถ้า real-time connection หลุด หน้าจอควรบอกว่าข้อมูลอาจไม่ล่าสุด จากนั้น reconnect แบบมีขอบเขตหรือให้ผู้ใช้ refresh ได้ การที่ deployment health check เป็นสีเขียวไม่ได้พิสูจน์ว่า KYC จบ flow, วิดีโอ resume ถูกตำแหน่ง หรือ chatbot configuration บันทึกได้จริง

Test สิ่งที่ระบบตัดสินใจ ไม่ยึดติด implementation

ผมใช้ test หลายชั้น Pure function เหมาะกับ calculation, normalization, permission, query-key construction และ state transition ส่วน component test ตรวจ decision ที่ผู้ใช้เห็น เช่น เมื่อถอนเงินไม่ได้ action ต้องถูก block, mutation ล้มเหลวแล้ว form ต้องยังอยู่ หรือ media error แล้ว player มีทาง recover Integration test ครอบหนึ่ง feature กับ controlled API response และ browser suite จำนวนไม่มากป้องกัน journey สำคัญผ่าน routing กับ authentication จริง

Regression test ที่คุ้มค่ามักมาจาก production incident ถ้า token refresh เคยทำให้ parallel requests วนซ้ำ ก็ควรมี concurrency test ที่ HTTP client ถ้า SSE reconnect แล้ว event ซ้ำ ให้ test identity และ cleanup ถ้าสลับภาษาแล้ว nested route หาย ให้ test route transformation แทนการเพิ่ม snapshot โดยไม่รู้ว่าปกป้องอะไร

Shared UI ควรมี interaction contract ด้วย เช่น ปิด dialog แล้ว focus กลับตำแหน่งเดิม ใช้ keyboard ได้ action ที่ disabled อธิบายเหตุผล และ responsive layout ยังทำงานหลักได้ Visual regression มีประโยชน์กับ player หรือ dashboard ที่ซับซ้อน แต่ไม่ทดแทน assertion ด้าน behavior

Handoff คือส่วนหนึ่งของการส่งมอบ

ระบบที่ดูแลง่ายไม่ควรพึ่งคนเดียวจำ constraint ทุกอย่าง ประเด็นนี้สำคัญมากเมื่อทำหน้าที่ frontend engineer เพียงคนเดียวและต้องประสานกับ design, backend และ product โดยตรง ผมจึงเก็บข้อมูลส่งต่องานไว้ใกล้โค้ด ได้แก่ architecture note สั้น ๆ, ตัวอย่าง API, environment requirement, คำสั่ง quality gate และ operational edge ที่ทีมควรรู้

เอกสาร handoff ที่ใช้ได้จริงควรตอบคำถามเหล่านี้

1. Feature เริ่มจากจุดไหน และ module ใดเป็นเจ้าของ
2. API state กับ permission rule มีอะไรบ้าง
3. จะรันและทดสอบในเครื่องโดยไม่ใช้ production secret ได้อย่างไร
4. Dashboard, log หรือ identifier ใดใช้สืบปัญหา
5. สิ่งใดยังไม่รองรับหรือจงใจเลื่อนไปก่อน

Decision record ควรอธิบาย trade-off มากกว่าบอกชื่อเครื่องมือ “ใช้ React Query” ให้ข้อมูลน้อยกว่า “workflow data ที่ server เป็นเจ้าของอยู่ใน React Query เพื่อให้ SSE และ mutation อัปเดต cache เดียว ส่วน editor draft ที่ยังไม่ save อยู่ local” ประโยคหลังช่วยให้คนทำต่อประเมินได้ว่าการเปลี่ยนใหม่ยังเข้ากับ boundary เดิมหรือไม่

งานหลัง launch ต้องอยู่ในแผน

Maintenance ไม่ควรถูกมองว่าเป็นงานแทรก ผมติดตาม error pattern และ feedback, ลบ feature flag ชั่วคราว, ทบทวน dependency และกลับไปจัด boundary ที่เริ่มมี exception มากเกินไป การแก้แต่ละครั้งปลอดภัยขึ้นเมื่อ release มี scope แคบ มี rollback path และมีวิธี verify ที่ผูกกับ journey ซึ่งได้รับผลกระทบ

ผมแยก compatibility work ออกจาก feature work ด้วย เมื่อ API เปลี่ยน สามารถวาง adapter รองรับ shape เก่าและใหม่ชั่วคราว พร้อม telemetry ว่ายังมีใครเรียกเส้นทางเก่าหรือไม่ เมื่อ migration จบให้ลบ adapter และ test ของมัน “ของชั่วคราว” ที่อยู่ถาวรเป็นหนึ่งในต้นเหตุสำคัญของ frontend ที่อ่านไม่รู้เรื่อง

มาตรฐานที่ผมต้องการไม่ซับซ้อน นักพัฒนาควร trace ได้จาก route ไป feature จาก feature ไป typed contract และจาก user action ไป observable outcome ต้องรู้ว่า state อยู่ที่ไหน test ใดปกป้อง behavior และจะกู้สถานการณ์อย่างไรเมื่อ production ไม่ตรงกับสมมติฐานในเครื่อง Frontend system ยังเข้าใจง่ายหลังเปิดใช้ ไม่ใช่เพราะมันไม่เปลี่ยน แต่เพราะ boundary ทำให้ทุกการเปลี่ยนมองเห็นได้ review ได้ และย้อนกลับได้