“What’s happened, happened. Which is an expression of faith in the mechanics of the world. It’s not an excuse to do nothing.”

(อะไรที่เกิดขึ้นไปแล้ว ก็คือเกิดขึ้นไปแล้ว นั่นคือการแสดงความศรัทธาในกลไกของโลก ไม่ใช่ข้ออ้างที่จะไม่ทำอะไรเลย) — Neil, Tenet (2020)

หากพูดถึงภาพยนตร์ที่ท้าทายสมองผู้ชมมากที่สุดเรื่องหนึ่งของผู้กำกับ คริสโตเฟอร์ โนแลน (Christopher Nolan) ชื่อของ Tenet (2020) จะต้องติดอยู่ในอันดับต้น ๆ อย่างไม่ต้องสงสัย

แทนที่จะเล่าเรื่องการเดินทางข้ามเวลาด้วยไทม์แมชชีนแบบก้าวกระโดด โนแลนหยิบเอาแนวคิดทางฟิสิกส์อุณหพลศาสตร์เรื่อง เอนโทรปี (Entropy) และศรแห่งเวลา (Arrow of Time) มาตั้งคำถามใหม่ว่า จะเกิดอะไรขึ้นหากเราสามารถเดินเข้าเครื่องจักรที่ชื่อว่า Turnstile เพื่อ “กลับขั้วเอนโทรปี” ของวัตถุหรือมนุษย์ ให้เคลื่อนที่สวนทางกับกระแสเวลาปกติทีละวินาที?

ภาพจำอันทรงพลังของภาพยนตร์เรื่องนี้ คือฉากที่ตัวเอกยืนอยู่หน้ากำแพงหินที่มีรูกระสุนปืนฝังอยู่แล้ว เมื่อเขายื่นปืนออกไปและเหนี่ยวไก แทนที่กระสุนจะพุ่งออกจากปากกระบอกปืน เศษหินที่แตกกระจายกลับค่อย ๆ ลอยกลับเข้ามารวมตัวกัน และหัวกระสุนที่ฝังอยู่ในกำแพงก็ถูกดูดย้อนกลับเข้าสู่ลำกล้องปืนอย่างน่าอัศจรรย์

แต่ภายใต้ฉากแอ็กชันย้อนเวลาที่ดูซับซ้อน กฎเหล็กข้อเดียวที่ควบคุมจักรวาลของ Tenet เอาไว้ได้อย่างอยู่หมัดคือคำพูดของนีลที่ว่า “What’s happened, happened”

ในโลกของ Tenet อดีตเป็นสิ่งที่ถูกจารึกไว้แล้วอย่างสมบูรณ์แบบ ต่อให้คุณกลับขั้วเวลาเดินย้อนกลับไปสู่อดีต คุณก็ไม่สามารถไป “ลบ” หรือ “เขียนทับ” เหตุการณ์ที่เคยเกิดขึ้นแล้วให้หายไปได้ สิ่งเดียวที่คุณทำได้คือการส่งการกระทำที่กลับขั้ว (Inverted Action) เข้าไปเติมเต็มและหักล้างผลลัพธ์ในระดับภาพรวมเท่านั้น

น่าทึ่งมากที่กฎเหล็กข้อนี้ ไม่ได้เป็นเพียงปรัชญาในภาพยนตร์ไซไฟ แต่มันคือรากฐานที่สำคัญที่สุดในการออกแบบระบบซอฟต์แวร์การเงิน ธนาคาร และระบบกระจายตัวระดับโลก ที่เราเรียกกันว่าสถาปัตยกรรม Event Sourcing และหลักการ Immutability

1. โลกที่มีแต่ยางลบ กับหายนะของการเขียนทับอดีต (Mutable State)

เมื่อเราเริ่มต้นเรียนเขียนโปรแกรมหรือออกแบบฐานข้อมูล คำสั่งพื้นฐาน 4 คำที่โปรแกรมเมอร์ทุกคนต้องท่องจำให้ขึ้นใจคือ CRUD ซึ่งย่อมาจาก Create, Read, Update, และ Delete

ในมุมมองของ CRUD โลกของข้อมูลคือ “กระดานไวท์บอร์ด” หรือกระดาษที่เราถือดินสอกับยางลบอยู่ในมือ เมื่อสถานะของระบบเปลี่ยนไป เราก็แค่เอายางลบไปลบค่าเก่าทิ้ง แล้วเขียนค่าใหม่ทับลงไปที่เดิม

ลองจินตนาการถึงการออกแบบตารางบัญชีธนาคารอย่างง่ายที่มีคอลัมน์ชื่อว่า Balance (ยอดเงินคงเหลือ):

• 09:00 น. — ผู้ใช้มีเงินในบัญชี 1,000 บาท
• 12:00 น. — ผู้ใช้โอนเงินออกไปซื้อกาแฟ 200 บาท ระบบทำการรันคำสั่ง UPDATE accounts SET balance = 800 เอาเลข 800 ไปเขียนทับเลข 1,000 ตัวเดิมทันที

วิธีเก็บสถานะปัจจุบันทับที่เดิมแบบนี้ ในทางวิศวกรรมซอฟต์แวร์เรียกว่า Mutable State (สถานะที่เปลี่ยนแปลงทับได้) ซึ่งดูเผิน ๆ ก็เรียบง่ายและประหยัดพื้นที่จัดเก็บดี

แต่ฝันร้ายจะเริ่มต้นขึ้นทันทีที่เกิดความผิดพลาด!

สมมติว่าในเวลา 18:00 น. ผู้ใช้เปิดแอปพลิเคชันขึ้นมาแล้วพบว่ายอดเงินในบัญชีกลายเป็น 0 บาท เมื่อวิศวกรเปิดฐานข้อมูลเข้าไปดู สิ่งเดียวที่ปรากฏอยู่ตรงหน้าคือตัวเลข 0 โดด ๆ เพียงตัวเดียว

คำถามคือ ก่อนหน้าที่จะกลายเป็นเลข 0 มันเคยเป็นเลขอะไรมาก่อน? เงินหายไปเพราะผู้ใช้กดโอนเอง? หายไปเพราะมีโปรเซสสองตัวทำงานชนกัน (Race Condition) แล้วคำนวณยอดผิด? หรือหายไปเพราะบั๊กในโค้ดที่เพิ่งอัปเดตขึ้นไปเมื่อตอนบ่าย?

ไม่มีใครตอบได้โดยดูจากตารางนั้นเพียงอย่างเดียว เพราะ “ร่องรอยของอดีต” ได้ถูกยางลบที่ชื่อว่า UPDATE และ DELETE ลบทิ้งไปหมดสิ้นแล้ว

2. Event Sourcing: เมื่อความจริงคือลำดับของเหตุการณ์ (Append-Only Log)

เพื่อแก้ปัญหาการสูญเสียความจริงในอดีต สถาปนิกซอฟต์แวร์ที่ออกแบบระบบที่มีความสำคัญสูง (Mission-Critical Systems) จึงเปลี่ยนกระบวนทัศน์จาก Mutable State ไปสู่หลักการ Immutability (ความไม่เปลี่ยนแปลง) และสถาปัตยกรรมที่เรียกว่า Event Sourcing (ซึ่งถูกทำให้แพร่หลายในวงการซอฟต์แวร์ยุคใหม่โดยกูรูอย่าง Martin Fowler และ Greg Young)

หัวใจของ Event Sourcing ยึดถือกฎเดียวกับภาพยนตร์ Tenet นั่นคือ “What’s happened, happened”

ในระบบที่ใช้ Event Sourcing เราจะห้ามใช้คำสั่ง UPDATE เพื่อแก้ไขข้อมูลเก่า และห้ามใช้คำสั่ง DELETE เพื่อลบอดีตทิ้งโดยเด็ดขาด สิ่งเดียวที่ระบบได้รับอนุญาตให้ทำ คือการบันทึก "เหตุการณ์ที่เกิดขึ้นจริง (Domain Events)" ต่อท้ายเรียงกันลงไปเรื่อย ๆ เท่านั้น หรือที่เรียกว่า Append-Only Log

แทนที่เราจะเก็บตัวเลขโดด ๆ ว่าตอนนี้มีเงิน 800 บาท ระบบจะเก็บบันทึกเป็นลำดับประวัติศาสตร์ว่า:

1. Event #1 [09:00]: AccountDeposited (+1,000 บาท)
2. Event #2 [12:00]: MoneyTransferredOut (-200 บาท)

แล้วเราจะรู้ได้อย่างไรว่า ณ ปัจจุบันผู้ใช้มีเงินเหลืออยู่กี่บาท?

คำตอบคือ เราใช้การนำเหตุการณ์ทั้งหมดตั้งแต่อดีตมาคำนวณรวมกันตามลำดับเวลา (เรียกว่าการทำ State Projection หรือการ Fold/Reduce ข้อมูล):

เมื่อนำ +1,000 มารวมกับ -200 เราจึงได้สถานะปัจจุบันออกมาเป็น 800 บาท

ความมหัศจรรย์ของการแยก “ประวัติศาสตร์ของเหตุการณ์ (Events)” ออกจาก “สถานะปัจจุบัน (State)” คือมันมอบพลังแห่งการเดินทางข้ามเวลา (Time Travel Debugging & Auditability) ให้กับระบบของเราอย่างสมบูรณ์แบบ หากเราอยากรู้ว่าเมื่อวันที่ 15 เดือนที่แล้ว เวลาบ่ายสองโมงสิบห้านาที 32 วินาที บัญชีนี้มียอดเงินเท่าไหร่ เราก็เพียงแค่สั่งให้ระบบเล่นเทปเหตุการณ์ (Replay Events) ตั้งแต่อดีตมาหยุด ณ เวลาบ่ายสองโมงสิบห้านาที 32 วินาที เราก็จะเห็นภาพความจริง ณ วินาทีนั้นได้ชัดเจน 100% โดยไม่มีข้อมูลใดสูญหายไปตามกาลเวลา

3. นักบัญชีไม่ใช้ยางลบ: การซ่อมแซมอดีตด้วย Compensating Transactions

คำถามสำคัญที่มักจะตามมาเสมอก็คือ “ในโลกความเป็นจริง มนุษย์และระบบทำผิดพลาดกันได้ตลอดเวลา เช่น ระบบตัดเงินลูกค้าซ้ำสองรอบ หรือพนักงานคีย์ตัวเลขผิดไปศูนย์ตัวหนึ่ง… ถ้ากฎเหล็กของ Event Sourcing ห้ามเราลบและห้ามแก้ไขอดีต แล้วเราจะซ่อมแซมความผิดพลาดเหล่านั้นได้อย่างไร?”

ในปี 2007 แพต เฮลแลนด์ (Pat Helland) สถาปนิกซอฟต์แวร์ระดับตำนาน ได้เขียนเปเปอร์ชิ้นสำคัญที่มีชื่ออันแสนคมคายว่า “Accountants Don’t Use Erasers” (นักบัญชีไม่ใช้ยางลบ)

ความจริงแล้ว โปรแกรมเมอร์ไม่ได้เป็นคนกลุ่มแรกที่คิดค้นแนวคิด Event Sourcing หรอกครับ แต่ผู้ที่วางรากฐานสถาปัตยกรรมนี้ไว้ตั้งแต่ปี ค.ศ. 1494 (ยุคเรอเนซองส์) คือบาทหลวงและนักคณิตศาสตร์ชาวอิตาเลียนนามว่า ลูกา ปาโชลี (Luca Pacioli) ผู้รวบรวมระบบ บัญชีคู่ (Double-Entry Bookkeeping) มาตรฐานที่ธนาคารทั่วโลกใช้กันมาจนถึงทุกวันนี้

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

สิ่งที่นักบัญชีทำเมื่อเกิดความผิดพลาด คือการปล่อยให้รายการที่ผิดพลาดบรรทัดนั้นคงอยู่ต่อไปในฐานะความจริงที่ว่า “เคยมีการลงบัญชีผิดเกิดขึ้นจริง” แล้วใช้วิธี เขียนรายการใหม่ขึ้นมาอีกหนึ่งบรรทัดในปัจจุบัน เพื่อหักล้างค่าเดิม:

• Event #2 [12:00]: MoneyDeducted (-500 บาท) (รายการที่ตัดผิด)
• Event #3 [12:05]: OverchargeCompensated (+500 บาท, อ้างอิง Event #2) (รายการปรับปรุงชดเชย)

ในทางวิศวกรรมซอฟต์แวร์และสถาปัตยกรรมไมโครเซอร์วิส (เช่น ใน Saga Pattern) เราเรียกการกระทำบรรทัดที่ 3 นี้ว่า Compensating Transaction (ธุรกรรมชดเชย) หรือการส่ง Inversion Event (เหตุการณ์กลับขั้ว) เข้าไปในระบบ

นี่คือภาพเดียวกับปฏิบัติการในภาพยนตร์ Tenet อย่างแท้จริง!

เมื่อตัวเอกของเรื่องต้องการกอบกู้โลกจากเหตุการณ์ที่เกิดขึ้นไปแล้ว เขาไม่ได้นั่งไทม์แมชชีนไปลบอดีตทิ้ง เพราะอดีตเป็นสิ่งที่ไม่สามารถเปลี่ยนแปลงได้ (Immutable) แต่สิ่งที่เขาทำคือการเดินเข้าเครื่อง Turnstile แล้วทำยุทธการ Temporal Pincer Movement คือการส่งการกระทำที่กลับขั้ววิ่งสวนเข้าไปหักล้างและชดเชยผลกระทบของเหตุการณ์เดิม เพื่อให้ผลรวมสุดท้าย (Final Projection) ของโลกกลับคืนสู่ความสมดุลอีกครั้ง โดยที่ประวัติศาสตร์ทุกบรรทัดยังคงอยู่ครบถ้วนสมบูรณ์

4. สมุดบันทึกชีวิตที่ไม่มีปุ่ม Rollback และปรัชญา Amor Fati

เมื่อเราถอยออกมามองสถาปัตยกรรม Event Sourcing แล้วหันกลับมามอง “สถาปัตยกรรมของชีวิตมนุษย์” เราจะพบความจริงที่ปลดล็อกความทุกข์ในใจของเราได้อย่างน่าอัศจรรย์

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

เรามักจะขังตัวเองไว้กับคำว่า “รู้งี้…”:

• “รู้งี้วันนั้นไม่น่าพูดประโยคร้าย ๆ แบบนั้นใส่คนที่เรารักเลย”
• “รู้งี้เมื่อสามปีก่อนไม่น่าตัดสินใจเลือกเส้นทางอาชีพนี้เลย”
• “รู้งี้ตอนนั้นน่าจะดูแลสุขภาพและใช้เวลากับครอบครัวให้มากกว่านี้”

เราเฝ้าปรารถนาจะได้ยางลบวิเศษ หรืออยากกดปุ่ม Rollback เพื่อย้อนเวลากลับไปลบความผิดพลาดและความล้มเหลวเหล่านั้นให้หายไปจากหน้าประวัติศาสตร์ชีวิต เหมือนโปรแกรมเมอร์ที่คุ้นชินกับการแก้ตารางฐานข้อมูลแบบ Mutable State

แต่ความจริงของธรรมชาติก็คือ ชีวิตมนุษย์ทำงานด้วยสถาปัตยกรรม Append-Only Log ร้อยเปอร์เซ็นต์ ไม่มีปุ่ม Undo ไม่มีคำสั่ง DELETE และไม่มีน้ำยาลบคำผิดให้เราใช้ลบอดีต ทุกการกระทำ ทุกคำพูด และทุกการตัดสินใจของเรา ทันทีที่มันเกิดขึ้นแล้ว มันจะถูกจารึกเป็น Immutable Event ทันที

ในทางปรัชญา นักปรัชญาชาวเยอรมัน ฟรีดริช นีตเชอ (Friedrich Nietzsche) รวมถึงนักปราชญ์สายสโตอิก (Stoicism) อย่าง อิพิคตีตัส (Epictetus) และจักรพรรดิ มาร์คัส ออเรลิอัส (Marcus Aurelius) ได้มอบกุญแจสำคัญในการรับมือกับความจริงข้อนี้ไว้ผ่านแนวคิดที่เรียกว่า Amor Fati (อามอร์ ฟาติ) ซึ่งแปลว่า “การรักในโชคชะตาของตนเอง”

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

คำว่า Amor Fati ในมุมมองของวิศวกรระบบ จึงไม่ใช่การยอมจำนนแล้วนั่งงอมืองอเท้า (เหมือนที่นีลบอกใน Tenet ว่า “มันไม่ใช่ข้ออ้างที่จะไม่ทำอะไรเลย”) แต่มันคือการหยุดเสียพลังงานชีวิตไปกับการพยายามลบ Log ในอดีตที่ลบไม่ได้ แล้วตระหนักว่า คุณค่าของชีวิตเราไม่ได้ถูกตัดสินด้วย Event ที่ผิดพลาดเพียงบรรทัดเดียวในอดีต แต่มันคือผลรวม (Projection) ของทุกบรรทัดที่เราเลือกเขียนต่อท้ายลงไปต่างหาก

บทสรุป: 3 แนวทางดูแลสถาปัตยกรรมชีวิตในโลกที่ห้ามใช้ยางลบ

การผสานมุมมองจากภาพยนตร์ Tenet, สถาปัตยกรรม Event Sourcing และปรัชญา Amor Fati มอบบทเรียนสำคัญ 3 ข้อให้เรานำไปปรับใช้ทั้งในการออกแบบระบบและการใช้ชีวิต:

1. เก็บรักษาความจริงของอดีตอย่างซื่อสัตย์ (Preserve the Immutable Truth): ทั้งในการสร้างระบบซอฟต์แวร์และการมองชีวิตตัวเอง อย่าพยายามปกปิดหรือหลอกตัวเองว่าความผิดพลาดไม่เคยเกิดขึ้น ระบบที่ลบประวัติศาสตร์ทิ้งคือระบบที่สูญเสียความสามารถในการเรียนรู้และตรวจสอบตัวเอง การยอมรับความจริงของอดีตอย่างตรงไปตรงมาคือจุดเริ่มต้นของความแข็งแกร่งเสมอ
2. ก้าวข้ามความผิดพลาดด้วย “การกระทำชดเชย” (Move Forward with Compensating Actions): เมื่อทำผิดพลาดในชีวิตหรือในความสัมพันธ์ จงวางยางลบในมือลง เลิกจมอยู่กับความรู้สึกผิดที่พยายามจะลบอดีต แต่จงใช้วิธีของนักบัญชีและวิศวกรระบบ นั่นคือการสร้าง Compensating Event ในวันนี้ — หากเคยพูดจาทำร้ายจิตใจใคร จงเขียน Event ใหม่ด้วยการขอโทษอย่างจริงใจและดูแลเขาให้ดีกว่าเดิม หากเคยทำโปรเจกต์ล้มเหลว จงเขียน Event ใหม่ด้วยการนำบทเรียนนั้นมาสร้างผลงานชิ้นใหม่ที่รอบคอบกว่าเดิม
3. Amor Fati: รักในทุกบรรทัดที่ผ่านมา และเขียนบรรทัดต่อไปให้ดีที่สุด (Own Your Log, Write the Next Event): อดีตมีไว้ให้เราสั่ง Replay เพื่อทำความเข้าใจลำดับเหตุและผล ไม่ได้มีไว้ให้เราเข้าไปติดขังอยู่ข้างใน จงมองย้อนกลับไปดูทุกความสำเร็จและทุกบาดแผลในอดีตด้วยความเข้าใจว่า “What’s happened, happened” แล้วใช้สิทธิ์อำนาจเดียวที่คุณมีอยู่ในวินาทีนี้ นั่นคือการจรดปากกาเขียน Event บรรทัดต่อไปของชีวิตด้วยความตั้งใจที่ดีที่สุดครับ

