วนเวียนแต่ไม่วนลูป: เมื่อชีวิตคือฟังก์ชัน Recursion และการเดินทางสู่พื้นที่ปลอดภัย

Share
วนเวียนแต่ไม่วนลูป: เมื่อชีวิตคือฟังก์ชัน Recursion และการเดินทางสู่พื้นที่ปลอดภัย
Photo by Dan Freeman on Unsplash

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


สำหรับสถาปนิกซอฟต์แวร์หรือนักพัฒนาโปรแกรม ภาพของปัญหาที่ซ้อนทับและเรียกใช้รูปแบบเดิมลึกลงไปแบบนี้ มีคำศัพท์เฉพาะที่เรียกว่า “Recursion” (การเรียกซ้ำ)

คนส่วนใหญ่มักมองว่า Recursion เป็นแนวคิดที่เข้าใจยาก ชวนเวียนหัว หรืออาจจะดูมืดมนจนนำไปสู่สภาวะระบบค้าง (Stack Overflow) แต่หากเราลองแงะแก่นคิดของโครงสร้างซอฟต์แวร์นี้ออกมาดูอย่างละเอียด เราจะพบว่าแท้จริงแล้ว Recursion ไม่ได้ถูกสร้างขึ้นมาเพื่อให้เราหลงทาง แต่เป็นศาสตร์แห่งการ “ย่อยปัญหา” ที่เต็มไปด้วยความหวังและความชัดเจน

1. Loop vs Recursion: บันไดวนที่มุ่งไปข้างหน้า

ในโลกของคอมพิวเตอร์ เวลาที่เราต้องการให้ระบบทำงานบางอย่างซ้ำ ๆ เครื่องมือที่เบสิกที่สุดคือการใช้ Loop (เช่น for หรือ while) มันคือการสั่งให้ระบบก้าวเดินเป็นวงกลมบนพื้นราบ คุณเดินผ่านพิกัดเดิม สภาวะแวดล้อม (Context) เดิม ทำซ้ำไปเรื่อย ๆ จนกว่าจะครบจำนวนรอบที่กำหนด

แต่ Recursion แตกต่างออกไปอย่างสิ้นเชิง

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

มนุษย์เราก็รันฟังก์ชัน Recursion ในสมองอยู่ตลอดเวลาผ่านการคิดทบทวนเกี่ยวกับความคิดตัวเอง (Thinking about thinking) แต่ความผิดพลาดที่ทำให้เราเกิดอาการสมองล้า หรือหมดไฟ (ซึ่งเทียบเท่ากับอาการ Stack Overflow ในคอมพิวเตอร์) ไม่ใช่เพราะเราคิดซ้ำ แต่เป็นเพราะเราควบคุมทิศทางของบันไดวนนั้นไม่ได้ เราแบกรับความเครียดของทุก ๆ ชั้นสะสมไว้จนหน่วยความจำเต็ม

แต่ระบบคอมพิวเตอร์ที่ชาญฉลาดจะไม่ยอมให้เกิดสิ่งนั้น เพราะในสถาปัตยกรรมที่ดีย่อมมีกลไกที่เรียกว่า Base Case เสมอ

2. Base Case: พื้นที่ปลอดภัยและจุดหมายที่ชัดเจน

ฟังก์ชัน Recursion จะไม่มีวันสมบูรณ์เลยหากขาดสิ่งที่เรียกว่า Base Case หรือ “เงื่อนไขสิ้นสุด”

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

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

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

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

3. Unwinding the Stack: พลังของการสะท้อนกลับ

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

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

เมื่อเราโฟกัสและเคลียร์ปัญหาที่ระดับล่างสุด (Base Case) ได้สำเร็จ ปรากฏการณ์ที่สวยงามที่สุดของ Recursion จะเกิดขึ้น ซึ่งในทางระบบเราเรียกว่า “Unwinding the Stack” หรือการสะท้อนกลับขึ้นมา

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

บทสรุปจากห้องสถาปัตยกรรม

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

ลองกลับมาสำรวจฟังก์ชันชีวิตที่คุณกำลังรันอยู่ตอนนี้:

  • คุณกำลังก้าวเดินเป็นวงกลมอยู่ที่เดิม (Loop) หรือกำลังก้าวลงบันไดวนเพื่อมุ่งไปข้างหน้า (Recursion)?
  • และที่สำคัญที่สุด… คุณกำหนด Base Case หรือจุดหมายปลายทางที่เรียบง่ายและชัดเจนให้กับตัวเองแล้วหรือยัง?

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


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

Read more

The Five Ideals

The Five Ideals

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

By Chokchai Phatharamalai
Communication, Reliability and Modern concepts - System Design, Simply Explained

Communication, Reliability and Modern concepts - System Design, Simply Explained

บทความนี้จะอธิบายพื้นฐานของ System Design โดยต่อยอดจากตัวอย่าง Gym Application เพื่อให้เห็นภาพว่า เมื่อระบบเริ่มเติบโตและถูกแยกออกเป็นหลาย Service แต่ละ Service จะสื่อสารและทำงานร่วมกันอย่างไร งานแบบไหนควรสื่อสารแบบ Synchronous งานแบบไหนควรประมวลผลแบบ Asynchronous รวมถึงอธิบาย Concept พื้นฐานต่าง ๆ ที่ควรรู้ เช่น API

By Boonsong Srithong
Race condition

Race condition

ผมกำลังอ่านหนังสือ The Unicorn Project ซึ่งเป็นนิยายเกี่ยวกับ developer สาวคนหนึ่งที่ใช้ชีวิตในองค์กรท่ามกลางกระแส digital disruption อ่านแล้วสนุกมาก เป็นเรื่องที่ตื่นเต้น และหลาย ๆ dynamic ที่เกิดขึ้นก็คล้ายกับที่ผมพบเจอในบริษัทซอฟต์แวร์ เลยทำให้

By Chokchai Phatharamalai
Distributed Systems Concepts - System Design, Simply Explained

Distributed Systems Concepts - System Design, Simply Explained

ในช่วงแรก Product เราสามารถออกแบบระบบให้อยู่ใน Server และ Database เดียวกันได้ แต่เมื่อระบบโตขึ้น มีผู้ใช้งานเพิ่มขึ้น ข้อมูลเยอะขึ้น ระบบเริ่มทำงานช้าลดเรื่อยๆ สิ่งที่หนีไม่ได้คือการ Decomposition Service ไปเป็น Distributed System เช่น Member Service, Booking Service, Payment

By Boonsong Srithong