วันที่ 19 มิถุนายน 2025 ผมไปงาน PiterJS #79 ที่เซนต์ปีเตอร์สเบิร์ก ธีมของคืนนั้นไม่หวือหวา และนั่นกลับเป็นข้อดี: ไม่ใช่ว่าจะ ship feature ถัดไปอย่างไร แต่จะดูแลสิ่งที่สร้างไว้แล้วอย่างไร — monitoring, deployment และ refactoring
โปรแกรมสอดคล้องกับธีมนี้มาก Pavel Shlykov พูดเรื่องการปรับปรุง monolith เก่า, Alexander Panfilov พูดเรื่อง FrontOps และ Igor Antonov พูดเรื่อง metrics ด้าน performance ของ web application ผมกลับออกมาพร้อมโน้ตที่ใช้คิดต่อได้จากทั้งสามหัวข้อ
ส่วนที่ไม่คาดคิดคือ Q&A สุดท้ายผม ได้รางวัลสองชิ้นจากการถามคำถามที่ดีที่สุด ในช่วงถามตอบ มันไม่ใช่ความสำเร็จทางเทคนิคครั้งใหญ่ แต่กลับเป็นรายละเอียดที่จำได้ชัดที่สุด เพราะมันย้ำว่าทำไมผมยังให้คุณค่ากับ technical meetup แบบเจอกันจริง ๆ: เราไม่ได้แค่รับฟัง talk ที่เตรียมไว้ แต่สามารถทดสอบความเข้าใจของตัวเองได้ทันทีในขณะที่คนที่เพิ่งนำเสนอเรื่องนั้นยังอยู่ในห้อง
สิ่งที่มีประโยชน์คือเรื่อง maintenance ไม่ใช่ความใหม่
งาน frontend สามารถกลายเป็นขบวนของ framework, API และ abstraction ใหม่ ๆ ได้ง่าย PiterJS #79 ดูติดดินกว่านั้น ธีมที่ประกาศไว้คือการดูแล software ที่มีอยู่แล้ว
เรื่องนี้สำคัญเพราะงาน engineering จำนวนมากเริ่มจริง ๆ หลัง release แรกที่สำเร็จ Legacy monolith ไม่ได้แปลว่าเป็นระบบที่แย่โดยอัตโนมัติ และ “modernization” ก็ไม่ได้หมายความว่าต้อง rewrite ทุกอย่างเสมอ คำถามเชิงปฏิบัติมักแคบกว่านั้น: constraint อะไรที่กำลังสร้างปัญหาให้ระบบจริง ๆ ตอนนี้ และการเปลี่ยนแปลงแบบไหนจะลดปัญหานั้นโดยไม่สร้าง risk ใหม่มากกว่าที่มันช่วยกำจัด?
นี่คือเหตุผลที่สาม talk เชื่อมกันได้ดี Refactoring เปลี่ยน code, FrontOps เปลี่ยนวิธี build, package, deliver และ operate frontend ส่วนงาน performance เปลี่ยนวิธีวัดผล ทั้งหมดคือคนละ layer ของปัญหาเดียวกัน: ทำอย่างไรให้ระบบจริงที่เติบโตแล้ว ยังเข้าใจและควบคุมได้
FrontOps กว้างกว่า Dockerfile
หนึ่งในโน้ตของผมจาก meetup คือเรื่องการทำ FrontOps ด้วย Docker สิ่งที่ควรแยกให้ชัดคือ Docker เป็นเครื่องมือ ไม่ใช่นิยามของ FrontOps
ความรับผิดชอบของ frontend ไม่จำเป็นต้องจบเมื่อ npm run build สำเร็จ ใน production ยังต้องมีคนคิดเรื่อง reproducible builds, การ package artifact, การส่ง configuration ไปยัง application, release rollback, cache behavior และการสังเกต failure Container อาจทำให้บางส่วนของงานเหล่านี้ predictable มากขึ้น แต่ไม่ได้แทนที่ operational decisions
นี่ช่วยแก้ mental model ที่พบได้บ่อย: successful build พิสูจน์ได้เพียงว่า build เสร็จ ไม่ได้พิสูจน์ว่า application จะ deploy ถูกต้อง ทำงานถูกต้องใน production หรือ recover ได้ง่ายเมื่อมีปัญหา
Performance เริ่มจากการนิยามว่า “ช้า” คืออะไร
Talk เรื่อง performance มีประโยชน์มากตรงวิธีวางกรอบเรื่อง measurement ขอบเขตที่ประกาศไว้รวมถึงปัจจัยที่กระทบ loading speed, frontend performance metrics แบบต่าง ๆ, วิธี quantify คำว่า “slow” และแม้แต่คำถามว่าทำไม optimization จึงไม่จำเป็นเสมอไป
ประเด็นสุดท้ายถูกมองข้ามได้ง่าย “ทำให้เร็วขึ้น” ฟังเหมือนเป้าหมายที่ objective แต่ถ้าไม่มี metric และไม่มีปัญหาที่ผู้ใช้มองเห็นจริง ๆ มันอาจกลายเป็นการเดาที่มีต้นทุนสูง process ด้าน performance ที่ดีควรเริ่มจากการนิยามว่าอะไรช้าจริง วัดมัน หา bottleneck เปลี่ยนสิ่งที่เกี่ยวข้องหนึ่งอย่าง แล้ววัดอีกครั้ง
Metric ไม่ใช่ user experience ด้วยตัวมันเอง แต่ช่วยให้การคุยมีหน่วยร่วมกัน หากไม่มี measurement งาน performance อาจกลายเป็นชุดการเปลี่ยนแปลงที่ดูน่าประทับใจทางเทคนิค แต่ไม่มี evidence ชัดเจนว่าปัญหาที่สำคัญจริงดีขึ้นหรือไม่
Q&A เปลี่ยนคุณค่าของ meetup สำหรับผม
ผมสามารถดู recording และเก็บ link ทีหลังได้ สิ่งที่ทำซ้ำได้ยากกว่าคือ interaction รอบ ๆ talk การตั้งคำถามที่ดีบังคับให้เราย่อ uncertainty ของตัวเองให้เหลือสิ่งที่เฉพาะพอที่ engineer อีกคนจะตอบได้
การได้รางวัลสองชิ้นเป็นเรื่องสนุก แต่ lesson ที่มีประโยชน์กว่านั้นเรียบง่ายกว่า: การไป meetup แบบออฟไลน์โดยเตรียมตัวเพื่อมีส่วนร่วม ให้คุณค่ามากกว่าการมองมันเป็น live YouTube playlist อย่างชัดเจน
คำถาม technical ที่ดีมักมี context และ constraint แทนที่จะถามว่า “architecture ไหนดีที่สุด?” การถามว่า trade-off เปลี่ยนอย่างไรเมื่อทีม rewrite legacy system ไม่ได้, deployment ต้อง backward-compatible หรือ performance metric ดีขึ้นแต่ผู้ใช้ไม่ได้ประโยชน์ที่มองเห็นได้ อาจมีประโยชน์มากกว่า
ไม่ได้หมายความว่าทุกคำถามต้องดูฉลาด จุดสำคัญคือช่วยเปิดเผย assumption, boundary หรือ failure mode
สิ่งที่ผมจะพกไป meetup ครั้งต่อไป
- รู้ก่อนว่า talk นี้สำคัญกับผมเพราะอะไร จด problem หรือ uncertainty จริงสักหนึ่งข้อก่อน session เริ่ม
- แยกประสบการณ์ของ speaker ออกจากระบบของตัวเอง Case study ที่ดีคือ evidence ไม่ใช่สูตรสากล
- ถามเรื่อง trade-off “เมื่อไรคุณจะไม่ใช้สิ่งนี้?” มักเปิดข้อมูลมากกว่า “tool ไหนดีที่สุด?”
- จด follow-up action หนึ่งอย่าง Note มีค่ามากขึ้นเมื่อพาไปสู่สิ่งที่ต้อง verify, test หรืออ่านต่อหลัง meetup
- อย่าสับสน talk ที่ฟังแล้วน่าเชื่อกับ production proof การตัดสินใจเรื่อง architecture, deployment และ performance ยังต้อง validate ใน environment ของตัวเอง
สิ่งที่ยังอยู่กับผม
ผมไม่อยากพูดเกินจริงว่า meetup หนึ่งครั้งเปลี่ยนอะไรได้มากแค่ไหน ผมไม่ได้ออกจาก PiterJS พร้อมสูตร architecture ที่ใช้ได้กับทุกระบบ และ talk ที่ดีก็ไม่แทน documentation, profiling, testing หรือ production data
สิ่งที่ผมได้กลับมาจริง ๆ เป็นเรื่องที่จับต้องได้กว่า: โน้ตที่มีประโยชน์เกี่ยวกับการ modernize legacy monolith, FrontOps ด้วย Docker และการวัด web performance; รางวัลสองชิ้นจาก Q&A; และการย้ำเตือนอีกครั้งว่า local developer community คุ้มค่ากับการไปเข้าร่วมด้วยตัวเอง
Recording เก็บ presentation ไว้ได้ ส่วนที่ archive ยากที่สุดคือบทสนทนาที่เกิดขึ้นรอบ ๆ มัน