📚 เอกสารอ้างอิง (References & Further Reading)

• Helland, P. (2007). Accountants Don’t Use Erasers. Conference on Innovative Data Systems Research (CIDR).
• Fowler, M. (2005). Event Sourcing. martinfowler.com.
• Pacioli, L. (1494). Summa de arithmetica, geometria, proportioni et proportionalita (จุดกำเนิดการจัดทำระบบบัญชีคู่ — Double-Entry Bookkeeping).
• Eddington, A. S. (1928). The Nature of the Physical World (แนวคิดเรื่อง Arrow of Time และ Entropy).
• Nietzsche, F. (1882 / 1888). The Gay Science (§276) & Ecce Homo (แนวคิดเรื่อง Amor Fati).
• Epictetus. Enchiridion (คู่มือการใช้ชีวิตตามปรัชญาสโตอิก).

บทความนี้เรียบเรียงจากเนื้อหาในรายการ Uncle Quin Podcast EP.66: Tenet & สถาปัตยกรรมย้อนเวลา สามารถรับฟังฉบับเต็มได้ทาง Spotify และ Apple Podcasts ครับ

หากคุณชอบบทความแนวการเชื่อมโยงปรัชญาเข้ากับการทำงานในโลกยุคใหม่ ฝากกดเลิฟ กดแชร์ และกดติดตามช่องของผมด้วยนะครับ!

• Spotify
• YouTube

Tenet & สถาปัตยกรรมย้อนเวลา was originally published in odds.team on Medium, where people are continuing the conversation by highlighting and responding to this story.

สมัยเริ่มต้นอาชีพโปรแกรมเมอร์ ผมตื่นเต้นกับเทคโนโลยีใหม่ ๆ มาก

มีเวลาว่างจากงานก็ขวนขวายศึกษา อยากรู้ว่าตัวนี้ทำอะไรได้ ตัวนั้นใช้อย่างไร แล้วจะเอามาช่วยงานที่ทำอยู่ได้ไหม

แต่ด้วยความที่ประสบการณ์ยังน้อย พื้นฐานก็ยังไม่แน่น กว่าจะอ่านและทำความเข้าใจเทคโนโลยีแต่ละตัวได้ บางทีก็ใช้เวลาหลายเดือน

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

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

กว่าจะเข้าใจเรื่องนี้ ก็ต้องผ่านการกลับไปแก้ระบบเดิมซ้ำ ๆ เพิ่ม requirement ใหม่ อัปเกรด library และพยายามเขียน test ให้โค้ดที่ตอนแรกไม่ได้คิดว่าจะต้องอยู่กับเรานานขนาดนั้น

หลังจากมีประสบการณ์กับ Clean Architecture และได้ดูแลระบบที่มีอายุหลายปี ผมถึงเริ่มมองตัวอย่างใน Quickstart เปลี่ยนไป

ผมยังอ่านมันเป็นอย่างแรกเหมือนเดิม แต่ก่อนเอาไปใช้ ผมจะถามเพิ่มว่า business logic อยู่ตรงไหน และโค้ดส่วนไหนกำลังผูกเราไว้กับ library ตัวนี้

ลองดูตัวอย่างจาก Temporal

ช่วงนี้ผมใช้ Temporal ใน Butler สำหรับงาน onboarding และ offboarding เลยขอยกตัวอย่างจาก Temporal Go Quickstart

Workflow ในตัวอย่างมีหน้าตาประมาณนี้ ผมตัดรายละเอียดบางส่วนให้เหลือเฉพาะจุดที่จะคุยกัน

func SayHelloWorkflow(
    ctx workflow.Context,
    name string,
) (string, error) {
    ctx = workflow.WithActivityOptions(
        ctx,
        workflow.ActivityOptions{
            StartToCloseTimeout: 10 * time.Second,
        },
    )

    var result string
    err := workflow.ExecuteActivity(
        ctx,
        Greet,
        name,
    ).Get(ctx, &result)

    return result, err
}

อ่านแล้วเห็นเลยว่า เราตั้งค่า activity อย่างไร เรียก activity อย่างไร แล้วเอาผลกลับมาอย่างไร

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

แต่พองานเปลี่ยนจากการทักทาย เป็นการสร้าง account ให้พนักงานหนึ่งคน คำถามก็เริ่มเพิ่มขึ้น

ต้องสร้าง M365 ก่อนหรือ Keycloak ก่อน? อะไรทำขนานกันได้? ถ้าบางระบบสำเร็จ บางระบบล้มเหลว จะสรุปผลอย่างไร? ถ้ามีผู้ใช้อยู่แล้วควรทำต่อไหม?

ถ้าเราเติมทุกอย่างลงไปตรงที่เริ่มเขียนไว้ ในที่สุด workflow ก็อาจมีทั้งลำดับงาน กฎธุรกิจ การแปลงข้อมูล และรายละเอียดของระบบภายนอกอยู่ด้วยกัน

โค้ดยังรันได้ แต่เวลาแก้เรื่องหนึ่ง เราต้องทำความเข้าใจอีกหลายเรื่องตามไปด้วย

ผมเริ่มจากแยกกฎที่ไม่ต้องรู้จัก Temporal

ใน Butler ผมแยกส่วนที่เกี่ยวข้องออกมาตามหน้าที่ มองเป็นภาพได้ประมาณนี้

Handler รู้แค่ว่ามีช่องทางให้สั่งเริ่มงาน ส่วนรายละเอียดการเรียก SDK อยู่ใน Temporal adapter ถ้า library เปลี่ยน เราก็มีขอบเขตให้เริ่มตรวจและแก้ได้ชัดเจน

เมื่อ workflow ทำงาน มันรับผิดชอบว่าอะไรต้องทำก่อนหลัง อะไรทำขนานกันได้ และต้องรอผลตรงไหน โดยให้ activity ลงมือทำงานที่มีผลกับระบบภายนอก

ส่วนกฎอย่างการเลือก email หรือการสรุปผลว่าเป็น success หรือ partial success ผมแยกเป็น business logic ที่รับข้อมูลมาคำนวณแล้วคืนผลได้ โดยไม่ต้องรู้จัก Temporal

ในภาพใช้กล่องแบบ class diagram เพื่อให้เห็นความสัมพันธ์ แต่ตอนเขียน Go จริง business logic เหล่านี้เป็นฟังก์ชันธรรมดาได้ ไม่จำเป็นต้องสร้าง struct หรือ interface ให้ทุกกล่อง

ยกตัวอย่างการเลือก email ที่จะนำไปใช้ต่อ โค้ดแบบย่อจะเป็นประมาณนี้

package logic

import "strings"

func DirectoryEmail(mail, principalName string) string {
    if email := strings.TrimSpace(mail); email != "" {
        return email
    }

    return strings.TrimSpace(principalName)
}

ฟังก์ชันนี้ไม่ต้องรู้จัก workflow context ไม่ต้องต่อ Temporal และไม่ต้องรู้ว่าข้อมูลมาจาก HTTP หรือ database

เวลาอยากทดสอบกฎนี้ ก็ส่ง input แล้วตรวจ output ได้เลย

func TestDirectoryEmailFallsBackToPrincipalName(t *testing.T) {
    got := logic.DirectoryEmail(
        " ",
        "someone@example.com",
    )

    if got != "someone@example.com" {
        t.Fatalf("unexpected email: %q", got)
    }
}

ส่วน workflow ก็เรียกใช้กฎนั้น แล้วทำหน้าที่จัดลำดับงานต่อ

// ตัวอย่างย่อจาก flow ของ Butler
var m365 M365Summary

err := workflow.ExecuteActivity(
    ctx,
    (*Activities).CreateM365User,
    input,
).Get(ctx, &m365)
if err != nil {
    return Result{}, err
}

email := logic.DirectoryEmail(
    m365.Mail,
    m365.UserPrincipalName,
)

ถ้าวันหนึ่งกฎการเลือก email เปลี่ยน ผมมีที่ให้แก้และทดสอบได้ตรง ๆ โดยไม่ต้องเข้าไปยุ่งกับวิธีเรียก activity

ส่วนกฎการรวมผลว่าเป็น success หรือ partial success ก็แยกด้วยเหตุผลเดียวกัน

ฝั่งที่สั่งเริ่มงาน ผมก็แยกตัวเชื่อมต่อออกมา

อีกจุดที่ผมเคยทำบ่อยตอนเริ่มต้น คือเรียก library ตรงจากโค้ดที่กำลังเขียนอยู่เลย

รับ HTTP request มาแล้วก็เรียก SDK ตรงนั้น พอมีอีก endpoint ก็ทำเหมือนเดิม หลังจากนั้นรายละเอียดของ SDK ก็ค่อย ๆ กระจายไปทั่วระบบ

ใน Butler ผมใช้ Gateway เป็นขอบเขตระหว่างผู้เรียกกับ Temporal ตัวอย่างแบบย่อคือ

type WorkflowRef struct {
    WorkflowID string
    RunID      string
}

type OnboardingGateway interface {
    StartOnboard(
        ctx context.Context,
        workflowID string,
        input OnboardInput,
    ) (WorkflowRef, error)
}

ผู้เรียกรู้ว่าต้องส่งข้อมูลอะไร และจะได้อะไรกลับมา ส่วนวิธีเรียก Temporal SDK อยู่ใน adapter

type TemporalGateway struct {
    Client    client.Client
    TaskQueue string
}

func (g *TemporalGateway) StartOnboard(
    ctx context.Context,
    workflowID string,
    input OnboardInput,
) (WorkflowRef, error) {
    run, err := g.Client.ExecuteWorkflow(
        ctx,
        client.StartWorkflowOptions{
            ID:        workflowID,
            TaskQueue: g.TaskQueue,
        },
        OnboardEmployeeWorkflow,
        input,
    )
    if err != nil {
        return WorkflowRef{}, err
    }

    return WorkflowRef{
        WorkflowID: run.GetID(),
        RunID:      run.GetRunID(),
    }, nil
}

รายละเอียดอย่าง client.StartWorkflowOptions หรือการอ่าน ID จากค่าที่ SDK คืนมา จึงอยู่รวมกันในส่วนที่เชื่อมต่อกับ Temporal

ฝั่ง HTTP handler ก็เรียกผ่าน interface นี้ได้ และตอนทดสอบ handler เราสามารถใส่ implementation จำลองเข้าไปได้ โดยไม่ต้องเปิด Temporal ขึ้นมาด้วย

นี่คือสิ่งที่ผมเข้าใจมากขึ้นหลังจากได้ใช้ Clean Architecture ว่าเราสามารถกำหนดขอบเขตจากสิ่งที่งานของเราต้องการ แล้วให้ adapter เป็นคนแปลไปหาวิธีใช้งานของ library

แล้วเวลาอัปเกรด framework จะง่ายขึ้นอย่างไร?

สมมติ library เปลี่ยนรูปแบบ options หรือเปลี่ยนชนิดข้อมูลที่คืนกลับมา ถ้ารายละเอียดเหล่านั้นกระจายอยู่ใน handler และ business logic หลายจุด เราก็ต้องตามแก้ทุกจุด

แต่ถ้ารวมการเชื่อมต่อไว้ใน adapter เรามีจุดเริ่มต้นที่ชัดเจนว่าอะไรต้องตรวจและแก้ ขณะที่กฎอย่างการเลือก email หรือการสรุปผลยังทดสอบแยกได้เหมือนเดิม

แน่นอนว่าการมี adapter ไม่ได้รับประกันว่าอัปเกรดแล้วจะแก้ไฟล์เดียวจบ โดยเฉพาะ Temporal ซึ่งตัว workflow ใช้ SDK โดยตรง และมีเรื่องความเข้ากันได้กับ execution ที่กำลังทำงานอยู่ให้ดูแลด้วย

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

ผมไม่ได้แยกทุกอย่างตั้งแต่วันแรก

พอมองย้อนกลับไป ผมก็เข้าใจตัวเองตอนเริ่มต้นนะ กว่าจะอ่านจนรันได้ก็เหนื่อยแล้ว ตอนนั้นยังไม่มีประสบการณ์มากพอจะเห็นปัญหาที่จะตามมาในอีกสองสามปี

วันนี้ผมเองก็ยังเริ่มจากโค้ดง่าย ๆ ก่อน เพียงแต่พองานโตขึ้น ผมจะคอยดูว่ามีกฎธุรกิจปนอยู่กับรายละเอียดของเครื่องมือมากแค่ไหน

ถ้าเป็นกฎที่อธิบายได้โดยไม่ต้องพูดชื่อ library ผมจะลองแยกมันออกมา

ถ้าเป็นโค้ดที่แปลงคำสั่งของเราไปเป็นการเรียก SDK ผมจะพยายามรวมมันไว้ใน adapter

แล้วก็ดูด้วยว่าการแยกนั้นช่วยจริงไหม เพราะ interface ที่มีไว้ส่งต่ออย่างเดียวหลายชั้น ก็ทำให้ตามโค้ดยากได้เหมือนกัน

สิ่งที่เปลี่ยนไปตามประสบการณ์ของผม คือจากเดิมที่อ่าน Quickstart แล้วถามว่า “ทำอย่างไรให้รันได้” วันนี้ผมมีอีกคำถามตามมาว่า “ถ้าต้องดูแลต่อไปอีกหลายปี ผมอยากให้กฎของงานนี้อยู่ตรงไหน”

คำตอบของคำถามหลังนี่แหละ ที่ทำให้โค้ดในโปรเจกต์ค่อย ๆ มีหน้าตาต่างจาก Quickstart

วันที่ผมเข้าใจว่า โค้ดใน Quickstart ไม่ใช่โครงสร้างที่ต้องใช้ตลอดไป was originally published in odds.team on Medium, where people are continuing the conversation by highlighting and responding to this story.

“1 ชั่วโมงบนดาวดวงนี้ เท่ากับเวลา 7 ปีบนโลก”

ใครที่เคยดูภาพยนตร์ไซไฟระดับขึ้นหิ้งอย่าง Interstellar (2014) ของผู้กำกับ คริสโตเฟอร์ โนแลน (Christopher Nolan) คงจำฉากที่บีบหัวใจที่สุดบน “ดาวมิลเลอร์” (Miller’s Planet) ได้ขึ้นใจ

ดาวดวงนี้โคจรอยู่ประชิดกับหลุมดำมวลยิ่งยวดที่ชื่อว่า การ์แกนทัว (Gargantua) แรงโน้มถ่วงมหาศาลของหลุมดำได้บิดโค้งปริภูมิ-เวลาตามทฤษฎีสัมพัทธภาพทั่วไป จนเกิดปรากฏการณ์ Gravitational Time Dilation (การยืดหดของเวลาจากแรงโน้มถ่วง) เสียงเข็มนาฬิกาที่ดัง “ติ๊ก… ต็อก…” ในเพลงประกอบของ ฮานส์ ซิมเมอร์ ทุก ๆ 1.25 วินาที คือตัวแทนของเวลา 1 วันเต็มบนโลกมนุษย์ที่กำลังไหลผ่านไป

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

ฉากนี้ไม่ได้เป็นเพียงดราม่าไซไฟที่ทรงพลัง แต่มันคือภาพสะท้อนความจริงขั้นพื้นฐานของธรรมชาติที่ว่า “ในจักรวาลนี้ ไม่มีสิ่งที่เรียกว่าเวลาเดียวกันที่แท้จริง”

และที่น่าทึ่งไปกว่านั้นคือ ความจริงข้อนี้ไม่ได้เกิดขึ้นเฉพาะในอวกาศอันไกลโพ้นใกล้หลุมดำ แต่มันกำลังเกิดขึ้นทุกเสี้ยววินาทีภายในตู้แร็คเซิร์ฟเวอร์และระบบ Cloud ที่พวกเราใช้งานกันอยู่ทุกวัน ในโลกของวิศวกรรมซอฟต์แวร์ที่เราเรียกว่า ระบบกระจายตัว (Distributed Systems)

1. มายาคติของ time.Now() และภัยเงียบที่ชื่อว่า Clock Drift

เวลาที่เราเริ่มต้นเขียนโปรแกรมบนคอมพิวเตอร์เครื่องเดียว (Single Node) เรามักจะคุ้นชินกับความเรียบง่ายของเวลา เมื่อต้องการรู้ว่าเหตุการณ์ไหนเกิดก่อนหรือเกิดหลัง เราแค่เรียกฟังก์ชันอย่าง Date.now() หรือ time.Now() เพื่อดึงเวลาจากระบบปฏิบัติการมาแปะเป็นป้ายเวลา (Timestamp) ตราบใดที่ทุกโปรเซสรันอยู่บนเครื่องเดียวกันและมองดูนาฬิกาเรือนเดียวกัน ทุกอย่างก็ดูสมเหตุสมผล

แต่ทันทีที่เราก้าวเข้าสู่สถาปัตยกรรมแบบ Distributed Systems — เมื่อเซิร์ฟเวอร์ Node A ตั้งอยู่ที่สิงคโปร์, Node B อยู่ที่โตเกียว และ Node C อยู่ที่แฟรงก์เฟิร์ต (หรือแม้แต่อยู่ใน Data Center เดียวกันแต่คนละเครื่อง) — กฎเกณฑ์ทั้งหมดที่เราคุ้นเคยจะพังทลายลงทันที เพราะ “ในระบบกระจายตัว ไม่มี Global Clock”

คอมพิวเตอร์แต่ละเครื่องรับรู้เวลาผ่านชิ้นส่วนฮาร์ดแวร์เล็ก ๆ บนเมนบอร์ด นั่นคือ ผลึกแร่ควอตซ์ (Quartz Crystal Oscillator) ซึ่งจะสั่นสะเทือนด้วยความถี่เมื่อมีกระแสไฟฟ้าไหลผ่านเพื่อทำหน้าที่เป็นลูกตุ้มนับเวลา

ปัญหาทางกายภาพก็คือ ไม่มีผลึกแร่ควอตซ์ชิ้นไหนในโลกที่ถูกผลิตออกมาได้สมบูรณ์แบบ 100% เมื่ออุณหภูมิในห้องเซิร์ฟเวอร์เปลี่ยนแปลงไปเพียงเล็กน้อย หรืออายุการใช้งานของฮาร์ดแวร์ต่างกัน แร่ควอตซ์ในเครื่องที่สิงคโปร์อาจจะสั่นเร็วกว่าเครื่องที่โตเกียวไปไม่กี่ส่วนล้านวินาที อาการที่นาฬิกาของคอมพิวเตอร์แต่ละเครื่องค่อย ๆ เดินคลาดเคลื่อนห่างออกจากกันไปเรื่อย ๆ นี้เรียกว่า Clock Drift

หากปล่อยทิ้งไว้โดยไม่ซิงก์กันเลย นาฬิกาของเซิร์ฟเวอร์สองเครื่องอาจเดินเพี้ยนห่างกันได้ถึงระดับหลายมิลลิวินาทีภายในเวลาไม่กี่ชั่วโมง

ทำไม NTP ถึงแก้ปัญหานี้ให้จบ 100% ไม่ได้?

หลายคนอาจสงสัยว่า “เราก็ใช้โปรโตคอล NTP (Network Time Protocol) ให้เซิร์ฟเวอร์ทุกเครื่องคอยซิงก์เวลากับนาฬิกาอะตอมมาตรฐานผ่านอินเทอร์เน็ตสิ แค่นี้เวลาก็ตรงกันแล้วไม่ใช่หรือ?”

คำตอบคือ NTP ช่วยบรรเทาปัญหาได้ดีมาก แต่ ไม่สามารถทำให้เวลาตรงกันแบบ 100% ได้เลย

