The Stoic Programmer: เขียนโค้ดอย่างไรให้ใจไม่พัง

Share
The Stoic Programmer: เขียนโค้ดอย่างไรให้ใจไม่พัง
Photo by Tyler Lastovich on Unsplash

ในมหานครที่ฉาบด้วยแสงนีออนและความโกลาหลของข้อมูล เหล่าโปรแกรมเมอร์มักจะติดอยู่ในวงจรของการพยายามควบคุมสิ่งที่ควบคุมไม่ได้ เราภาวนาให้ Network ไม่ล่ม เราอ้อนวอนให้ User ใส่ Input ที่ถูกต้อง และเราเจ็บปวดเมื่อระบบ panic! พังทลายลงต่อหน้า

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

1. แยกแยะสิ่งที่ควบคุมได้และไม่ได้ (Dichotomy of Control)

แก่นของสโตอิกคือการยอมรับความจริงอันโหดร้ายว่า เราควบคุมสิ่งภายนอกไม่ได้เลย

  • สิ่งที่ควบคุมไม่ได้: 3rd party services อาจจะล่ม หรือแม้แต่พฤติกรรมที่คาดเดาไม่ได้ของผู้ใช้งาน
  • สิ่งที่ควบคุมได้: โครงสร้างของ Logic, การออกแบบระบบ Error Handling, และที่สำคัญที่สุดคือ “ปฏิกิริยา” ของเราต่อปัญหา

เมื่อคุณเขียน Rust คุณกำลังฝึกฝนวิถีสโตอิก เพราะ Rust ไม่ยอมให้คุณเพิกเฉยต่อความไม่แน่นอน

2. Error Handling: การยอมรับความจริงผ่าน Result และ Option

ในภาษาอื่น Error อาจเป็นเรื่องน่าตกใจ แต่ใน Rust… Error คือเรื่องธรรมดา การใช้ Result<T, E> คือการประกาศว่า "ฉันรู้ว่างานนี้อาจจะล้มเหลว"

แทนที่จะปล่อยให้โปรแกรมระเบิดตัวเองด้วย Exception เราใช้ match เพื่อแกะความจริงออกมาดูทีละชั้น หากมันคือ Ok(data)เราก็ก้าวต่อไป หากมันคือ Err(e) เราก็รับมือมันด้วยความสงบนิ่ง นี่คือการมีสติ (Mindfulness) ในรูปแบบของโค้ด

3. Immutability: ความนิ่งสงบในโลกที่แปรปรวน

ในยุคที่เราถูกรุมเร้าด้วยสถานะที่เปลี่ยนแปลงตลอดเวลา (Mutable State) ความสงบมักหายไปได้ง่ายๆ Rust จึงมอบพลังของ Immutability มาเป็นค่าเริ่มต้น

เมื่อคุณกำหนดให้ข้อมูลเป็น Immutable คุณกำลังสร้างความมั่นคง (Certainty) ขึ้นมาท่ามกลางความโกลาหล ข้อมูลนั้นจะไม่ถูกเปลี่ยนโดยมือมืดที่เราควบคุมไม่ได้จาก Thread อื่น มันคือการรักษา “จุดยืนที่มั่นคง” ของระบบให้ยังคงอยู่แม้พายุแห่งข้อมูลจะโหมกระหน่ำ

บทสรุป

การเป็น The Stoic Programmer ไม่ใช่แค่เรื่องของการจัดการหน่วยความจำ หรือการเขียนโค้ดให้ปลอดภัย แต่คือการเข้าใจว่า บั๊กและข้อผิดพลาดเป็นส่วนหนึ่งของวิถีชีวิต

พันธกิจของ Software Engineer ไม่ใช่เพียงการพยายามสร้างระบบที่สมบูรณ์แบบจนไม่มีวันเกิดข้อผิดพลาด แต่คือการออกแบบระบบให้มีความ Resilience หรือความสามารถในการรับมือกับความไม่แน่นอนได้อย่างชาญฉลาด เพื่อให้ธุรกิจดำเนินต่อไปได้อย่างราบรื่นแม้ในสภาวะวิกฤต ซึ่งทัศนคติที่มั่นคงของผู้ออกแบบนี้เอง คือหัวใจสำคัญของการสร้างเทคโนโลยีที่ยั่งยืน

Uncle Quin
Bit Crafter / Philosopher of the Void


หากบทความนี้มีประโยชน์

คุณสามารถติดตาม Late Night with Uncle Quin ได้ทาง

ที่ที่เราคุยกันเรื่อง software, engineering mindset และอนาคตของ developer

แบบไม่ต้องใส่สูท

แต่ใส่ความจริงของวงการเข้าไปเต็ม ๆ

Read more

เริ่มต้นกับ Functional Programming

เริ่มต้นกับ Functional Programming

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

By Chokchai Phatharamalai
Values ของ Framework ต่าง ๆ

Values ของ Framework ต่าง ๆ

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

By Chokchai Phatharamalai
Accepted Responsibility

Accepted Responsibility

ช่วงนี้ผมกำลังอ่านหนังสือ Extreme Programming Explained ของ Kent Beck แล้วก็ได้เจอหัวข้อหนึ่งที่กระทบใจ คือ principle ที่เรียกว่า Accepted Responsibility Principle คืออะไร? ในหนังสืออธิบายว่า Principle คือหลักการที่ทำให้ Values ของ XP กลายเป็น Practices ได้

By Chokchai Phatharamalai
The Five Ideals

The Five Ideals

จากหนังสือ The Unicorn Project ในนั้นจะมีที่ปรึกษาเก่ง ๆ คนหนึ่งชื่อ Erik เป็นเหมือนเซ็นเซหาตัวยาก เดี๋ยวก็มา เดี๋ยวก็ไป ถ้าโชคดีก็จะเจอเค้าว่าง แล้วเค้าก็จะสอนอะไรที่สำคัญ ๆ แต่ฟังดูล้ำ ๆ และลึกซึ้ง

By Chokchai Phatharamalai