ในเรื่อง Interstellar นักวิทยาศาสตร์บนยานแม่ยังสามารถใช้สมการฟิสิกส์คำนวณอัตราส่วนความต่างของเวลาที่แน่นอนเป๊ะ ๆ ได้ว่า 1 ชั่วโมงข้างล่างเท่ากับ 7 ปีข้างบน แต่ในระบบเครือข่ายคอมพิวเตอร์ เวลาที่เซิร์ฟเวอร์ส่งแพ็กเก็ตผ่านสายไฟเบอร์ออปติกไปถามเวลาจาก NTP Server มันต้องเผชิญกับ ความหน่วงของเครือข่ายที่คาดเดาไม่ได้ (Unpredictable Network Latency)

แสงที่วิ่งในใยแก้วนำแสงเดินทางช้ากว่าในสุญญากาศราว 30% จากดัชนีหักเหของแก้ว และที่สำคัญกว่านั้นคือระหว่างทาง แพ็กเก็ตข้อมูลต้องผ่านสวิตช์และเราเตอร์นับสิบตัว บางจังหวะขาไปใช้เวลา 10 มิลลิวินาที แต่ขากลับบังเอิญทราฟฟิกหนาแน่น ติดคิวรอประมวลผลในเราเตอร์ (Queueing Delay) หรือใช้เส้นทางวิ่งกลับคนละเส้นทาง (Asymmetric Routing) จนใช้เวลาขากลับไป 50 มิลลิวินาที

เมื่อเวลาเดินทางขาไปและขากลับไม่เท่ากันและแกว่งไปมาตลอดเวลา เซิร์ฟเวอร์ปลายทางจึงไม่มีทางคำนวณชดเชยเวลาที่เสียไประหว่างทางได้แม่นยำ 100% นาฬิกาของทุกโหนดจึงมี “ช่วงความคลาดเคลื่อน” (Uncertainty Bound) ซ่อนอยู่เสมอ

ฝันร้ายของกลยุทธ์ Last Write Wins (LWW)

ความคลาดเคลื่อนระดับ 10 มิลลิวินาทีอาจฟังดูเล็กน้อยสำหรับมนุษย์ แต่ในระบบฐานข้อมูลกระจายตัวที่ใช้กลยุทธ์จัดการข้อมูลชนกันแบบ Last Write Wins (ใครเขียนทีหลัง คนนั้นชนะ) โดยอิงจากเวลาของเครื่อง (Wall-clock Time) มันคือหายนะเงียบ ๆ

ลองจินตนาการถึงเหตุการณ์นี้:

1. เวลาจริง 10:00:00.001 — ผู้ใช้สั่งอัปเดตสถานะคำสั่งซื้อที่ Node A (นาฬิกาเครื่องตรงเป๊ะ บันทึกป้ายเวลาเป็น 10:00:00.001)
2. เวลาจริง 10:00:00.005 — ระบบตัดเงินอัปเดตข้อมูลคำสั่งซื้อชิ้นเดียวกันตามหลังมาที่ Node B
3. แต่บังเอิญนาฬิกาของ Node B เกิดอาการ Clock Drift เดินช้ากว่าเวลาจริงไปแค่ 10 มิลลิวินาที ป้ายเวลาที่ Node B แปะลงไปในข้อมูลจึงกลายเป็น 09:59:59.995

เมื่อฐานข้อมูลนำข้อมูลจากทั้งสองโหนดมารวมกันและเปรียบเทียบป้ายเวลา มันจะตัดสินทันทีว่าข้อมูลจาก Node B (ซึ่งเกิดขึ้นทีหลังสุดในความเป็นจริง) เป็น “ข้อมูลเก่าในอดีต” และทำการเขียนทับหรือทิ้งข้อมูลใหม่ล่าสุดนั้นไปอย่างเงียบเชียบ โดยไม่มี Error แจ้งเตือนในระบบแม้แต่บรรทัดเดียว

2. เมื่อเข็มนาฬิกาพึ่งไม่ได้ จงพึ่งพา “เหตุและผล” (Causality)

หากเราไม่สามารถเชื่อถือเข็มนาฬิกาของแต่ละเครื่องได้ แล้วเราจะจัดระเบียบความจริงในระบบกระจายตัวได้อย่างไร?

ผู้ที่เข้ามาไขปริศนาระดับจักรวาลนี้คือนักวิทยาศาสตร์คอมพิวเตอร์ระดับตำนานเจ้าของรางวัล Turing Award ที่ชื่อว่า เลสลี ลามพอร์ต (Leslie Lamport) กับเปเปอร์ชิ้นประวัติศาสตร์ในปี 1978 เรื่อง “Time, Clocks, and the Ordering of Events in a Distributed System”

เบื้องหลังการเขียนเปเปอร์ฉบับนี้มีเกร็ดทางประวัติศาสตร์ที่น่าสนใจมาก หากเราเปิดดูบรรณานุกรม (References) ท้ายเปเปอร์ปี 1978 ของลามพอร์ต เราจะพบว่าเขามีเอกสารอ้างอิงอยู่เพียง 2 รายการเท่านั้น:

1. รายงานเทคนิคปี 1975 ของ Paul R. Johnson และ Robert H. Thomas (The maintenance of duplicate databases) ซึ่งเป็นเปเปอร์ที่เสนอให้ใช้นาฬิกาเครื่องมาตัดสินลำดับข้อมูลในฐานข้อมูลกระจายตัว ลามพอร์ตอ่านเจอจุดนี้และเห็นทันทีว่ามันมีช่องโหว่ร้ายแรง
2. ตำราฟิสิกส์ปี 1966 เรื่อง Spacetime Physics ของ Edwin F. Taylor และ John Archibald Wheeler

ลามพอร์ตซึ่งมีพื้นฐานด้านฟิสิกส์ทฤษฎีมาก่อน ได้หยิบยืมกรอบคิดเชิงเรขาคณิตของ ทฤษฎีสัมพัทธภาพพิเศษ (Special Theory of Relativity) และแผนภาพปริภูมิ-เวลา (Space-Time Diagrams) จากตำราฟิสิกส์เล่มนั้นเข้ามาผสานกับวิทยาการคอมพิวเตอร์

เขาชี้ให้เห็นว่า ในเมื่อการส่งข้อความระหว่างเซิร์ฟเวอร์ต้องใช้เวลาเดินทางผ่านเครือข่ายเสมอ เราจึงไม่สามารถนิยามคำว่า “เวลาเดียวกัน” ข้ามเครื่องได้โดยปราศจากการสื่อสาร ดังนั้น ลามพอร์ตจึงเสนอให้เปลี่ยนกระบวนทัศน์ใหม่ทั้งหมด:

“ถ้าเราไม่สามารถซิงก์เวลาจริง (Physical Time) ให้ตรงกันได้ ก็จงเลิกถามว่าเหตุการณ์นี้เกิดขึ้นตอนกี่โมง แต่ให้เปลี่ยนมาถามว่า เหตุการณ์ไหนเกิดขึ้นก่อนและส่งผลให้เกิดเหตุการณ์ไหนแทน”

นี่คือหัวใจของสิ่งที่เรียกว่า ความสัมพันธ์แบบเกิดขึ้นก่อน (Happened-Before Relation: →→) หรือการจัดลำดับด้วย เหตุและผล (Causality)

Lamport Timestamps ทำงานอย่างไร?

แทนที่จะใช้เข็มนาฬิกาที่เดินตามวินาที ลามพอร์ตสร้าง Logical Clock (นาฬิกาเชิงตรรกะ) ที่เป็นเพียงตัวเลขลำดับเดี่ยว ๆ (Counter) เช่น 1,2,3,…1,2,3,… ประจำแต่ละโหนด โดยมีกฎการทำงานที่เรียบง่ายเพียง 3 ข้อ:

1. ทุกครั้งที่โหนดเกิดเหตุการณ์ภายในเครื่องตัวเอง ให้บวกตัวเลขของตัวเองขึ้น 1 (Li=Li+1)
2. เมื่อโหนดจะส่งข้อความ (Message) ไปหาโหนดอื่น ให้แนบค่าตัวเลข Li ปัจจุบันติดไปกับข้อความนั้นด้วย
3. เมื่อโหนดปลายทางได้รับข้อความที่มีค่าป้ายเวลา t ติดมา ให้ปรับตัวเลขของตัวเองโดยเลือกค่าระหว่างเลขเดิมของตัวเองกับเลขที่ได้รับมาว่าอันไหนสูงกว่า แล้วบวกเพิ่มไป 1 เสมอ:

Lj = max⁡(Lj, t) + 1

ด้วยสมการบรรทัดเดียวที่แสนเรียบง่ายนี้ เราสามารถรับประกันได้ทันทีว่า หากเหตุการณ์ a เป็นสาเหตุให้เกิดเหตุการณ์ b (a→b) แล้ว ค่าป้ายเวลาของ a จะต้องน้อยกว่า b เสมอ (L(a) < L(b)) โดยที่เราไม่ต้องสนใจเลยว่าผลึกแร่ควอตซ์ของเซิร์ฟเวอร์เครื่องไหนจะเดินเพี้ยนไปกี่วินาที

จาก Lamport Timestamps สู่ Vector Clocks

อย่างไรก็ตาม ตัวเลขเดี่ยว ๆ ของ Lamport Timestamps ยังมีข้อจำกัดอยู่หนึ่งข้อ คือแม้เราจะรู้ว่าถ้า a→b แล้ว L(a) < L(b) แต่ในทางกลับกัน หากเราเห็นแค่ตัวเลข L(a) < L(b) เราไม่สามารถฟันธงย้อนกลับได้ว่า a เป็นสาเหตุของ b จริง ๆ หรือไม่ เพราะเหตุการณ์ทั้งสองอาจจะเกิดขึ้นพร้อม ๆ กันบนคนละเครื่องโดยไม่ได้เกี่ยวข้องกันเลย (Concurrent Events)

ในช่วงทศวรรษ 1980s นักวิจัยหลายกลุ่มจึงได้พัฒนาแนวคิดการเก็บสถานะเป็นแถวลำดับขึ้น และถูกสรุปเป็นโมเดลคณิตศาสตร์มาตรฐานอย่างชัดเจนโดย Colin Fidge (1988) และ Friedemann Mattern (1989) ในชื่อ Vector Clocks

แทนที่แต่ละโหนดจะถือตัวเลขแค่ตัวเดียว โหนดในระบบ Vector Clocks จะถือ Array ของตัวเลขที่บันทึกความก้าวหน้าของทุกโหนดในระบบไว้ด้วยกัน เช่น [Node A: 2, Node B: 1, Node C: 0]

สถาปัตยกรรม Vector Clocks นี้เองที่ถูกนำไปใช้เป็นหัวใจสำคัญในระบบฐานข้อมูลกระจายตัวระดับตำนานอย่าง Amazon Dynamo (2007) เพื่อตรวจจับความขัดแย้งของข้อมูล (Conflict Detection) ได้อย่างแม่นยำว่า ข้อมูลสองเวอร์ชันที่ถูกเขียนขึ้นมานั้น เวอร์ชันไหนเป็นผลสืบเนื่องจากอีกเวอร์ชันจริง ๆ หรือเวอร์ชันไหนที่ถูกแก้ไขชนกันพร้อม ๆ กัน เพื่อให้ระบบจัดการรวมข้อมูล (Reconciliation) ได้โดยไม่เผลอลบข้อมูลสำคัญทิ้งเหมือนยุค Last Write Wins

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

3. เวลาสัมพัทธ์ของชีวิต และแรงโน้มถ่วงบน “ดาวมิลเลอร์จำลอง”

เมื่อเราถอยออกมามองสถาปัตยกรรมของ Distributed Systems แล้วหันกลับมามองชีวิตของพวกเราเอง เราจะพบว่ามนุษย์ทุกคนต่างก็เป็นเหมือน “โหนด (Node)” แต่ละเครื่องที่กำลังรันชีวิตของตัวเองอยู่ในความเร็วที่ไม่เท่ากัน

ในทางปรัชญา อ็องรี แบร์กซอน (Henri Bergson) นักปรัชญาชาวฝรั่งเศส ได้แยกแยะความแตกต่างระหว่าง Objective Time (เวลาตามหน้าปัดนาฬิกาทางวิทยาศาสตร์) ที่ทุกวินาทีถูกซอยย่อยให้มีความยาวเท่ากันเป๊ะ กับแนวคิดเรื่อง Durée (Lived Time หรือเวลาที่ดำรงอยู่จริงในจิตสำนึกของมนุษย์)

เวลาจริงของชีวิตมนุษย์ไม่เคยวัดด้วยเสียงติ๊กต็อกของแร่ควอตซ์ แต่วัดด้วย “ความเข้มข้นของประสบการณ์และความหมาย” สามชั่วโมงที่เราได้นั่งเขียนโค้ดในสภาวะ Flow หรือนั่งพูดคุยหัวเราะกับคนที่เรารัก มักผ่านไปไวเหมือนพริบตาเดียว ในขณะที่ 15 นาทีในห้องประชุมที่ไร้จุดหมายกลับยาวนานราวกับติดอยู่บนดาวมิลเลอร์ไปเจ็ดปี

แต่โศกนาฏกรรมที่เงียบงันที่สุดของคนทำงานในโลกยุคดิจิทัลคืออะไรรู้ไหมครับ?

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

ทว่าในชีวิตจริง พวกเราหลายคนกลับ เลือกที่จะพาตัวเองลงไปติดอยู่บน “ดาวมิลเลอร์จำลอง” ด้วยความสมัครใจทุกวัน

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

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

บทสรุป: 3 แนวทางดูแลนาฬิกาชีวิตในโลกที่เวลาเดินไม่พร้อมกัน

การทำความเข้าใจธรรมชาติของเวลาในระบบกระจายตัวและภาพยนตร์ Interstellar ทิ้งบทเรียนสำคัญไว้ให้เราใช้จัดระเบียบสถาปัตยกรรมชีวิต 3 ข้อ:

1. เลิกเปรียบเทียบนาฬิกาชีวิตของตัวเองกับคนอื่น (Accept Your Own Local Clock): ในเมื่อแม้แต่เซิร์ฟเวอร์ระดับโลกยังไม่มี Global Clock ที่เดินพร้อมกัน ชีวิตมนุษย์ก็เช่นกัน อย่าเอาป้ายเวลา (Timestamp) ความสำเร็จของคนอื่นมาตัดสินคุณค่าของตัวเอง บางโหนดอาจประมวลผลเสร็จเร็ว บางโหนดอาจต้องใช้เวลาบ่มเพาะนานกว่า จงเคารพจังหวะและเส้นเวลาของตัวเอง
2. ซิงก์ความสัมพันธ์ด้วยการส่งสารที่มีความหมาย (Sync Through Meaningful Causality): เหมือนกับหลักการของ Logical Clocks ที่นาฬิกาของสองโหนดจะปรับจูนเข้าหากันได้ก็ต่อเมื่อมีการส่ง Message หากันเท่านั้น ความสัมพันธ์ในทีม ในครอบครัว หรือกับคนรัก จะไม่มีวันเดินไปพร้อมกันได้เลยหากเราปล่อยให้ต่างคนต่างอยู่โดยไร้การสื่อสาร จงหมั่นส่งสัญญาณแห่งความใส่ใจ รับฟังกัน และสร้างเหตุและผลที่ดีร่วมกันอย่างสม่ำเสมอ
3. ระวังแรงโน้มถ่วงของสิ่งที่ไม่สำคัญ (Beware of Artificial Time Dilation): ใน Interstellar สิ่งเดียวที่สามารถเดินทางทะลุมิติของกาลเวลาและแรงโน้มถ่วงของหลุมดำออกมาได้ คือความรักและความผูกพันที่ถูกส่งผ่านรหัสมอร์สบนเข็มนาฬิกา ในทุก ๆ วัน ก่อนที่เราจะยอมให้เรื่องวุ่นวายที่ไม่จำเป็นดึงเราลงไปติดอยู่บนดาวมิลเลอร์ จงถามตัวเองเสมอว่าอะไรคือสิ่งที่มีความหมายที่สุดในชีวิต แล้วใช้เวลาอันมีค่าอยู่กับสิ่งนั้นและคนเหล่านั้น ก่อนที่เข็มนาฬิกาจะเดินผ่านไปครับ

📚 เอกสารอ้างอิง (References & Further Reading)

• Lamport, L. (1978). Time, Clocks, and the Ordering of Events in a Distributed System. Communications of the ACM, 21(7), 558–565.
• Taylor, E. F., & Wheeler, J. A. (1966). Spacetime Physics. W. H. Freeman and Company.
• Johnson, P. R., & Thomas, R. H. (1975). The Maintenance of Duplicate Databases. ARPA Network Working Group Request for Comments (RFC 677).
• Fidge, C. J. (1988). Timestamps in Message-Passing Systems That Preserve the Partial Ordering. Proceedings of the 11th Australian Computer Science Conference.
• Mattern, F. (1989). Virtual Time and Global States of Distributed Systems. Parallel and Distributed Algorithms,215–226.
• DeCandia, G., et al. (2007). Dynamo: Amazon’s Highly Available Key-Value Store. ACM SIGOPS Operating Systems Review (SOSP ‘07).
• Bergson, H. (1889). Time and Free Will: An Essay on the Immediate Data of Consciousness (Essai sur les données immédiates de la conscience).

บทความนี้เรียบเรียงจากเนื้อหาในรายการ Uncle Quin Podcast EP.65: Interstellar & ปริศนาเวลาในระบบกระจายตัว สามารถรับฟังฉบับเต็มได้ทาง Spotify และ Apple Podcasts ครับ

หากคุณชอบบทความแนวการเชื่อมโยงปรัชญาเข้ากับการทำงานในโลกยุคใหม่ ฝากกดเลิฟ กดแชร์ และกดติดตามช่องของผมด้วยนะครับ!

• Spotify
• YouTube

Interstellar & ปริศนาเวลาในระบบกระจายตัว was originally published in odds.team on Medium, where people are continuing the conversation by highlighting and responding to this story.

“การล้มลงครั้งแรกไม่ใช่จุดจบของภารกิจ แต่มันคือขั้นตอนของการเก็บข้อมูล (Data Collection)”

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

แต่ถ้าเราลองถอดหมวกของเกมเมอร์ออกชั่วคราว แล้วสวมแว่นตาของ System Architect และคนทำงานสายวิศวกรรมซอฟต์แวร์มองกลับเข้าไปในเกมนี้ เราจะพบความจริงที่น่าทึ่งว่า กลไกการออกแบบของ Monster Hunter แท้จริงแล้วคือแบบจำลองชั้นยอดของการบริหารจัดการระบบที่ซับซ้อน (Complex Systems) การตัดสินใจเชิงโครงสร้าง และจิตวิทยาการทำงานร่วมกันเป็นทีมในสภาวะวิกฤต

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

1. ทำไมปาร์ตี้ 4 คน ถึงล้มมังกรโบราณได้ดีกว่ากองทัพ 100 คน? (Brooks’s Law & Two-Pizza Team)

เคยสงสัยไหมครับว่า ในเมื่อโลกของ Monster Hunter ต้องเผชิญกับภัยพิบัติระดับมังกรโบราณที่มีพลังทำลายล้างสูงพอจะถล่มเมืองทั้งเมืองได้ ทำไมสมาคมฮันเตอร์ (The Guild) ถึงอนุญาตให้จัดปาร์ตี้ออกไปทำภารกิจได้สูงสุดแค่ 4 คน เท่านั้น?ทำไมเขาไม่ส่งกองทัพฮันเตอร์สัก 50 หรือ 100 คนออกไปรุมตีพร้อมกันให้จบเร็ว ๆ?

คำตอบในทางเกมเพลย์นั้นชัดเจนมาก ขนาดออกไปกันแค่ 4 คน หากยืนตำแหน่งไม่ดีหรือจังหวะไม่สอดคล้องกัน อาวุธของเรายังฟันไปโดนเพื่อนร่วมทีมจนเสียจังหวะ (Friendly Fire / Flinching) อยู่บ่อยครั้ง ลองนึกภาพฮันเตอร์ 50 คนวิ่งถืออาวุธเข้าไปรุมฟันที่ขาของมอนสเตอร์พร้อมกัน สิ่งที่จะเกิดขึ้นคือความโกลาหลที่ไม่มีใครขยับตัวได้ มองไม่เห็นภาษากายของมอนสเตอร์ และเมื่อมอนสเตอร์พ่นไฟกวาดเพียงครั้งเดียว ทั้งกองทัพก็จะพ่ายแพ้พร้อมกันทันที

ในโลกของวิศวกรรมซอฟต์แวร์ ปรากฏการณ์นี้คือภาพสะท้อนของกฎคลาสสิกที่ชื่อว่า Brooks’s Law (กฎของบรูคส์) จากหนังสือระดับตำนาน The Mythical Man-Month ของ Fred Brooks ที่กล่าวไว้ว่า “การเพิ่มคนเข้าไปในโปรเจกต์ซอฟต์แวร์ที่กำลังล่าช้า จะยิ่งทำให้โปรเจกต์นั้นล่าช้ากว่าเดิม”

เหตุผลเป็นเพราะเมื่อจำนวนคนในทีมเพิ่มขึ้น ต้นทุนในการสื่อสารและการประสานงาน (Communication Overhead) ไม่ได้เพิ่มขึ้นแบบเส้นตรง แต่จะพุ่งทะยานขึ้นแบบทวีคูณตามสูตร:

Communication Channels = N(N−1)/2

• ในปาร์ตี้ฮันเตอร์ 4 คน เส้นทางการสื่อสารระหว่างกันมีเพียง 6 เส้นทาง ทุกคนมองเห็นกัน รู้หน้าที่ของกันและกันโดยแทบไม่ต้องพูด
• แต่ถ้าเราอัดวิศวกร 20 คน เข้าไปในห้อง War Room ตอนเซิร์ฟเวอร์ล่ม เส้นทางการสื่อสารจะพุ่งขึ้นไปถึง 190 เส้นทางทันที ผลลัพธ์คือการแย่งกันพูด การแก้โค้ดทับกัน และการเหยียบเท้ากันเองจนระบบพังหนักกว่าเดิม

เมื่อต้องรับมือกับสถาปัตยกรรมแกนกลางที่ซับซ้อน หรือการกู้วิกฤตระบบล่มตอนตีสอง ทีมที่แข็งแกร่งที่สุดจึงไม่ใช่กองทัพขนาดใหญ่ แต่คือ Cross-Functional Squad ขนาดกะทัดรัด (3–5 คน หรือ Two-Pizza Team) ที่แต่ละคนถือ “อาวุธ” คนละสายอย่างเชี่ยวชาญ — คนหนึ่งคุม Infrastructure, คนหนึ่งแม่น Database, อีกคนเจาะลึก Application Logic — โดยที่ทุกคนไว้ใจพื้นที่และจังหวะของกันและกันอย่างสมบูรณ์แบบ

2. ดาบใหญ่ที่ง้างแล้วหยุดไม่ได้ กับศิลปะการอ่านสัญญาณเตือนล่วงหน้า (Animation Commitment & Leading Indicators)

เสน่ห์อันเป็นเอกลักษณ์ที่สุดอย่างหนึ่งของ Monster Hunter ที่มักทำให้ผู้เล่นหน้าใหม่หงุดหงิด แต่ทำให้ผู้เล่นเก๋า ๆ หลงรักจนถอนตัวไม่ขึ้น คือระบบที่เรียกว่า Animation Commitment

ในเกมแอ็กชันทั่วไป เวลาเรากดปุ่มโจมตีแล้วเห็นศัตรูกำลังจะสวนกลับ เราสามารถกดปุ่มกลิ้งหลบเพื่อยกเลิกท่าโจมตี (Cancel Animation) ได้ทันที แต่ใน Monster Hunter โดยเฉพาะเมื่อคุณถืออาวุธหนักอย่าง “ดาบใหญ่” (Great Sword) ทันทีที่คุณตัดสินใจกดง้างชาร์จดาบในท่าไม้ตาย True Charged Slash คุณจะไม่สามารถกดยกเลิกกลางคันได้เลย คุณต้องยอมรับผลลัพธ์ของการตัดสินใจนั้นจนกว่าดาบจะฟาดลงพื้นเสร็จสมบูรณ์

นี่คือบทเรียนชั้นครูของสถาปนิกซอฟต์แวร์ที่สอนให้เรารู้ว่า “การกระทำที่ทรงพลังที่สุด มักมาพร้อมกับราคาของความยืดหยุ่นที่ต้องจ่ายเสมอ”

ในทางวิศวกรรมระบบและการบริหารธุรกิจ เราแบ่งการตัดสินใจออกเป็น 2 ประเภท:

1. Two-Way Doors (ประตูที่เดินเข้าแล้วถอยกลับออกมาได้): เปรียบเหมือนอาวุธเบาอย่างดาบคู่หรือดาบโล่ ที่ฟันได้ไวและกลิ้งหลบเพื่อเปลี่ยนทิศทางได้ตลอดเวลา เช่น การปรับแต่ง UI เล็กน้อย หรือการเขียนฟังก์ชันย่อยที่สามารถทำ Rollback ได้ในไม่กี่วินาที
2. One-Way Doors (ประตูที่เดินผ่านแล้วหันหลังกลับไม่ได้ง่าย ๆ): เปรียบเหมือนการง้างดาบใหญ่ เช่น การเลือกโครงสร้าง Database หลักของบริษัท, การเปลี่ยนสถาปัตยกรรมจาก Monolith เป็น Microservices, หรือการประกาศใช้ Public API ที่ลูกค้าภายนอกต้องมาเชื่อมต่อ เมื่อคุณฟันดาบลงไปใน Production แล้ว คุณไม่สามารถกด Cancel กลางอากาศได้ หากกะจังหวะผิด สิ่งที่ตามมาคือการโดนมอนสเตอร์ (หรือ Technical Debt) ฟาดกลับอย่างรุนแรงในจังหวะที่คุณขยับตัวหนีไม่ได้

อ่านท่ามอนสเตอร์ 3 วินาทีล่วงหน้า ด้วย Leading Indicators

คำถามคือ ฮันเตอร์ระดับพระกาฬที่ใช้ดาบใหญ่อันเชื่องช้า สามารถชาร์จดาบ 3 จังหวะแล้วฟาดลงไปกลางหัวมอนสเตอร์ที่เคลื่อนไหวตลอดเวลาได้อย่างไร?

คำตอบคือ พวกเขาไม่ได้ฟันไปยังจุดที่มอนสเตอร์ “กำลังยืนอยู่” แต่ฟันดักไปยังจุดที่มอนสเตอร์ “กำลังจะหันกลับมาในอีก 3 วินาทีข้างหน้า” ต่างหาก และสิ่งที่ทำให้พวกเขารู้อนาคตล่วงหน้าได้ คือการอ่าน Telegraphing (ภาษากายของมอนสเตอร์) เช่น การเห็นมอนสเตอร์สูดหายใจเข้าลึก ๆ พร้อมขยับปีกไปด้านหลังเล็กน้อย ซึ่งเป็นสัญญาณเตือนว่าอีก 2 วินาทีมันจะพ่นลูกไฟและเอาหัวมุดลงตรงจุดเดิมแน่นอน

ในงาน Site Reliability Engineering (SRE) และการดูแลระบบ ทักษะการอ่านท่ามอนสเตอร์นี้คือการแยกแยะระหว่างตัวชี้วัด 2 ชนิดบนหน้าจอ Monitoring:

• Lagging Indicators (ตัวชี้วัดปลายเหตุ): เช่น กราฟแจ้งเตือนว่า HTTP 500 Internal Server Error พุ่งทะลุเพดาน หรือ CPU Utilization 100% ไปเรียบร้อยแล้ว สิ่งนี้เหมือนการที่มอนสเตอร์พ่นไฟใส่หน้าเราจนตัวปลิวไปแล้ว เราทำได้แค่วิ่งหนีไปกินยาเติมเลือดตามแก้ปัญหาเฉพาะหน้า
• Leading Indicators (สัญญาณเตือนล่วงหน้า): คืออาการขยับปีกเล็ก ๆ ของระบบก่อนที่พายุจะเข้า เช่น อัตราการทำ Garbage Collection ใน Memory ที่เริ่มถี่ขึ้นผิดปกติ, Connection Pool ที่เริ่มค้างนานขึ้นทีละนิด, หรือขนาดของ Queue ที่ระบายออกช้ากว่าขาเข้าเพียงเสี้ยววินาที

วิศวกรที่เก่งกาจจะไม่รอให้สัญญาณไฟแดงของ Lagging Indicators ดังขึ้น แต่จะคอยเฝ้าสังเกต Leading Indicators เหล่านี้เพื่ออ่านการเคลื่อนไหวของระบบล่วงหน้า และขยับตัวไปขยายทรัพยากรหรือแก้คอขวดได้ทัน ก่อนที่ผู้ใช้จริงจะทันรู้ตัวด้วยซ้ำว่ามอนสเตอร์กำลังจะพ่นไฟ

3. ปรัชญาแห่งการ “นอนแมวกลับแคมป์” และสภาวะ Flow State (Blameless Post-Mortem & Psychological Safety)

ไม่ว่าคุณจะเป็นฮันเตอร์ที่เก่งกาจมาจากไหน ทุกคนที่เล่นเกมนี้ล้วนต้องเคยผ่านประสบการณ์เดียวกัน นั่นคือการพลาดท่าโดนมอนสเตอร์โจมตีจนหลอดพลังชีวิตหมดเกลี้ยง แล้วมีแก๊งแมวตัวเล็ก ๆ เข็นรถไม้มาแบกร่างอันสลบเหมือดของเรากลับไปเททิ้งที่แคมป์ หรือที่เหล่าเกมเมอร์เรียกกันติดปากว่า “นอนแมว” (Carting)

แต่ลองสังเกตการออกแบบของเกมดูสิครับ ทำไมเวลาเราพลาดท่าสลบครั้งแรก เกมถึงไม่ขึ้นหน้าจอสีดำพร้อมตัวอักษรสีแดงน่ากลัวว่า “YOU DIED — GAME OVER” แล้วตัดจบภารกิจทันที?

ทำไมผู้สร้างเกมถึงเลือกใช้ภาพน่ารัก ๆ ของแมวเข็นรถกลับมาส่งเราที่แคมป์ ให้โอกาสปาร์ตี้พลาดได้ถึง 2 ครั้ง (ล้มครั้งที่ 3 ถึงจะเควสต์ล้มเหลว) แถมเมื่อตื่นขึ้นมาที่แคมป์ เรายังไม่เสียไอเทมในกระเป๋า สามารถเดินเข้าเต็นท์ไปเปลี่ยนชุดเกราะให้กันธาตุได้ดีขึ้น เปลี่ยนอาวุธ กินอาหารเติมพลัง แล้ววิ่งกลับออกไปสู้กับมอนสเตอร์ตัวเดิมที่เลือดลดไปแล้วต่อได้ทันที?

นี่คือปรัชญาการออกแบบระบบความยืดหยุ่น (Resilience) และวัฒนธรรมองค์กรที่ลึกซึ้งอย่างยิ่ง เกมกำลังบอกเราว่า “การล้มลงครั้งแรกไม่ใช่ความพ่ายแพ้ แต่มันคือกระบวนการเก็บข้อมูล (Data Collection)”

จากแคมป์นักล่า สู่ Blameless Post-Mortem

ลองจินตนาการถึงปาร์ตี้ล่าแย้ 2 ทีมที่เจอมอนสเตอร์ระดับโหดหินตัวเดียวกัน:

• ทีม A (วัฒนธรรมหาคนผิด): ทันทีที่เพื่อนคนหนึ่งในทีมพลาดโดนท่าไม้ตายจนนอนแมวครั้งแรก เพื่อนอีก 3 คนเปิดไมค์รุมด่าทันทีว่า “เล่นโง่ ๆ แบบนี้มาเป็นตัวถ่วงทำไม!” เมื่อเพื่อนคนนั้นฟื้นที่แคมป์แล้ววิ่งกลับมาสู้ต่อ ความกลัวที่จะโดนด่าซ้ำจะทำให้มือของเขาสั่น เกร็งจนไม่กล้าเข้าไปโจมตี หรือแย่ที่สุดคือกดออกจากเกม (Leave Quest) ทิ้งทีมไปเลย
• ทีม B (วัฒนธรรม Blameless & Psychological Safety): เมื่อเพื่อนพลาดนอนแมว คนในทีมบอกกันว่า “ไม่เป็นไร ท่านี้วงกว้างจริง ตอนมันกางปีกต้องรีบเก็บอาวุธแล้วพุ่งหลบนะ เดี๋ยวรอบนี้พวกเราช่วยกดผงฮีลหมู่ประคองให้ นายเติมยาแล้ววิ่งตามมาลุยต่อเลย!”

ในโลกของการพัฒนาซอฟต์แวร์ ทีม B คือหัวใจของวัฒนธรรม Blameless Post-Mortem (การสรุปบทเรียนหลังระบบล่มโดยไม่กล่าวโทษตัวบุคคล) และ Psychological Safety (พื้นที่ปลอดภัยทางจิตวิทยา)

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

ในทางกลับกัน เมื่อคนทำงานรู้ว่าเขามี “แคมป์ที่ปลอดภัย” ให้กลับมาตั้งหลักได้เสมอ และทุกครั้งที่ล้มลง ทีมจะช่วยกันวิเคราะห์ “ท่าของมอนสเตอร์” เพื่อปรับปรุงระบบป้องกันให้ดีขึ้น ความกลัวจะแปรเปลี่ยนเป็นการเรียนรู้ที่รวดเร็ว และนำพาทั้งทีมเข้าสู่สภาวะที่นักจิตวิทยา Mihaly Csikszentmihalyi เรียกว่า Flow State — จุดที่ความท้าทายระดับสูงสุดหลอมรวมเข้ากับทักษะที่พัฒนาขึ้นอย่างต่อเนื่อง จนการต่อสู้กับปัญหายาก ๆ กลายเป็นเหมือนการเต้นรำที่ลื่นไหลและงดงาม

บทสรุปหน้ากองไฟ: คัมภีร์ฮันเตอร์สำหรับการทำงานและชีวิต

ก่อนจะปิดเต็นท์และก้าวออกไปรับเควสต์ใหม่ในเช้าวันพรุ่งนี้ ลองพก 3 หลักคิดนี้ติดกระเป๋าไว้เหมือนไอเทมประจำตัวครับ:

1. Small Squad, Deep Synergy (จัดปาร์ตี้ให้เล็ก แต่เชื่อมต่อกันให้ลึก): อย่าหลงคิดว่าปัญหาที่ใหญ่ต้องแก้ด้วยการสุมคนจำนวนมากลงไปตามกับดักของ Brooks’s Law จงสร้างทีมขนาดเล็กที่แต่ละคนเชี่ยวชาญอาวุธของตัวเอง มีความหลากหลายแต่เกื้อหนุนกัน และสื่อสารกันด้วยความไว้วางใจ
2. Respect Commitment & Read the Tells (รู้น้ำหนักอาวุธ และอ่านสัญญาณเตือนล่วงหน้า): ก่อนจะง้างดาบใหญ่ตัดสินใจในเรื่องที่เป็น One-Way Door จงฝึกสังเกต Leading Indicators หรือสัญญาณเตือนเล็ก ๆ ในระบบและในชีวิตให้ขาด อย่ารอให้ไฟลุกท่วมหน้าจอแล้วค่อยวิ่งหาทางแก้
3. Embrace the Cart as Data (เปลี่ยนการ “นอนแมว” ให้เป็นข้อมูลเพื่อการเติบโต): ไม่มีฮันเตอร์คนไหนปราบมังกรโบราณได้โดยไม่เคยสลบกลับแคมป์ หากวันนี้โปรเจกต์ของคุณพัง หรือคุณตัดสินใจผิดพลาดในชีวิต อย่าเพิ่งเกลียดตัวเองและอย่าเพิ่งโทษเพื่อนร่วมทาง ลุกขึ้นมาปัดฝุ่น กินอาหารดี ๆ ให้มีแรง ปรับแต่งกลยุทธ์ในเต็นท์ใหม่ แล้ววิ่งกลับออกไปสู้ต่อด้วยความเข้าใจโลกที่ลึกซึ้งกว่าเดิมครับ

🎧 ติดตามฟังเรื่องราวการผ่าตัดสถาปัตยกรรมซอฟต์แวร์และปรัชญาชีวิตฉบับเต็มได้ใน: รายการ Uncle Quin Podcast EP.64 | ปาร์ตี้ล่าแย้กับวิศวกรรมระบบ (The Guild & The Hunt)

หากคุณชอบบทความแนวการเชื่อมโยงปรัชญาเข้ากับการทำงานในโลกยุคใหม่ ฝากกดเลิฟ กดแชร์ และกดติดตามช่องของผมด้วยนะครับ!

• Spotify
• YouTube

ปาร์ตี้ล่าแย้กับวิศวกรรมระบบ (The Guild & The Hunt) was originally published in odds.team on Medium, where people are continuing the conversation by highlighting and responding to this story.

หลาย ๆ คนอาจจะผ่านการทำงานในรูปแบบ “ทีม” มา ไม่มากก็น้อยใช่ไหมครับ ไม่ว่าจะเป็นในบริบท “สมาชิกของทีม” หรือ “ผู้นำ” ซึ่ง 2 บริบทนี้จะมีหน้าที่และความรับผิดชอบที่ค่อนข้างต่างกัน

ทำยังไงให้เราหรือทีมสามารถทำงานร่วมกันได้ลื่นไหล โดยที่งานออกมามีคุณภาพมากที่สุด?

การจะทำได้นั้น พวกเราจะต้องเข้าใจซึ่งกันและกัน ได้ใช้เวลาร่วมกัน และเข้าใจจุดมุ่งหมายเดียวกัน

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

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

แล้วเราจะสังเกตสัญญาณเหล่านี้ได้อย่างไร ก่อนเริ่มแก้ปัญหา?

ผมได้มีโอกาสเรียนคลาส Engineering Manager กับพี่ <ปุ๊ก> ซึ่งทำให้เห็น Career Path ที่ชัดเจน เข้าใจบทบาทและความรับผิดชอบ รวมถึงวิธี Take Action เมื่อเกิดปัญหา

บทความนี้จึงนำเนื้อหาบางส่วนมาเรียบเรียงและส่งต่อผ่านมุมมองของผมเอง หวังว่าจะเป็นประโยชน์กับหลาย ๆ คนนะครับ :)

5 สิ่งที่ช่วยสร้าง Teamwork ที่ดี

หัวใจสำคัญของทีมที่มีประสิทธิภาพไม่ได้ขึ้นอยู่กับว่า “ใคร” อยู่ในทีม แต่ขึ้นอยู่กับ “วิธีการ” ที่คนในทีมทำงานร่วมกัน

1. Psychological Safety — ความรู้สึกปลอดภัยทางจิตวิทยา

ปัจจัยสำคัญที่สุดคือการสร้าง “พื้นที่ปลอดภัย” ให้คนในทีมกล้าเป็นตัวเอง กล้าพูดความจริง โดยไม่ต้องใส่หน้ากาก และไม่กลัวว่าคำว่า “ไม่รู้” หรือ “ทำพลาดไปแล้ว” จะทำให้โดนด่า ดูถูก หรือถูกมองว่าไม่เก่ง

ทีมที่มี Psychological Safety ที่ดี

• ทุกคนกล้าเสนอไอเดียที่ยังไม่สมบูรณ์ (Half-baked ideas)
• กล้าแย้งไอเดียของซีเนียร์ในห้องประชุม
• เมื่อเกิดปัญหา ทำ Blameless Postmortem: ไม่ล่าตัวคนผิด แต่ถามว่า “ระบบเรามีช่องโหว่ตรงไหน และจะป้องกันไม่ให้เกิดซ้ำได้อย่างไร”

สัญญาณเตือน

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

2. Dependability — ความพึ่งพาได้และการรักษาคำพูด

ข้อนี้ไม่ใช่เรื่องของการทำงานเร็ว แต่คือเรื่องของ “ความไว้ใจ” (Trust) ทุกคนในทีมเชื่อใจได้ว่างานที่ส่งมอบจะมีคุณภาพและเสร็จตามคำสัญญา ที่สำคัญคือคำว่า “งานเสร็จ” (Done) ต้องหมายถึงสิ่งเดียวกัน ไม่ใช่เสร็จแค่ในเครื่องของตัวเอง

ทีมที่มี Dependability ที่ดี

• รู้วันส่งมอบที่แน่นอน
• เมื่อรู้ว่าจะมีปัญหาเร่งด่วนกระทบกำหนดการ กล้ายกมือขอความช่วยเหลือตั้งแต่วันแรกที่รู้

สัญญาณเตือน

• แจ้งทีมว่า “ใกล้เสร็จแล้ว” มา 3–4 วันติดกัน
• ติดปัญหาใหญ่มาตั้งแต่วันจันทร์ แต่เงียบไว้แล้วค่อยบอกทีมในวันศุกร์ใกล้เวลาส่งมอบ

3. Structure & Clarity — โครงสร้างและความชัดเจน

เปรียบเหมือน “เข็มทิศและแผนที่การเดินทาง” ทุกคนในทีมรู้ว่าจุดหมายปลายทางคืออะไร งานชิ้นนี้ใครเป็นผู้รับผิดชอบ (Owner) และมีเกณฑ์ความสำเร็จ (Acceptance Criteria) ที่วัดผลได้ชัดเจน โดยไม่ต้องเดาใจกัน

ทีมที่มีความชัดเจน

• งาน 1 ชิ้นมี Owner เพียง 1 คนที่ชัดเจน
• มีเกณฑ์บอกชัดว่าเทสผ่านอย่างไร และส่งมอบแบบไหนจึงเรียกว่างานเสร็จสมบูรณ์

สัญญาณเตือน

• เนื้อหางานเขียนสั้นและลอย เช่น “Fix login” โดยไม่มีรายละเอียด
• ไม่มีใครรู้ว่าใครต้องรับผิดชอบหลัก จนงานไม่เดินเพราะคิดว่าอีกคนทำ

4. Meaning — ความหมายต่องาน: ผลต่อตัวเรา

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

ทีมที่มี Meaning ดี

• ทีมหรือหัวหน้าเข้าใจเป้าหมายชีวิตของน้อง ๆ
• คอยป้อนงานที่ท้าทาย เพื่อให้ได้ทดลองใช้ทักษะใหม่ ๆ และมองย้อนกลับมาแล้วภูมิใจว่าตัวเองเก่งขึ้น

สัญญาณเตือน

• ทำงานตามที่ได้รับมอบหมายไปวัน ๆ
• ผ่านไป 6 เดือนแล้วยังไม่รู้ว่าตัวเองเก่งขึ้นตรงไหน หรือได้ทำแต่งานซ้ำ ๆ เพราะ “ทำได้เร็วอยู่แล้ว”

5. Impact — ผลกระทบต่องาน: ผลต่อผู้อื่น

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

ทีมที่มี Impact ชัดเจน

• พูดได้เต็มปากว่า “งานปรับปรุง Caching ครั้งนี้ ช่วยลดเวลาโหลดหน้าชำระเงินจาก 4 วินาทีเหลือ 1.5 วินาที ทำให้ผู้ใช้งานซื้อของลื่นขึ้น และช่วยลดงานแจ้งปัญหาของทีม Support ลงได้ 30%”

สัญญาณเตือน

• ทำงานเสร็จแล้วก็ย้ายไปทำงานถัดไปทันที โดยไม่กลับไปดูว่าฟีเจอร์นั้นมีคนใช้ไหม หรือสร้างประโยชน์จริงหรือเปล่า

สรุป: 5 เสาหลักของทีมที่ดี

• Psychological Safety — กล้าพูดความจริง
• Dependability — รักษาคำพูด
• Structure & Clarity — เป้าหมายและหน้าที่ชัดเจน
• Meaning — ตอบได้ว่างานนี้ทำให้เราเติบโตอย่างไร
• Impact — ตอบได้ว่างานนี้ช่วยให้ชีวิตคนอื่นดีขึ้นอย่างไร

อยากลอง “วินิจฉัยทีม” ของคุณจากโจทย์หรือไม่? ลองทำ Quiz Team Doctor ได้ที่นี่

บทส่งท้าย

ไม่ว่าคุณจะเป็นผู้นำหรือสมาชิกในทีม “ทีมที่ดี” เริ่มต้นที่ตัวเราเสมอ การสร้าง Team Dynamics ที่แข็งแกร่งไม่ใช่ภาระหน้าที่ของ Engineering Manager หรือ Team Lead เพียงผู้เดียว เพราะบรรยากาศ ความไว้เนื้อเชื่อใจ และวัฒนธรรมของทีม เกิดจากพฤติกรรมและการกระทำเล็ก ๆ น้อย ๆ ของพวกเราทุกคนในทุก ๆ วัน

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

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

จงออกไปเป็นทั้งเพื่อนร่วมงาน และผู้นำ ในแบบที่คุณเคยอยากมีในวันแรกที่เริ่มทำงานครับ 🕊️🤍

นี่…ทีมฉันเป็นอะไรไปนะ!! was originally published in odds.team on Medium, where people are continuing the conversation by highlighting and responding to this story.

ก่อนหน้านี้ผมเจอโพสต์หนึ่งถามว่า สำหรับคนที่เคยใช้แต่ OOP จะเริ่มต้นกับ Functional Programming ควรเริ่มยังไงดี

ผมชอบคำตอบที่ตัวเองตอบไป เลยอยากเอามาจดเก็บไว้

ฝันร้ายของโปรแกรมเมอร์

ก่อนจะเข้าไปใน programming แต่ละ paradigm ผมอยากเริ่มต้นที่ปัญหาก่อน

หนึ่งในปัญหาที่หลอกหลอนโปรแกรมเมอร์มากที่สุด คือ บั๊กบน production ที่เกิดจาก shared mutable state โดยเฉพาะ global variable เพราะ global variable คือตัวแปรที่โค้ดหลายส่วนของโปรแกรมสามารถเข้าถึงและแก้ไขได้ นั่นแปลว่า ถ้าค่าของมันผิดขึ้นมา โค้ดที่เป็นผู้ต้องสงสัยอาจกระจายอยู่ทั่วทั้งระบบ

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

ถ้ามองผ่านปัญหา shared mutable state นี้ OOP และ FP เป็นสองแนวทางที่จัดการกับปัญหาคล้าย ๆ กัน แต่ใช้วิธีต่างกัน

OOP แก้ปัญหายังไง?

ถ้ากลับไปดูภาษาโปรแกรมมิ่งเก่า ๆ อย่าง assembly ซึ่งเป็น imperative programming เราจะเห็นการเขียนโปรแกรมในรูปแบบชุดคำสั่งเพื่อสั่งงานเครื่องคอมพิวเตอร์ เช่น เอาตัวเลขนี้ไปเก็บในช่องนั้น ย้ายค่าจากช่องนั้นไปช่องนี้ หรือเอาค่าจาก 2 ช่องมาบวกกัน เป็นต้น

เมื่อโปรแกรมใหญ่ขึ้น ถ้า state ต่าง ๆ ถูกเปิดให้โค้ดทุกส่วนเข้าถึงและแก้ไขได้ การดูแลโปรแกรมก็จะยากขึ้นเรื่อย ๆ

หนึ่งในแนวคิดสำคัญของ Object-Oriented Programming คือการเอา state กับ behavior ที่เกี่ยวข้องกันมาอยู่ในขอบเขตเดียวกัน แล้วซ่อนรายละเอียดภายในเอาไว้

เช่น ถ้าเรามี Object Student ข้อมูลต่าง ๆ ของ Student ไม่ว่าจะเป็นชื่อ เกรดเฉลี่ย หรือชั้นปี ก็อยู่กับ Student และพวกฟังก์ชันที่ใช้จัดการข้อมูลเหล่านี้ก็อยู่กับ Student เช่นกัน เราเรียกฟังก์ชันเหล่านี้ว่า method

แทนที่โค้ดทั้งระบบจะเข้ามาแก้ข้อมูลของ Student โดยตรง เราสามารถกำหนดได้ว่าใครเห็นอะไรได้ และจะเปลี่ยน state ผ่านทางไหน

พอเราจำกัด scope และซ่อน state ไว้ ถ้า Student มีค่าอะไรบางอย่างผิดพลาด ผู้ต้องสงสัยก็แคบลง เพราะโค้ดภายนอกไม่สามารถเข้ามาแก้ state ภายในได้ตามใจ

พูดง่าย ๆ คือ OOP ไม่ได้พยายามกำจัด state ที่เปลี่ยนแปลงได้ แต่พยายามควบคุมว่า ใครมีสิทธิ์เข้าถึงและเปลี่ยน state นั้น

นอกจาก scope แล้ว Object ยังมี life cycle ของตัวเองด้วย เมื่อ Object นั้นไม่ถูกใช้งานแล้ว ระบบก็สามารถจัดการ memory ที่เกี่ยวข้องกับมันได้

FP แก้ปัญหายังไง?

ถ้า OOP พยายามควบคุมว่าใครแก้ state ได้บ้าง Functional Programming ไปอีกทาง คือพยายามลดการแก้ state ลงให้มากที่สุดตั้งแต่แรก

ถ้าจะพูดเล่น ๆ แบบสุดโต่งหน่อย คือ

OOP พยายามแบน global
FP พยายามแบนการเปลี่ยนค่า variable

Functional Programming ให้ความสำคัญกับ immutability คือ เมื่อข้อมูลถูกสร้างขึ้นมาแล้ว เราพยายามไม่แก้ค่าของมัน แต่สร้างค่าใหม่จากค่าเดิมแทน

เช่น ถ้ามี

x = 1

แทนที่จะเปลี่ยน x จาก 1 เป็น 2 เราจะสร้างค่าใหม่ขึ้นมา

x = 1
y = x + 1

x ก็ยังคงเป็น 1 เหมือนเดิม

อีกแนวคิดสำคัญคือ pure function ซึ่งเป็น function ที่ผลลัพธ์ขึ้นอยู่กับ input ที่รับเข้ามา ถ้า input เหมือนเดิม ก็ควรให้ output เหมือนเดิม และไม่แอบไปเปลี่ยนแปลง state ข้างนอก function

ลองนึกภาพว่าเรามี

input
  ↓
function
  ↓
output

สิ่งที่เกิดขึ้นใน function สามารถทำความเข้าใจได้จาก input และ output ของมัน โดยไม่ต้องตามไปดูว่า global variable ตัวไหนเพิ่งถูกแก้มาก่อนหน้านี้

ถ้าระหว่างทางต้องคำนวณหรือเก็บค่าใหม่ เราก็สร้างค่าใหม่ขึ้นมา แทนที่จะกลับไปแก้ค่าเดิม

ผลที่ตามมาคือ code ส่วนหนึ่งของเราจะ predictable มากขึ้น และเหตุผลเกี่ยวกับมันได้ง่ายขึ้น

FP กับการย้อนเวลา

ผลพลอยได้ที่น่าสนใจมากของ immutable data คือ มันทำให้การย้อนกลับไปดู state ในอดีตง่ายขึ้นมาก

สมมติว่าโปรแกรมมี state แบบนี้

state1
  ↓
state2
  ↓
state3

ถ้าเราใช้ mutable state เราอาจมี Object เดียวที่ถูกแก้ไปเรื่อย ๆ

state
  ↓ mutate
state
  ↓ mutate
state

ค่าเก่าถูกเขียนทับไปแล้ว ถ้าอยากรู้ว่าเมื่อก่อนมันเป็นอะไร เราต้องมี mechanism เพิ่ม เช่น log, snapshot หรือ undo history

แต่ถ้าเราใช้ immutable data เราสามารถสร้าง state ใหม่จาก state เดิมได้

state1 = ...
state2 = update(state1)
state3 = update(state2)

โดย state1 และ state2 ยังอยู่เหมือนเดิม

ดังนั้นถ้าเราอยากย้อนกลับไปดูว่า ตอนนั้นโปรแกรมอยู่ใน state ไหน เราก็สามารถกลับไปดู state เก่าได้

นี่คือเหตุผลว่าทำไมระบบที่ใช้แนวคิด Functional Programming บางประเภทถึงทำสิ่งอย่าง time-travel debugging ได้ง่าย

มันไม่ได้ย้อน program pointer กลับไปในอดีตจริง ๆ แต่มันสามารถย้อนกลับไปดู state ในอดีต ได้ เพราะ state เก่าไม่ได้ถูกทำลายทิ้ง

ทำไมผมถึงไม่กลัว function ยาวใน FP เท่า method ยาวใน OOP

ความเรียบง่ายแบบนี้ทำให้ผมไม่กลัว function ยาว ๆ ใน FP เท่ากับ method ยาว ๆ ที่เต็มไปด้วย mutable state

ไม่ใช่ว่า function ยาวเป็นเรื่องดีนะ ยาวก็ควรแยกอยู่ดี

แต่ถ้า function หนึ่งเป็น pure function ผมสามารถดูมันแบบ

input → transformation → output

แล้วพยายามทำความเข้าใจมันได้โดยไม่ต้องกังวลมากนักว่า ระหว่างทางมันไปเปลี่ยน state อะไรข้างนอกหรือเปล่า

ในทางกลับกัน method ยาว ๆ ที่เปลี่ยน state ของ Object ไปเรื่อย ๆ จะทำให้ผมต้องจำตลอดว่า ตอนนี้ค่าของแต่ละ field เปลี่ยนไปเป็นอะไรแล้ว

อันนั้นสำหรับผมน่าสยดสยองกว่าเยอะ

ทำไม FP ถึงยากสำหรับคนที่ชินกับ Imperative Programming

สิ่งหนึ่งที่ทำให้ผมรู้สึกว่า FP ยากในตอนเริ่มต้น คือ วิธีคิดของมันต่างจาก imperative programming พอสมควร

เวลาเขียน imperative เรามักจะคิดเป็นขั้นตอนว่า

ทำ A
แก้ค่า B
วน loop
ถ้าเป็นแบบนี้ให้แก้ C
แล้วค่อยไปทำ D

แต่เวลาเขียน FP ผมมักจะคิดในรูปของการเปลี่ยนข้อมูลจากรูปหนึ่งไปอีกรูปหนึ่งมากกว่า

เช่น ถ้าผมมีคำตอบของข้อสอบทุกวิชาของนักเรียนคนหนึ่ง แล้วอยากหาเกรดเฉลี่ย ผมอาจเริ่มถามตัวเองว่า

Q: ก่อนจะได้เกรดเฉลี่ย จะต้องมีอะไรก่อน?
A: เกรดทุกวิชา

ผมก็จะรู้ว่า function สุดท้ายที่ return เกรดเฉลี่ย จะต้องรับ input เป็นเกรดของทุกวิชา

แล้วถามต่อว่า

Q: ก่อนจะได้เกรดทุกวิชา ต้องมีอะไรก่อน?
A: คะแนนสอบของแต่ละวิชา

ก็จะได้ transformation ประมาณนี้

คำตอบของข้อสอบ
    ↓
คะแนนสอบ
    ↓
เกรด
    ↓
เกรดเฉลี่ย

สุดท้ายโปรแกรมก็จะกลายเป็นการต่อ function เล็ก ๆ เข้าด้วยกัน

input
  → transform
  → transform
  → transform
  → output

วิธีคิดแบบนี้ไม่ใช่ว่า imperative programming ทำไม่ได้ หรือ FP ต้องคิดถอยหลังเสมอไป

แต่มันเป็นวิธีคิดแบบ data transformation และ function composition ซึ่งผมเจอบ่อยมากเวลาเขียน Functional Programming และสำหรับคนที่ชินกับ imperative programming อาจต้องใช้เวลาปรับวิธีคิดอยู่บ้าง

ทำไมควรรู้ทั้ง FP และ OOP

วิธีการแก้ปัญหาของ 2 paradigm นี้ มันเหมือนค้อนกับกรรไกร บางงานมันแก้ด้วยเครื่องมืออีกอย่างง่ายกว่ามาก ๆ ถ้าเรารู้จักทั้ง 2 เครื่องมือ เราก็จะเลือกใช้ได้อย่างเหมาะสม

OOP พยายามทำให้ state ที่เปลี่ยนแปลงได้อยู่ในขอบเขตที่ควบคุมได้

FP พยายามลดจำนวน state ที่เปลี่ยนแปลงได้ลงตั้งแต่แรก

ทั้งสองแนวทางไม่ได้เป็นศัตรูกันด้วย ทุกวันนี้ภาษาโปรแกรมจำนวนมากก็เอาแนวคิดจากทั้ง OOP และ FP มาใช้ร่วมกัน

ผมเคยเห็นโค้ด imperative เป็นหลายพันบรรทัด ที่พอเปลี่ยนมามองปัญหาเป็น data transformation แล้ว ใช้แนวคิดแบบ FP กลับเหลือโค้ดไม่ถึง 200 บรรทัดก็มี

ที่ผมเลือกเอาเรื่องนี้มาแบ่งปัน เพราะในชีวิตเราอาจจะเจอปัญหาที่บางครั้งเราคิดว่ายากจังเลย

ผมอยากฝากคำของ Gerald Weinberg ไว้ว่า

ปัญหาไม่มีง่ายหรือยาก ยากหรือง่ายมันอยู่ที่ solution ในการแก้ปัญหา
ปัญหาที่เราคิดว่ายาก คือปัญหาที่เรายังไม่รู้ solution ง่าย ๆ

เริ่มต้นกับ Functional Programming was originally published in odds.team on Medium, where people are continuing the conversation by highlighting and responding to this story.

สถาปัตยกรรม AI Agent, วิกฤตตัวตนของช่างฝีมือ และเรือของธีซีอุส

“ในวันที่เครื่องจักรสามารถคิด วางแผน และลงมือทำแทนเราได้เกือบทั้งหมด… แล้วตัวตนและคุณค่าของมนุษย์อย่างเราอยู่ตรงไหนกันแน่?”

เรากำลังอยู่ในจุดเปลี่ยนผ่านครั้งสำคัญที่สุดครั้งหนึ่งของประวัติศาสตร์วิศวกรรมซอฟต์แวร์

หากย้อนกลับไปเมื่อไม่กี่ปีก่อน เวลาเราพูดถึง AI เรามักจะคุ้นเคยกับภาพของ Chatbot ที่ทำหน้าที่เหมือน “ที่ปรึกษาที่นั่งรอคำสั่ง” เราต้องพิมพ์คำถามเข้าไปหนึ่งครั้ง มันถึงจะคิดและตอบกลับมาหนึ่งครั้ง หากเราไม่ขยับ มันก็นิ่งสนิทอยู่บนหน้าจอ

แต่วันนี้ สถาปัตยกรรมของซอฟต์แวร์ได้ก้าวข้ามไปสู่ยุคของ Agentic Workflows และระบบ Autonomous AI Agents เป็นที่เรียบร้อยแล้ว มันไม่ใช่แค่โปรแกรมที่รอตอบคำถามอีกต่อไป แต่เราสามารถโยน “เป้าหมาย” ก้อนใหญ่ให้มัน เช่น สั่งว่า “ช่วยไปหาสาเหตุของบั๊กตัวนี้ แก้โค้ด รันเทสต์ให้ผ่าน แล้วเปิด Pull Request ทิ้งไว้ให้หน่อย” ตัว Agent จะทำหน้าที่แตกงานย่อย เปิดอ่านไฟล์ในโปรเจกต์ เรียกใช้ Terminal รันคำสั่ง และแก้ไขข้อผิดพลาดด้วยตัวเองเป็นสิบ ๆ ขั้นตอนจนเสร็จสมบูรณ์ โดยที่เราแทบไม่ต้องแตะคีย์บอร์ดแม้แต่ปุ่มเดียว

วินาทีที่เรานั่งจิบกาแฟมองดูหน้าจอ Terminal ไหลรันคำสั่งไปเองอย่างรวดเร็ว ครึ่งหนึ่งของความรู้สึกคือความทึ่งในความสะดวกสบาย แต่อีกครึ่งหนึ่งที่ซ่อนอยู่ลึก ๆ ในใจของวิศวกรและคนทำงานสร้างสรรค์จำนวนมาก กลับเป็นความรู้สึก “โหวง ๆ” อย่างบอกไม่ถูก เหมือนเรากำลังนั่งมอง “เงา” ของใครบางคนเข้ามานั่งทำงานบนโต๊ะตัวโปรดแทนเรา

การมาถึงของ Autonomous Agent จึงไม่ได้เปลี่ยนแค่วิธีที่เราออกแบบระบบคอมพิวเตอร์เท่านั้น แต่มันกำลังท้าทายไปถึงแก่นของจิตวิญญาณคนทำงาน

1. เมื่อฝูงโดรนไร้คนขับหลงทาง: จาก Deterministic สู่ภัยเงียบของ Cascading Hallucinations

หากสวมหมวกของ System Architect มองเข้ามาในระบบยุคใหม่ ความท้าทายที่ใหญ่ที่สุดของการนำ AI Agent มาใช้งาน คือการเปลี่ยนผ่านระดับรากฐานของธรรมชาติซอฟต์แวร์

ตลอดหลายทศวรรษที่ผ่านมา วิศวกรรมซอฟต์แวร์ถูกสร้างอยู่บนโลกของ Deterministic Systems (ระบบที่ผลลัพธ์คาดเดาได้แน่นอน 100%) หากเราเขียนโค้ดว่า 1 + 1 ไม่ว่าจะรันโค้ดนี้ตอนเที่ยงวันหรือเที่ยงคืน รันซ้ำอีกพันล้านครั้ง คำตอบก็ยังเป็น 2 เสมอ หากผลลัพธ์เพี้ยนไป แปลว่ามีบั๊กที่บรรทัดใดบรรทัดหนึ่ง ซึ่งเราสามารถไล่แกะรอย (Trace) ไปแก้ไขได้อย่างตรงไปตรงมา

แต่ทันทีที่เราดึง AI Agent เข้ามาเป็นส่วนหนึ่งของท่อการทำงาน เรากำลังเปลี่ยนระบบให้กลายเป็น Probabilistic Systems (ระบบที่ทำงานอยู่บนความน่าจะเป็น) โยนโจทย์เดิมให้ทำสองครั้ง มันอาจเลือกเส้นทางการแก้ปัญหาไม่เหมือนกัน และภัยเงียบที่น่ากลัวที่สุดเมื่อเราต่อท่อให้ Agent หลายตัวทำงานรับส่งลูกกันเอง คือปรากฏการณ์ที่เรียกว่า Cascading Hallucinations (การหลอนต่อเนื่องเป็นลูกโซ่)

ลองนึกภาพการเล่นเกมกระซิบส่งสารในระบบอัตโนมัติที่มี Agent 3 ตัวทำงานต่อกัน:

1. Agent ตัวที่ 1 (Requirement Analyzer): อ่านความต้องการของลูกค้าจากอีเมล แล้วบังเอิญตีความประโยคกำกวมผิดไปเพียงนิดเดียว แต่สรุปสเปกออกมาด้วยภาษาที่มั่นใจมาก แล้วส่งต่อให้ตัวที่สอง
2. Agent ตัวที่ 2 (Coder): ไม่รู้เลยว่าสารตั้งต้นเพี้ยนไปแล้ว มันรับลูกต่ออย่างขยันขันแข็ง เขียนโค้ดรื้อโครงสร้างฐานข้อมูลตามสเปกที่ผิดนั้นทันที แล้วส่งต่อให้ตัวที่สาม
3. Agent ตัวที่ 3 (Tester & Deployer): เขียนชุดทดสอบตามสเปกที่ได้รับมา เมื่อรันเทสต์จึงขึ้น “ไฟเขียว (All Tests Passed)” ผ่านฉลุยทุกขั้นตอน!

ผลลัพธ์คือระบบรายงานว่างานเสร็จสมบูรณ์ 100% ภายใต้สถานะสีเขียวจอมปลอม ทั้งที่ผลลัพธ์ปลายทางกำลังพังพินาศไปคนละทิศละทางกับความต้องการจริง และความน่ากลัวของ Autonomous Loop คือมันทำความผิดพลาดนี้ด้วยความเร็วระดับเครื่องจักร ซึ่งสามารถผลาญงบประมาณ Cloud หรือทำลายข้อมูลสำคัญได้ภายในเสี้ยวนาที

1. สถาปัตยกรรมควบคุมเงา: Bounded Autonomy และ Circuit Breakers

หน้าที่ของวิศวกรในยุคนี้จึงไม่ใช่การปล่อยให้ AI วิ่งทำงานอย่างไร้ขอบเขต แต่คือการสร้าง Deterministic Guardrails ครอบทับระบบที่คาดเดาไม่ได้อีกชั้นหนึ่ง:

• Bounded Autonomy (อิสรภาพภายใต้กรอบที่จำกัด): ภายในกล่องงานย่อย เราอนุญาตให้ Agent ใช้ความคิดสร้างสรรค์แบบ Probabilistic ได้เต็มที่ แต่ที่ “ขอบกล่อง” (Interface & Boundary) ต้องถูกกั้นด้วยกฎเหล็กแบบ Deterministic เสมอ
• Circuit Breakers (เบรกเกอร์ตัดไฟ): กำหนดเพดานการทำงานที่ชัดเจน เช่น หากลูปการแก้บั๊กหมุนเกิน 5 รอบแล้วยังไม่ผ่าน หรือมีการเรียกใช้ Token เกินงบประมาณที่กำหนดต่อหนึ่งงาน เบรกเกอร์ต้องดีดตัดการทำงานทันทีเพื่อป้องกัน Infinite Loop
• Human-in-the-Loop ตามระดับความเสี่ยง: แยกสิทธิ์การเข้าถึงอย่างเด็ดขาด งานประเภทอ่านข้อมูล วิเคราะห์ และวางแผน (Read & Plan) สามารถให้ Agent รันอัตโนมัติได้ แต่เมื่อใดที่เป็นการเปลี่ยนแปลงสถานะของระบบจริง การลบข้อมูล หรือการนำโค้ดขึ้น Production (Write & Execute) ระบบต้องหยุดรอการตรวจสอบและกดอนุมัติจากมนุษย์เสมอ

2. เรือของธีซีอุส กับความแปลกแยกของช่างฝีมือ (Alienation from Labor)

เมื่อจัดการความเสี่ยงทางเทคนิคได้แล้ว คำถามที่ยากกว่ากลับอยู่ในใจของคนทำงานเอง: ทำไมยิ่งงานเสร็จเร็วขึ้น เรากลับยิ่งรู้สึกภูมิใจในตัวเองน้อยลง?

คำตอบของความรู้สึกนี้ซ่อนอยู่ในปริศนาปรัชญากรีกโบราณที่ชื่อว่า “เรือของธีซีอุส” (The Ship of Theseus)

เรื่องมีอยู่ว่า เรือไม้ของวีรบุรุษธีซีอุสถูกเก็บรักษาไว้เป็นอนุสรณ์ เมื่อเวลาผ่านไป ไม้กระดานแผ่นไหนผุพัง ช่างก็จะนำไม้แผ่นใหม่มาตอกเปลี่ยนแทนที่ไปเรื่อย ๆ จนกระทั่งวันหนึ่ง ไม้กระดาน เสากระโดงเรือ และใบเรือทุกชิ้น ถูกเปลี่ยนเป็นของใหม่ทั้งหมด 100% คำถามคือ เรือลำที่จอดอยู่ตรงหน้าเรานี้ ยังใช่ “เรือของธีซีอุส” ลำเดิมอยู่หรือไม่?

เมื่อนำปริศนานี้มาวางทาบกับงานของเราในปัจจุบัน หากซอฟต์แวร์หนึ่งระบบ บทความหนึ่งชิ้น หรืองานออกแบบหนึ่งหน้า ถูกสร้างและประกอบร่างโดย AI ไปแล้วถึง 90% โดยมีเราเป็นเพียงผู้พิมพ์คำสั่งตอนต้นและตรวจทานตอนท้าย… เรายังสามารถพูดได้เต็มปากไหมว่า “นี่คือผลงานของฉัน”?

ในทางปรัชญาสังคมศาสตร์ อาการโหวง ๆ ในใจนี้เรียกว่า Alienation from Labor (ความแปลกแยกจากผลงานของตัวเอง) และนักปรัชญาชาวเยอรมันอย่าง มาร์ติน ไฮเดกเกอร์ (Martin Heidegger) ได้เคยสะท้อนไว้ในงานเขียน The Question Concerning Technology ว่า เมื่อเทคโนโลยีสมัยใหม่เปลี่ยนทุกสรรพสิ่งให้กลายเป็นเพียง “ทรัพยากรที่พร้อมถูกสั่งใช้งานเพื่อประสิทธิภาพสูงสุด” (Standing-Reserve) มนุษย์จะสูญเสียความสัมพันธ์เชิงลึกและการค้นพบความหมายผ่านการสร้างสรรค์ไป

เพราะสำหรับมนุษย์แล้ว ความสุขและความหมายของการเป็น “ช่างฝีมือ” (Craftsmanship) ไม่ได้อยู่ที่วินาทีที่งานเสร็จสมบูรณ์เพียงอย่างเดียว แต่มันซ่อนอยู่ใน “กระบวนการระหว่างทาง” ต่างหาก มันอยู่ในช่วงเวลาที่เราขบคิดแก้ปัญหายาก ๆ อยู่ในจังหวะที่เราค่อย ๆ เรียงร้อยโครงสร้างด้วยตัวเองจนเกิดสภาวะลื่นไหล (Flow State) เหมือนช่างปั้นหม้อที่ได้ใช้สองมือสัมผัสกับเนื้อดินเหนียว

เมื่อ AI เข้ามาตัดทอน “กระบวนการลงมือทำ” ตรงกลางทิ้งไปทั้งหมด เหลือเพียงจุดเริ่มต้นคือการสั่ง (Prompt) และกระโดดข้ามไปที่จุดจบคือการตรวจรับ (Review) ทันที เราจึงได้ “ผลลัพธ์ของงาน” มาครอบครองอย่างรวดเร็ว แต่กลับทำ “จิตวิญญาณของช่างฝีมือ” ตกหล่นไประหว่างทาง

3. จากช่างก่ออิฐ สู่สถาปนิกผู้รักษาจิตวิญญาณ: 3 แนวทางสำหรับคนทำงานยุค Agentic

ในเมื่อเราไม่สามารถหมุนเข็มนาฬิกากลับไปสู่ยุคก่อนจะมี AI ได้ และเครื่องมือเหล่านี้ก็จะยิ่งฉลาดขึ้นทุกวัน เราจะก้าวเดินต่อไปอย่างไรโดยไม่สูญเสียคุณค่าและความภาคภูมิใจในตัวเอง? ทางออกไม่ใช่การปฏิเสธเทคโนโลยี แต่คือการ “นิยามความหมายของช่างฝีมือเสียใหม่” ผ่าน 3 แนวทางนี้ครับ:

1. ขยับจาก “ผู้ลงมือทำ” สู่ “ผู้กำหนดเจตจำนงและรสนิยม” (From Execution to Intent & Taste)

ลองนึกถึง “วาทยกร” (Conductor) ที่ยืนโบกไม้บาตองอยู่หน้าวงออร์เคสตรา วาทยกรไม่ได้ลงไปนั่งสีไวโอลินหรือเป่าทรัมเป็ตด้วยตัวเองแม้แต่ตัวโน้ตเดียว แต่ทำไมบทเพลงซิมโฟนีบทเดียวกัน เมื่อเปลี่ยนตัววาทยกร พลังและอารมณ์ของเพลงถึงแตกต่างกันราวฟ้ากับเหว?

เพราะวาทยกรคือผู้กำหนด “เจตจำนง (Intent)” และ “รสนิยม (Taste)” ของบทเพลงทั้งหมด AI Agent อาจเป็นนักดนตรีที่เล่นตามตัวโน้ตได้แม่นยำและรวดเร็วที่สุดในโลก แต่มันไม่มีเจตจำนงของตัวเอง มันไม่รู้หรอกว่าทำไมฟีเจอร์นี้ถึงมีความหมายต่อรอยยิ้มของผู้ใช้ และไม่รู้ว่าสถาปัตยกรรมแบบไหนที่เรียบง่ายและสง่างาม ในยุคนี้ ความเป็นช่างฝีมือของเราจึงย้ายจากการพิมพ์ Syntax ให้ถูกไวยากรณ์ ไปสู่การเป็นวาทยกรที่ใช้ความเข้าใจมนุษย์และประสบการณ์ชีวิตในการกำกับทิศทางและคัดเลือกสิ่งที่ดีที่สุด

2. อย่าปล่อยให้พื้นฐานทางความคิดฝ่อลง (Never Outsource Your Understanding)

อันตรายที่น่ากลัวที่สุดของการใช้ AI Agent ไม่ใช่การที่มันเขียนโค้ดแทนเรา แต่คือการที่เรายอมกด Merge โค้ดที่มันเขียนมา โดยที่เราเองก็ไม่เข้าใจว่าข้างในนั้นทำงานอย่างไร

หากเราปล่อยให้ตัวเองทำแบบนั้นจนชิน วันหนึ่งเมื่อระบบเกิดพังทลายลงในจุดที่ซับซ้อนเกินกว่า AI จะแก้ได้ เราจะกลายเป็นคนที่ไร้หนทางสู้ทันที ไม่ว่าผู้ช่วยอัจฉริยะจะร่างงานมาให้เร็วแค่ไหน จงรักษาความอยากรู้อยากเห็นแบบวิศวกรไว้เสมอ อ่านทำความเข้าใจ ตั้งคำถามกับโครงสร้างที่มันสร้าง และลับคมวิธีคิดเชิงระบบ (Systems Thinking) ของตัวเองอยู่เสมอ เพื่อให้เราเป็น “เจ้านายของเครื่องมือ” ไม่ใช่ผู้ตามของเครื่องมือ

3. เก็บรักษา “สวนหลังบ้านที่ทำด้วยมือ” ไว้หล่อเลี้ยงหัวใจ (Keep a Handcrafted Sanctuary)

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

ลองกลับมานั่งเขียนโค้ดเพียว ๆ ด้วยตัวเองทีละบรรทัด ลองเขียนบทความจากหน้ากระดาษเปล่าด้วยสำนวนของตัวเอง หรือออกไปทำกิจกรรมในโลกกายภาพที่ไม่มี AI ตัวไหนทำแทนเราได้ เช่น การออกไปวิ่งให้เหงื่อซึม การชงกาแฟดริปช้า ๆ ในตอนเช้า หรือการนั่งพูดคุยสบตากับคนที่เรารัก เพื่อให้สองมือและหัวใจของเรายังคงได้สัมผัสกับ “เนื้อดินเหนียวของชีวิตจริง” และจดจำได้เสมอว่า ความสุขของการได้ลงมือสร้างสรรค์สิ่งต่าง ๆ ด้วยตัวเองอย่างช้า ๆ นั้นมีคุณค่าและงดงามเพียงใด

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

🎧 ติดตามฟังเรื่องราวการผ่าตัดสถาปัตยกรรมซอฟต์แวร์และปรัชญาชีวิตฉบับเต็มได้ใน: รายการ Uncle Quin Podcast EP.63 | เงาในเครื่องจักร (The Autonomous Ghost)

หากคุณชอบบทความแนวการเชื่อมโยงปรัชญาเข้ากับการทำงานในโลกยุคใหม่ ฝากกดเลิฟ กดแชร์ และกดติดตามช่องของผมด้วยนะครับ!

• Spotify
• YouTube

เงาในเครื่องจักร (The Autonomous Ghost) was originally published in odds.team on Medium, where people are continuing the conversation by highlighting and responding to this story.

เมื่อปัญหาของ Test Automation ไม่ใช่จำนวน Test Case แต่เป็นการเลือกทดสอบให้ถูกระดับ

ถ้าคุณทำงานในสาย QA หรือ Software Development มาสักระยะหนึ่ง คงเคยได้ยินแนวคิด Testing Pyramid กันมาบ้าง

ภาพสามเหลี่ยมที่มี Unit Test อยู่ด้านล่าง Integration Test อยู่ตรงกลาง และ End-to-End (E2E) Test อยู่ด้านบน

เป็นแนวคิดที่เข้าใจไม่ยาก และมักถูกพูดถึงเวลาทีมเริ่มวาง Test Strategy หรือพยายามปรับปรุงกระบวนการทดสอบ

แต่คำถามที่น่าสนใจคือ

ถ้าทุกคนรู้จัก Testing Pyramid แล้ว ทำไมหลายโปรเจกต์ถึงยังมี Automated E2E Test จำนวนมาก แต่กลับมี Unit Test และ Integration Test ไม่เพียงพอ?

แนวคิดนี้ทำให้ฉันสนใจบทความ The Testing Pyramid: Everybody Knows It, Nobody Follows It ของ Serhii Smetanskyi

บทความต้นฉบับชวนให้กลับมามองว่า การมี Automation Test จำนวนมาก ไม่ได้หมายความว่าเรากำลังมี Test Strategy ที่ดีเสมอไป

และนี่คือประเด็นที่ฉันอยากหยิบมาขยายความในมุมของการทำ QA และ Test Automation

1. Testing Pyramid ไม่ได้บอกให้เราทำ Automation ให้มากที่สุด

แนวคิด Testing Pyramid มีหลักการสำคัญคือ การกระจายการทดสอบให้เหมาะสมกับต้นทุน ความเร็ว และความเสี่ยงของแต่ละระดับ

Unit Test ควรเป็นรากฐาน เพราะสามารถตรวจสอบ Business Logic ได้รวดเร็วและมีต้นทุนการรันต่ำ

Integration Test ช่วยตรวจสอบว่าระบบหรือ Component ต่าง ๆ สามารถทำงานร่วมกันได้อย่างถูกต้อง

ส่วน E2E Test ใช้ตรวจสอบ Critical User Journey ที่ต้องอาศัยการทำงานของหลายส่วนประกอบร่วมกัน

ปัญหาคือหลายทีมเริ่มต้น Test Automation จากสิ่งที่มองเห็นได้ง่ายที่สุด นั่นคือ User Interface

เมื่อมี Feature ใหม่ ก็เพิ่ม E2E Test

เมื่อพบ Defect ก็เพิ่ม Regression Test ผ่าน UI

เมื่อ Business Rule เปลี่ยน ก็เพิ่ม Scenario บน Browser

จนสุดท้าย Automation Suite มีขนาดใหญ่ขึ้นเรื่อย ๆ แต่กลับใช้เวลารันนาน ดูแลรักษายาก และมี Flaky Test เกิดขึ้นบ่อยครั้ง

สิ่งที่ควรตั้งคำถามจึงไม่ใช่เพียงว่า

“เรามี Automated Test กี่ Test Case แล้ว?”

แต่ควรถามว่า

“สิ่งที่เราต้องการตรวจสอบ ควรถูกทดสอบที่ระดับไหนจึงจะเหมาะสมที่สุด?”

2. Unit Test: รากฐานของ Fast Feedback

Unit Test มีหน้าที่ตรวจสอบ Logic ในขอบเขตเล็ก ๆ เช่น Function, Method หรือ Class โดยพยายามแยก External Dependency ออก

ลองนึกถึงระบบสินเชื่อที่มี Business Rule สำหรับคำนวณวงเงินอนุมัติ

หากต้องตรวจสอบเงื่อนไขเกี่ยวกับอายุผู้สมัคร รายได้ หรือวงเงินสูงสุด เราไม่จำเป็นต้องเปิด Browser กรอกข้อมูล และกด Submit ทุกครั้ง

หลายเงื่อนไขสามารถตรวจสอบได้โดยตรงผ่าน Unit Test

ข้อดีคือ Developer สามารถได้รับ Feedback ได้ตั้งแต่ช่วง Development โดยไม่ต้องรอให้ระบบถูก Deploy ไปยัง Test Environment

แต่สิ่งสำคัญไม่ใช่แค่การมี Unit Test

Test ต้องมี Assertion ที่ตรวจสอบผลลัพธ์อย่างมีความหมาย ไม่ใช่เพียงเรียก Function แล้วจบโดยไม่มีการยืนยันว่าผลลัพธ์ถูกต้อง

นอกจากนี้ Code Coverage ยังเป็นเพียงหนึ่งในตัวช่วยประเมิน ไม่ใช่หลักประกันว่า Test มีคุณภาพ

Unit Test ที่ดีควรช่วยให้ทีมมั่นใจใน Business Logic และกล้า Refactor Code โดยไม่ต้องกังวลว่าจะทำให้พฤติกรรมเดิมเปลี่ยนไปโดยไม่ตั้งใจ

3. Integration Test: ระดับที่หลายทีมมองข้าม

หนึ่งในปัญหาที่พบได้บ่อยคือ ทีมมีทั้ง Unit Test และ E2E Test แต่มี Integration Test น้อยมาก

ทั้งที่ Defect จำนวนหนึ่งไม่ได้เกิดจาก Logic ของ Component ใด Component หนึ่งโดยตรง

แต่เกิดจากการเชื่อมต่อระหว่าง Component เช่น

• API ส่ง Response Field ไม่ตรงกับที่ Consumer คาดหวัง
• Service บันทึกข้อมูลลง Database ไม่ถูกต้อง
• Business Logic ทำงานถูกต้อง แต่การ Mapping ข้อมูลผิดพลาด
• ระบบจัดการ Error Status ไม่ตรงตาม Contract

ปัญหาเหล่านี้อาจไม่ถูกตรวจพบด้วย Unit Test ที่ Mock Dependency ไว้ทั้งหมดและหากรอให้ E2E Test เป็นผู้ตรวจพบ ก็อาจทำให้การวิเคราะห์ Root Cause ยากขึ้น Integration Test จึงมีบทบาทสำคัญในการตรวจสอบการทำงานร่วมกันของระบบ สำหรับทีมที่ใช้ Playwright อยู่แล้ว ก็สามารถใช้ API Testing ผ่าน APIRequestContext ได้ โดยไม่จำเป็นต้องสร้าง Browser Test สำหรับทุก Scenario

อย่างไรก็ตาม การส่ง HTTP Request เพียงอย่างเดียวไม่ได้ทำให้ Test เป็น Integration Test โดยอัตโนมัติ เราต้องพิจารณาด้วยว่ากำลังตรวจสอบการทำงานร่วมกันของ Component จริงหรือไม่

เป้าหมายคือค้นพบปัญหาให้ใกล้กับจุดที่เกิดปัญหามากที่สุด ไม่ใช่รอให้ปัญหาแสดงออกบน UI เสมอไป

4. Modular Integration Test: ทดสอบพฤติกรรม ไม่ใช่แค่การเรียก Function

อีกหนึ่งแนวคิดที่น่าสนใจคือ Modular Integration Test

แทนที่จะ Mock ทุกอย่างภายใน Module เราสามารถทดสอบการทำงานจริงของส่วนประกอบภายใน Module นั้น และจำลองเฉพาะ External Dependency ที่อยู่นอกขอบเขต

ตัวอย่างเช่น ระบบสร้างคำสั่งซื้อ

การทดสอบไม่ควรยืนยันเพียงว่า Function สำหรับบันทึก Order ถูกเรียกแล้ว

แต่ควรตรวจสอบผลลัพธ์ว่า Order ถูกบันทึกจริงหรือไม่ สถานะถูกต้องหรือไม่ และข้อมูลที่เกี่ยวข้องมีความสอดคล้องกันหรือไม่

แนวทางนี้ทำให้ Test ผูกติดกับ Implementation Detail น้อยลง

เมื่อ Developer เปลี่ยนชื่อ Method หรือ Refactor โครงสร้างภายใน โดยที่ Business Behavior ไม่เปลี่ยน Test ก็ไม่ควรล้มเหลวโดยไม่จำเป็น

สิ่งนี้สะท้อนหลักคิดสำคัญว่า

Test ที่ดีควรยืนยันสิ่งที่ระบบทำได้ ไม่ใช่ยึดติดกับวิธีที่ระบบถูกเขียนขึ้น

5. E2E Test ไม่ใช่ปัญหา แต่การใช้ E2E Test กับทุกอย่างต่างหากที่เป็นปัญหา

E2E Test มีคุณค่ามาก เพราะเป็นการตรวจสอบว่าระบบสามารถรองรับการทำงานของผู้ใช้ได้จริง

ตัวอย่างเช่น ลูกค้าเข้าสู่ระบบ เลือกผลิตภัณฑ์ กรอกข้อมูลสมัครสินเชื่อ ส่งคำขอ และได้รับผลลัพธ์ตามที่ระบบกำหนด Flow ลักษณะนี้เหมาะกับ E2E Test เพราะมีหลาย Component ทำงานร่วมกัน และสะท้อน Critical Business Journey

แต่หากเรานำทุก Validation Rule ทุก Error Message และทุก Boundary Condition มาทดสอบผ่าน UI ทั้งหมด ก็อาจทำให้ Test Suite มีขนาดใหญ่เกินความจำเป็น

E2E Test มี Dependency หลายส่วน ทั้ง Browser, Network, Test Data, Environment และ Backend Services

ยิ่งมี Dependency มากเท่าไร โอกาสที่ Test จะล้มเหลวจากสาเหตุอื่นนอกเหนือจาก Defect ก็ยิ่งเพิ่มขึ้น

ดังนั้นการเลือก E2E Scenario ควรให้ความสำคัญกับ Business Risk และ Critical User Journey มากกว่าการพยายามครอบคลุมทุกเงื่อนไขผ่าน Browser

6. Flaky Test ไม่ควรเป็นเรื่องปกติของ Automation

เมื่อ Automation Suite เริ่มใหญ่ขึ้น หลายทีมอาจเริ่มพบปัญหาคล้ายกัน

Test ผ่านบนเครื่อง Developer แต่ล้มเหลวบน CI

Test ผ่านเมื่อรันแยก แต่ล้มเหลวเมื่อรันพร้อมกัน

หรือ Test ล้มเหลวในครั้งแรก แต่ผ่านเมื่อ Retry

การเพิ่ม Retry อาจช่วยลดผลกระทบระยะสั้น แต่ไม่ได้แก้ Root Cause เสมอไป

ทีมควรตรวจสอบ Test Data Isolation, Shared State, Locator Stability, Synchronization และ Environment Readiness

โดยเฉพาะเมื่อใช้ Parallel Execution เราควรออกแบบให้แต่ละ Test สามารถทำงานได้อย่างอิสระ ไม่พึ่งพาลำดับการรันของ Test อื่น

เพราะเป้าหมายของ Automation ไม่ใช่การทำให้ Pipeline แสดงสีเขียว

แต่คือการสร้าง Feedback ที่ทีมสามารถเชื่อถือได้

7. AI ทำให้เขียน Code เร็วขึ้น แต่ไม่ได้หมายความว่า Test Strategy จะดีขึ้น

ปัจจุบัน AI Coding Assistant ช่วยให้ Developer สร้าง Code และ Test ได้รวดเร็วขึ้นมาก แต่การสร้าง Test ได้เร็วขึ้น ไม่ได้หมายความว่าเรากำลังเลือก Test Level ได้เหมาะสม

หากทีมไม่มี Test Strategy ที่ชัดเจน AI ก็อาจช่วยสร้าง Test จำนวนมากที่ซ้ำซ้อน ผูกกับ Implementation Detail หรือไม่ได้ครอบคลุม Business Risk ที่สำคัญ

ดังนั้นเมื่อ Development Velocity เพิ่มขึ้น ความสำคัญของ Test Strategy ก็ยิ่งเพิ่มขึ้นตามไปด้วย

ทีมยังคงต้องตัดสินใจว่าอะไรควรทดสอบ อะไรไม่จำเป็นต้องทดสอบซ้ำ และควรใช้ Test Level ใดในการให้ Feedback ที่รวดเร็วและน่าเชื่อถือที่สุด

แล้ว QA ควรเริ่มต้นปรับ Testing Pyramid อย่างไร?

ในมุมของฉัน การนำ Testing Pyramid ไปใช้ไม่จำเป็นต้องเริ่มจากการรื้อ Automation Framework ทั้งหมด แต่เริ่มจากการกลับมาทบทวน Test Coverage ที่มีอยู่ ดูว่าแต่ละ Scenario กำลังตรวจสอบอะไร มีความเสี่ยงต่อ Business มากแค่ไหน และสามารถย้ายไปตรวจสอบในระดับที่ต่ำกว่าได้หรือไม่ QA ควรทำงานร่วมกับ Developer ตั้งแต่ช่วง Test Design เพื่อกำหนด Test Ownership ให้ชัดเจน

ไม่ใช่ปล่อยให้ QA รับผิดชอบ E2E Test ทั้งหมด ขณะที่ Unit Test และ Integration Test เป็นเรื่องที่ไม่มีใครดูแลอย่างจริงจัง

และที่สำคัญ การวัดความสำเร็จของ Automation ไม่ควรจบอยู่ที่จำนวน Test Case หรือ Automation Coverage เพียงอย่างเดียว

แต่ควรมองถึง Feedback Time, Test Reliability, Defect Detection และความสามารถของทีมในการ Release Software อย่างมั่นใจ

บทส่งท้าย: Testing Pyramid ไม่ใช่เป้าหมาย แต่เป็นแนวทางในการตัดสินใจ

สิ่งที่ฉันชอบจากแนวคิดนี้คือ มันไม่ได้บอกว่า E2E Test ไม่ดี หรือทุกทีมต้องมีสัดส่วน Unit Test, Integration Test และ E2E Test เหมือนกันทั้งหมด

แต่กำลังเตือนว่า การทำ Test Automation โดยไม่มี Strategy อาจทำให้เราสร้างภาระในการดูแลรักษามากกว่าคุณค่าที่ได้รับ

บางครั้งการเพิ่ม Automated Test อีก 100 Test Case อาจไม่ได้ช่วยเพิ่มความมั่นใจให้ทีมมากเท่ากับการออกแบบ Test เพียงไม่กี่ Scenario ให้ถูกระดับ

สุดท้ายแล้ว คุณภาพของ Test Automation ไม่ควรวัดจากจำนวน Test ที่เรามีเพียงอย่างเดียว แต่ควรวัดจากความสามารถในการตรวจพบปัญหา ให้ Feedback ที่รวดเร็ว และสร้างความมั่นใจในการส่งมอบ Software

เพราะการมี Automation จำนวนมาก ไม่ได้แปลว่าเรากำลังทดสอบได้ดีเสมอไป

และการรู้จัก Testing Pyramid ก็ไม่ได้หมายความว่าเราได้นำแนวคิดนี้ไปใช้อย่างแท้จริง

บทความอ้างอิง

The Testing Pyramid: Everybody Knows It, Nobody Follows It — Serhii Smetanskyi

บทความนี้เป็นการเรียบเรียงและขยายความแนวคิดจากต้นฉบับ พร้อมมุมมองด้าน QA และ Test Automation ไม่ใช่คำแปลแบบคำต่อคำ

Testing Pyramid: ทุกคนรู้จัก แต่ทำไมหลายทีมถึงไม่ทำตาม? was originally published in odds.team on Medium, where people are continuing the conversation by highlighting and responding to this story.

“ข้าขอสาบานอย่างจริงจังว่า ข้ากำลังคิดแผนชั่ว (I solemnly swear that I am up to no good)”

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

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

สำหรับแฟน ๆ Harry Potter นี่คือ “แผนที่ตัวกวน” (The Marauder’s Map) ไอเทมคู่ใจที่ช่วยให้แฮร์รี่แอบย่องออกจากหอคอยตอนเที่ยงคืนโดยไม่ถูกภารโรงฟิลช์จับได้

แต่ถ้าคุณเป็นวิศวกรซอฟต์แวร์ (Software Engineer) หรือสถาปนิกระบบ (System Architect) ทันทีที่คุณเห็นแผนที่ตัวกวนกางออก คุณจะรู้ทันทีว่านี่ไม่ใช่แค่กระดาษเวทมนตร์ธรรมดา แต่มันคือ Real-time Observability & Telemetry Dashboard ในอุดมคติที่วิศวกรทุกคนใฝ่ฝันหา

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

1. Kernel-Level Tracing: ทำไมหนูสแคบเบอร์สถึงหนีไม่พ้นแผนที่ตัวกวน?

ฉากที่พิสูจน์ความอัจฉริยะระดับสถาปัตยกรรมของแผนที่ตัวกวนได้ดีที่สุด อยู่ในภาค นักโทษแห่งอัซคาบัน (Prisoner of Azkaban) ครับ

ตลอดสิบกว่าปี โลกเวทมนตร์เข้าใจว่า ปีเตอร์ เพ็ตทิกรูว์ เสียชีวิตไปแล้ว เพราะเขาใช้วิชาแอนิเมจัส (Animagus) แปลงร่างเป็นหนูแก่ ๆ ที่ชื่อว่า “สแคบเบอร์ส” แล้วแฝงตัวเป็นสัตว์เลี้ยงอยู่ในครอบครัววีสลีย์มาโดยตลอด

ไม่ว่าใครจะมองด้วยตาเปล่า หรือใช้คาถาตรวจสอบพื้นฐาน ก็เห็นแค่หนูธรรมดาตัวหนึ่ง แต่เมื่อรีมัส ลูปิน และแฮร์รี่กางแผนที่ตัวกวนออกมา แผนที่กลับไม่เคยถูกหลอก มันแสดงป้ายชื่อ “Peter Pettigrew” เดินดุ๊กดิ๊กอยู่บนเตียงของรอนอย่างชัดเจน ไม่ว่าใครจะสวมผ้าคลุมล่องหน ดื่มน้ำยาสรรพรสปลอมตัวเป็นคนอื่น หรือกลายร่างเป็นสัตว์ แผนที่ตัวกวนก็ยังระบุตัวตนที่แท้จริง (True Identity) ได้โดยไม่เคยพลาด

ในทางวิศวกรรมซอฟต์แวร์ นี่คือความแตกต่างระหว่างการทำ Surface Monitoring กับการทำ Deep Observability (Kernel-Level Tracing) ครับ

การมองเห็นหนูสแคบเบอร์สด้วยตาเปล่า เหมือนกับการที่เราดูสถานะของระบบแค่ที่ระดับ Application Layer หรือดูแค่ว่าหน้าเว็บยังคืนค่า HTTP 200 OK อยู่ไหม ถ้าระบบถูกผู้ไม่หวังดีแฮกเข้ามาฝัง Malware ที่ปลอมชื่อโปรเซสตัวเองเป็นไฟล์ระบบธรรมดา หรือเขียนโค้ดหลอกให้พ่น Log ออกมาว่า "ทุกอย่างปกติ" การดูแค่เปลือกนอกจะไม่มีวันจับความผิดปกติได้เลย

แต่แผนที่ตัวกวนทำงานเหมือนเทคโนโลยีระดับ Linux Kernel Tracing (เช่น eBPF) ครับ ต่อให้โปรแกรมข้างบนจะสวม “ผ้าคลุมล่องหน” ปกปิดตัวเองในระดับ User Space แค่ไหน หรือดื่ม “น้ำยาสรรพรส” ปลอม Header มาหลอกยังไง แต่ตราบใดที่มันยังต้องมีชีวิตอยู่ — ต้องขยับตัว ต้องหายใจ หรือในทางคอมพิวเตอร์คือต้องเรียกใช้ System Call (Syscall) ลงมาที่ระดับ Kernel เพื่อขอใช้ CPU, ขออ่าน Memory หรือขอส่งแพ็กเกจผ่าน Network — ตัว Kernel จะมองทะลุเปลือกนอกและเห็นตัวตนที่แท้จริงของโปรเซสนั้นเสมอ

นี่คือแก่นแท้ของ Observability: ไม่ใช่แค่การติดไฟเขียวไฟแดงไว้ดูสิ่งที่เรารู้จักอยู่แล้ว (Known Unknowns) แต่คือการมีข้อมูลเชิงลึก (Traces, Metrics, Logs) ที่บริสุทธิ์และละเอียดพอให้เราตั้งคำถามเพื่อแกะรอยหา “หนูสแคบเบอร์ส” ที่ซ่อนอยู่ในระบบของเราเจอ (Unknown Unknowns)

2. เมื่อแผนที่ตกไปอยู่ในมืออัมบริดจ์: คุกวงแหวน Panopticon ของ Michel Foucault

แผนที่ตัวกวนคือเครื่องมือที่ทรงพลังมากเมื่ออยู่ในมือของแฮร์รี่ พอตเตอร์ แต่ลองจินตนาการดูสิครับว่า ถ้าแผนที่แผ่นนี้ดันตกไปอยู่ในมือของ โดโลเรส อัมบริดจ์ แล้วถูกนำไปฉายขึ้นจอยักษ์กลางห้องทำงานของเธอ จะเกิดอะไรขึ้น?

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

ภาพฝันร้ายนี้ตรงกับแนวคิดทางปรัชญาที่โด่งดังของ มิเชล ฟูโกต์ (Michel Foucault) นักปรัชญาชาวฝรั่งเศส ที่วิเคราะห์เรื่องอำนาจและการควบคุมผ่านสถาปัตยกรรมที่เรียกว่า “Panopticon” (คุกวงแหวน) ในหนังสือ Discipline and Punish

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

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

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

เราเห็นบริษัทที่ติดตั้งซอฟต์แวร์แอบแคปหน้าจอพนักงานทุก ๆ 5 นาที, ระบบที่นับจำนวนครั้งการคลิกเมาส์และการกดคีย์บอร์ด, หัวหน้าที่คอยจ้องว่าทำไมจุดไฟใน Slack หรือ Microsoft Teams ถึงเปลี่ยนจากสีเขียวเป็นสีเหลืองเกิน 10 นาที หรือการนำ Velocity Point ใน Jira และจำนวน Commit ใน Git มานั่งจับผิดรายบุคคล

เมื่อผู้บริหารสวมบทเป็นอัมบริดจ์ที่ถือแผนที่ตัวกวน สิ่งที่ตามมาไม่ใช่ประสิทธิภาพการทำงานที่เพิ่มขึ้นครับ แต่คือการทำลายระบบนิเวศของทีมอย่างย่อยยับผ่าน กฎของกู๊ดฮาร์ต (Goodhart’s Law):

“เมื่อไหร่ก็ตามที่ตัวชี้วัด (Measure) กลายเป็นเป้าหมายในการให้รางวัลหรือลงโทษ (Target) มันจะสูญเสียคุณค่าในการเป็นตัวชี้วัดที่ดีไปทันที”

เมื่อมนุษย์รู้ว่าตัวเองกำลังอยู่ในคุก Panopticon สมองจะเปลี่ยนโหมดจาก “การคิดสร้างสรรค์” ไปสู่ “การเอาตัวรอด” ทันที พนักงานจะเลิกโฟกัสที่การแก้ปัญหายาก ๆ ให้ลูกค้า แต่จะเอาพลังงานไปทุ่มให้กับการ “แสดงละครให้แผนที่ดูสวยงาม” แทน เช่น การหาของหนัก ๆ มาวางทับปุ่ม Spacebar เพื่อให้ไฟสถานะเขียวตลอดเวลา, การแตก Task งานเล็ก ๆ ยิบย่อยเพื่อให้ดูเหมือนปิด Ticket ได้เยอะ หรือการซ่อนปัญหาใต้พรมเพราะกลัวกราฟตัวเองดูแย่

สุดท้าย ผู้บริหารจะได้เห็นตัวเลขสีเขียวสวยหรูเต็มหน้าจอ Dashboard สมใจอยาก แต่แลกมาด้วยการตายสนิทของ ความไว้ใจ (Trust) และ ความปลอดภัยทางจิตวิทยา (Psychological Safety) ในองค์กร

3. กฎเหล็ก 3 ข้อของแก๊งตัวกวน: ใช้เพื่อเปิดทาง ไม่ใช่เพื่อคุมขัง

ทำไมแผนที่แผ่นเดียวกัน เมื่ออยู่ในมือผู้สร้างทั้งสี่ (จันทร์เจ้า, หางหนอน, เท้าปุย, เขาแหลม) หรืออยู่ในมือแฮร์รี่ จึงกลายเป็นสัญลักษณ์ของอิสรภาพและมิตรภาพ แต่เมื่ออยู่ในมือผู้คุมกลับกลายเป็นเครื่องมือเผด็จการ?

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

หากเราต้องการนำปรัชญาของแผนที่ตัวกวนมาใช้ออกแบบระบบวิศวกรรมและการบริหารทีมอย่างถูกวิธี นี่คือ 3 กฎเหล็กที่เราต้องยึดถือครับ:

1. Observe the System, Never Spy on the Soul (ส่องที่ระบบ อย่าสอดแนมที่ตัวคน)

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

2. Deep Context over Surface Status (ดูบริบทที่แท้จริง อย่าดูแค่เปลือกนอก)

เหมือนที่แผนที่ตัวกวนไม่หลงเชื่อรูปลักษณ์ภายนอกของหนูสแคบเบอร์ส เวลาดูแลระบบ อย่าดูแค่ว่า CPU ยังไม่เต็มหรือหน้าเว็บยังเข้าได้ แต่จงดูไปถึง Business Metrics ว่าลูกค้าใช้งานสำเร็จจริงไหม และเวลาดูแลทีม จงเลิกตัดสินคุณค่าของคนจาก “จำนวนชั่วโมงที่ไฟเขียวในแชต” แต่ให้ดูที่ผลลัพธ์และคุณค่าที่เขาส่งมอบให้ทีมจริง ๆ

3. Mischief Managed (รู้จักพับแผนที่เก็บเมื่อจบภารกิจ)

กฎข้อที่สำคัญที่สุดของแผนที่ตัวกวน คือเมื่อใช้งานเสร็จ ผู้ใช้ต้องเอาไม้กายสิทธิ์แตะกระดาษแล้วพูดว่า “แผนลวงสำเร็จแล้ว! (Mischief Managed!)” เพื่อให้หมึกทั้งหมดเลือนหายไป กลายเป็นกระดาษเปล่าดังเดิม

ในฐานะวิศวกรและผู้นำ เราไม่จำเป็นต้องจ้องหน้าจอ Dashboard ตลอด 24 ชั่วโมงจนประสาทเสีย และในฐานะเพื่อนมนุษย์ เราต้องเคารพ “สิทธิในการตัดขาดและพื้นที่ส่วนตัว” (Right to Privacy & Disconnect) เมื่อแก้ปัญหาเสร็จ เมื่อจบเวลางาน หรือเมื่อถึงเวลาพักผ่อน จงแตะไม้กายสิทธิ์พับแผนที่เก็บ ปิดหน้าจอลง และปล่อยให้ทุกคนได้ใช้ชีวิตอย่างอิสระโดยไม่มีสายตาของใครคอยจ้องมอง

บทสรุป: หัวใจของคนถือแผนที่

เทคโนโลยีการติดตามและวัดผล — ไม่ว่าจะเป็น eBPF ใน Linux Kernel, หน้าจอ Grafana หรือบอร์ดจัดการงานของทีม — ล้วนเป็นเหมือนแผนที่ตัวกวนที่มีอำนาจในการเปิดเผยความจริง

แต่มันจะกลายเป็น “ของวิเศษที่ช่วยชีวิตทีม” หรือกลายเป็น “คุกวงแหวน Panopticon ที่สูบวิญญาณคนทำงาน” ไม่ได้ขึ้นอยู่กับความล้ำสมัยของเครื่องมือเลยครับ

มันขึ้นอยู่กับว่า คนที่ถือแผนที่แผ่นนั้นอยู่… มีหัวใจแบบ แฮร์รี่ พอตเตอร์ หรือมีหัวใจแบบ โดโลเรส อัมบริดจ์ ต่างหาก

Mischief Managed.

🎧 ติดตามฟังเรื่องราวการถอดรหัสโลกเวทมนตร์ด้วย Software Architecture และปรัชญาชีวิตฉบับเต็มได้ใน: รายการ Uncle Quin Podcast EP.61 | แผนที่ตัวกวน (The Marauder’s Map)

หากคุณชอบบทความแนวการเชื่อมโยงปรัชญาเข้ากับการทำงานในโลกยุคใหม่ ฝากกดเลิฟ กดแชร์ และกดติดตามช่องของผมด้วยนะครับ!

• Spotify
• YouTube

แผนที่ตัวกวน (The Marauder’s Map) was originally published in odds.team on Medium, where people are continuing the conversation by highlighting and responding to this story.

คุณเคยเจออาการแบบนี้ตอนตีสองไหมครับ?

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

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

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

และอาวุธลับที่ดัมเบิลดอร์ใช้กอบกู้สมองของตัวเองกลับมา ก็คือสิ่งประดิษฐ์เวทมนตร์ที่เรียกว่า “อ่างเพนซิฟ” (The Pensieve)

หากเราถอดเสื้อคลุมพ่อมดออก แล้วสวมแว่นตาของ สถาปัตยกรรมซอฟต์แวร์ (Software Architecture) และ จิตวิทยาการรู้คิด (Cognitive Psychology) เราจะพบว่าอ่างเพนซิฟไม่ใช่แค่จินตนาการแฟนตาซี แต่มันคือแบบจำลองการจัดการหน่วยความจำและการดีบั๊กชีวิตที่เฉียบคมที่สุดชิ้นหนึ่งครับ

1. Out of Memory & Thrashing: ทำไมยิ่งคิดในหัว ยิ่งแก้ปัญหาไม่ออก?

ในหนังสือ Harry Potter and the Goblet of Fire แฮร์รี่บังเอิญไปเจออ่างหินตื้น ๆ ที่มีอักษรรูนสลักอยู่รอบขอบ ข้างในมีสสารสีเงินสว่างหมุนวนอยู่ ดัมเบิลดอร์เอาปลายไม้กายสิทธิ์แตะที่ขมับของตัวเอง ดึงเส้นใยความทรงจำสีเงินออกมาจากหัว แล้วหย่อนลงไปในอ่าง ก่อนจะอธิบายให้แฮร์รี่ฟังว่า:

“บางครั้งฉันก็รู้สึกว่ามีเรื่องราวและข้อมูลอัดแน่นอยู่ในหัวมากเกินไป จนมันปั่นป่วนไปหมด… เวลาแบบนั้น ฉันก็จะใช้เพนซิฟนี่แหละ สูบเอาความคิดส่วนเกินออกไปพักไว้ในอ่าง พอสมองโล่งขึ้น ฉันก็จะมีพื้นที่ว่างพอที่จะมองเห็นรูปแบบและความเชื่อมโยงของเรื่องราวพวกนั้นได้ชัดเจนขึ้น”

ในทางคอมพิวเตอร์ สมองส่วนหน้าของเราที่ใช้คิดวิเคราะห์ (Working Memory) ทำหน้าที่เหมือน RAM (Random Access Memory) ครับ ข้อดีของมันคือดึงข้อมูลมาประมวลผลได้เร็วมาก แต่ข้อจำกัดที่โหดร้ายคือ “พื้นที่มันเล็กมาก”

งานวิจัยทางประสาทวิทยาระบุว่า Working Memory ของมนุษย์สามารถถือข้อมูลเพื่อประมวลผลพร้อมกันได้เพียง 4 ถึง 7 ก้อน (Chunks) เท่านั้น

เมื่อคุณพยายามแก้ปัญหาที่มีตัวแปร 20 เรื่องด้วยการ “นั่งคิดในหัว” สิ่งที่เกิดขึ้นกับสมองคืออาการเดียวกับเซิร์ฟเวอร์ที่เกิด Out of Memory (OOM) และนำไปสู่สภาวะที่วิศวกรระบบกลัวที่สุดที่เรียกว่า Thrashing

Thrashing คือสภาวะที่ RAM เต็มจนระบบต้องคอยสลับข้อมูลเข้า-ออกระหว่าง RAM กับ Disk ตลอดเวลา ผลลัพธ์คือ CPU วิ่ง 100% เครื่องร้อนจี๋ พัดลมดังสนั่น แต่โปรแกรมไม่ขยับไปไหนเลย เหมือนกับสมองของเราตอนตีสองที่ใช้พลังงานชีวิตเกือบทั้งหมดไปกับการพยายาม “ประคองไม่ให้ลืมว่าเมื่อกี้คิดถึงไหนแล้ว” แทนที่จะได้ใช้พลังงานนั้นไปกับการ “วิเคราะห์หาทางออก” จริง ๆ

การที่ดัมเบิลดอร์ดึงเส้นใยความทรงจำออกจากขมับไปเทลงอ่างเพนซิฟ จึงเทียบเท่ากับการทำ Memory Dump (Core Dump) หรือการทำ Offloading เอาสถานะ (State) ที่ค้างอยู่ใน RAM เขียนลงสู่ External Storage ทันทีที่ความคิดถูกถ่ายโอนออกไป พื้นที่ใน RAM ก็ว่างลง และสมองก็พร้อมกลับมาคำนวณหาความเชื่อมโยงที่ซับซ้อนได้อีกครั้ง

2. Mutable State vs. Event Sourcing: ความทรงจำที่ถูกอารมณ์เขียนทับ

แต่ความอัจฉริยะของอ่างเพนซิฟไม่ได้หยุดอยู่แค่การเคลียร์ RAM ครับ จุดที่น่าสนใจที่สุดคือ “วิธีที่มันเก็บข้อมูล”

เคยสังเกตไหมครับว่า เวลาเรานั่งนึกย้อนไปถึงปัญหาหรือความขัดแย้งในหัวตัวเอง (เช่น ตอนที่ระบบล่ม หรือตอนที่เถียงกับเพื่อนร่วมงาน) ยิ่งนึกย้อนกลับไปกี่ครั้ง เราก็มักจะยิ่งเครียด ยิ่งโกรธ หรือยิ่งโทษตัวเองมากขึ้นเรื่อย ๆ?

นั่นเป็นเพราะหน่วยความจำในหัวมนุษย์ทำงานเหมือนฐานข้อมูลแบบ Mutable State (สถานะที่ถูกแก้ไขทับได้) ครับ สมองของเราไม่ได้บันทึกอดีตเป็นไฟล์วิดีโอที่เที่ยงตรง แต่มันบันทึกเฉพาะ “ความรู้สึกและข้อสรุปสุดท้าย” ทุกครั้งที่เราดึงความทรงจำขึ้นมาคิดในหัว อารมณ์ความกลัว อคติ และอีโก้ในปัจจุบันของเราจะแอบทำคำสั่ง UPDATE เขียนทับความทรงจำเดิมเสมอ จนเราแยกไม่ออกแล้วว่าอะไรคือสิ่งที่เกิดขึ้นจริง (Fact) และอะไรคือสิ่งที่เราปรุงแต่งขึ้นมาเอง (Interpretation)

ในทางกลับกัน อ่างเพนซิฟทำงานด้วยสถาปัตยกรรมที่เรียกว่า Event Sourcing (Immutable Event Log)

เมื่อความทรงจำถูกเทลงในอ่างเพนซิฟ มันจะกลายเป็นบันทึกเหตุการณ์ที่ แก้ไขย้อนหลังไม่ได้ (Immutable) และเก็บรายละเอียดทุกอย่างตามที่ประสาทสัมผัสรับเข้ามาจริง ๆ แบบไร้ฟิลเตอร์อารมณ์ เหมือนตอนที่แฮร์รี่ดำดิ่งลงไปในความทรงจำของสเนป หรือตอนที่ดัมเบิลดอร์พาย้อนไปดูอดีตของโวลเดอมอร์ พวกเขาสามารถเดินสำรวจรอบ ๆ ห้อง สังเกตสีหน้าของคนอื่นที่อยู่มุมห้อง หรือได้ยินบทสนทนาที่ตอนเกิดเหตุจริงเจ้าของความทรงจำอาจไม่ได้สนใจฟังด้วยซ้ำ

3. Third-Person Debugging: เปลี่ยนจาก “ผู้ประสบภัย” เป็น “นักสืบ”

ทำไมเวลาใช้อ่างเพนซิฟ พ่อมดถึงต้องเอาหน้าจุ่มลงไป แล้วลงไปเดินดูเหตุการณ์เคียงข้างตัวเองในอดีต?

ในมุมของการแก้ปัญหา นี่คือการทำ Third-Person Debugging (การดีบั๊กจากมุมมองบุคคลที่สาม) ครับ

ตราบใดที่ปัญหายังวิ่งวนอยู่ในหัวของคุณ คุณกำลังมองมันผ่านมุมมองบุคคลที่หนึ่ง (First-Person View) คุณคือ “ตัวละครเอกที่กำลังจมอยู่ในดราม่า” เมื่อตัวตนของคุณผูกติดอยู่กับปัญหา ความกลัวจะบังตาจนคุณมองไม่เห็นทางออก

แต่ทันทีที่คุณดึงความคิดนั้นออกมาวางไว้ข้างนอกตัว — ไม่ว่าจะในอ่างเพนซิฟ หรือบนหน้ากระดาษ — คุณได้ทำการแยก (Decouple) “ตัวคุณ” ออกจาก “ความคิดของคุณ” ทันที คุณเปลี่ยนสถานะจากผู้ประสบภัยในเหตุการณ์ กลายเป็น “นักสืบ”ที่ยืนกอดอกมองดูเหตุการณ์นั้นจากด้านนอกอย่างเป็นกลาง และนั่นคือวินาทีที่คุณจะร้องอ๋อว่า จุดที่ระบบพังจริง ๆ มันอยู่ตรงไหน

4. สร้าง “อ่างเพนซิฟ” สำหรับชาวมักเกิ้ล

แม้เราจะไม่มีไม้กายสิทธิ์และอ่างหินสลักอักษรรูน แต่เราสามารถสร้างสถาปัตยกรรมอ่างเพนซิฟให้กับชีวิตและการทำงานของทีมได้ผ่าน 3 กลไกนี้ครับ:

1. Personal Pensieve: เขียนก่อน จัดระเบียบทีหลัง (Brain Dump)

เมื่อไหร่ที่รู้สึกว่าสมองเริ่มเกิดอาการ Thrashing คิดวนซ้ำ ๆ เกิน 2 รอบ ห้ามพยายามคิดต่อในหัวเด็ดขาด ให้เปิดหน้าโน้ตเปล่า ๆ (เช่น ใน Obsidian หรือสมุดคู่ใจ) แล้วเททุกอย่างที่อยู่ในหัวออกมาเป็นตัวหนังสือแบบไม่ต้องคัดกรอง ไม่ต้องสนโครงสร้างหรือความสวยงาม (Write first, organize later) แค่ย้ายข้อมูลจาก RAM ลงสู่ Disk ให้ครบ สมองของคุณจะเบาลงทันทีเกินครึ่ง

2. The Pensieve Review: อ่านโน้ตตัวเองด้วยสายตาของคนนอก

หลังจากเทความคิดลงกระดาษแล้ว ให้พักสมองหรือนอนหลับไปก่อน รอให้ฝุ่นของอารมณ์จางลง แล้วค่อยกลับมาอ่านโน้ตนั้นอีกครั้งในวันรุ่งขึ้นด้วยสายตาของ “บุคคลที่สาม” ขีดเส้นใต้แยกให้ออกว่าประโยคไหนคือ Immutable Event (ข้อเท็จจริงที่เกิดขึ้น) และประโยคไหนคือ Mutable Emotion (ความกังวลที่เราคิดไปเอง) เมื่อเห็นข้อมูลกางอยู่ตรงหน้า คุณจะลากเส้นเชื่อมโยงหาทางออกได้อย่างง่ายดาย

3. Team Pensieve: วัฒนธรรม Blameless Post-mortem และ ADR

ในระดับทีม เวลาที่เกิดวิกฤตระบบล่มหรือตัดสินใจผิดพลาด อย่าปล่อยให้ทีมนั่งเถียงกันด้วย “ความทรงจำในหัว” เพราะแต่ละคนจะมีฟิลเตอร์ป้องกันตัวเองเสมอ ให้สร้างอ่างเพนซิฟส่วนกลางด้วยการทำ Blameless Post-mortem หรือ Architecture Decision Records (ADR) นำ Timeline ของเหตุการณ์จริง, กราฟ Metrics และ Log ทั้งหมดมาวางกางรวมกัน แล้วชวนทุกคนมายืนมองดูเหตุการณ์นั้นเคียงข้างกันในฐานะนักสืบ เพื่อหาว่า “ขั้นตอนไหนในระบบที่ทำให้เราพลาด” ไม่ใช่ “ใครเป็นคนทำพัง”

บทสรุป: วางไม้กายสิทธิ์ แล้วหยิบปากกา

ความลับของพ่อมดที่ฉลาดที่สุด อาจไม่ใช่การมีสมองที่จำทุกอย่างได้ไม่รู้ลืม แต่คือการรู้ขีดจำกัดของสมองตัวเอง และรู้ว่าเมื่อไหร่ที่ควร “วางความคิดลง”

คืนนี้ หากคุณพบว่าตัวเองกำลังนอนจ้องเพดานพร้อมกับเส้นใยความคิดสีเงิน ๆ ที่พันกันยุ่งเหยิงอยู่ในหัว ลองหยิบไม้กายสิทธิ์ของชาวมักเกิ้ล — ไม่ว่าจะเป็นปากกาหรือคีย์บอร์ด — ดึงความกังวลเหล่านั้นออกมาพักไว้ในอ่างเพนซิฟของคุณดูนะครับ

เมื่อสมองว่างพอ ความจริงจะปรากฏขึ้นเองเสมอ

🎧 ติดตามฟังเรื่องราวการถอดรหัสโลกเวทมนตร์ด้วย Software Architecture และปรัชญาชีวิตฉบับเต็มได้ใน: รายการ Uncle Quin Podcast EP.60 | อ่างเพนซิฟ (The Pensieve Protocol)

หากคุณชอบบทความแนวการเชื่อมโยงปรัชญาเข้ากับการทำงานในโลกยุคใหม่ ฝากกดเลิฟ กดแชร์ และกดติดตามช่องของผมด้วยนะครับ!

• Spotify
• YouTube

อ่างเพนซิฟ (The Pensieve Protocol): Memory Dump, Event Sourcing… was originally published in odds.team on Medium, where people are continuing the conversation by highlighting and responding to this story.