จากห้องทำงานของนักปรัชญา สู่หน้าจอของ Developer: เมื่อแนวคิด Kierkegaard ปลดล็อกการพัฒนา Software
ลองจินตนาการถึงสถานการณ์ที่คุณกำลังเผชิญในโปรเจกต์ซอฟต์แวร์ปัจจุบัน: ทีมของคุณต้องการความเร็วเพื่อปล่อยฟีเจอร์ใหม่ให้ทันตลาด (Living Forward) แต่ในขณะเดียวกัน โค้ดเก่าที่เต็มไปด้วยหนี้ทางเทคนิค (Technical Debt) ก็กำลังฉุดรั้งให้ทุกอย่างช้าลง จนคุณต้องหยุดเพื่อทำความเข้าใจและตามแก้ปัญหาเดิมๆ (Understanding Backward)
ภาวะกลืนไม่เข้าคายไม่ออก (Dilemma) นี้ ไม่ใช่เรื่องใหม่ในประวัติศาสตร์มนุษยชาติ เพราะเมื่อร้อยกว่าปีก่อน เซอเรน เคียร์เคอการ์ (Søren Kierkegaard) นักปรัชญาชาวเดนมาร์ก ได้เคยบันทึกวลีคลาสสิกไว้ในไดอารี่ของเขาว่า:
“ชีวิตนั้นทำความเข้าใจได้ด้วยการมองย้อนกลับไปข้างหลัง แต่ต้องดำเนินต่อไปข้างหน้า” — Søren Kierkegaard
ในโลกของการพัฒนาซอฟต์แวร์ วาทะนี้ไม่ได้เป็นแค่ประโยคปรัชญาเท่ๆ แต่คือ “เข็มทิศ” ในการบริหารจัดการระบบและทีมทำงานได้อย่างยั่งยืน ผ่าน 3 มิติสำคัญ ดังนี้ครับ
1. มองย้อนกลับเพื่อเข้าใจ (Understanding Backward)
ในมิตินี้ อดีตคือบทเรียนและข้อมูลดิบที่ดีที่สุด ซอฟต์แวร์ไม่มีทางพัฒนาอย่างถูกทิศทางหากขาดการวิเคราะห์สิ่งเสร็จสิ้นไปแล้ว เราประยุกต์ใช้สิ่งนี้ผ่าน:
- Agile Retrospective: ทุกครั้งที่จบ Sprint ทีมจะหยุดเดินชั่วคราวเพื่อ “มองย้อนกลับไป” ว่าอะไรทำได้ดี อะไรที่เป็นปัญหา เพื่อให้เข้าใจพฤติกรรมของทีมและระบบ ก่อนจะก้าวไปในสัปดาห์ถัดไป
- Root Cause Analysis (RCA) & Post-mortem: เมื่อระบบล่ม (Incidents) การดันทุรังซ่อมส่งๆ เพื่อให้เดินหน้าต่อได้เร็วที่สุดมักจบด้วยการล่มซ้ำซาก เราจำเป็นต้อง “มองย้อนกลับ” ไปแกะรอย Log, Metrics, และประวัติการ Commit เพื่อทำความเข้าใจบริบทที่แท้จริงของความผิดพลาด
- Legacy Code & Telemetry Data: โค้ดเก่าและข้อมูลการใช้งานจริงของ User (Data Analytics) คือกระจกเงาชั้นดีที่บอกว่าสถาปัตยกรรมเดิมที่เราวางไว้ตอบโจทย์จริงหรือไม่
2. ดำเนินต่อไปข้างหน้า (Living Forward)
เคียร์เคอการ์ชี้ให้เห็นว่า เวลาไม่เคยหยุดวิ่งเพื่อให้เราทำความเข้าใจ reality ได้แบบร้อยเปอร์เซ็นต์ ในธุรกิจซอฟต์แวร์ก็เช่นกัน การจมปลักอยู่กับอดีตหรือรอจนกว่าข้อมูลจะสมบูรณ์แบบจะทำให้เกิดภาวะ “Analysis Paralysis” (วิเคราะห์จนเป็นอัมพาต) และนั่นเท่ากับการตายของโปรดักต์
- Iterative & Incremental Development: เราไม่มีวันรู้ Requirements ทั้งหมดในวันแรก และไม่มีวันเขียนโค้ดที่สมบูรณ์แบบได้ตั้งแต่ Version 1.0 สิ่งที่ต้องทำคือการปล่อยฟีเจอร์ออกไป (Ship Code) เพื่อให้ซอฟต์แวร์ได้ทำหน้าที่ของมันในโลกความจริง
- Technical Debt Management: บางครั้งเราจำเป็นต้องยอมสร้าง “หนี้ทางเทคนิค” (Technical Debt) เพื่อแลกกับความเร็วในการตลาด (Time-to-Market) ยอมเลือกทางเลือกที่ไม่ได้ดีที่สุดในวันนี้ เพื่อให้โปรเจกต์เดินหน้าต่อไปได้ก่อน
3. จุดตัดที่ลงตัว: การรีแฟกเตอร์ (Refactoring)
ความสอดประสานของแนวคิดนี้เกิดขึ้นที่ “การรีแฟกเตอร์โค้ด” (Refactoring) และการออกแบบสถาปัตยกรรมที่ปรับแต่งได้ (Evolutionary Architecture)
ซอฟต์แวร์ที่ดีไม่ได้เกิดจากการออกแบบให้สมบูรณ์แบบตั้งแต่เริ่มต้น แต่เกิดจากการออกแบบให้ “ปรับปรุงง่าย” เมื่อเรามีความเข้าใจมากขึ้นในอนาคต
เมื่อเราเดินหน้าสร้างฟีเจอร์ไปซักพัก (Living Forward) เราจะเริ่มสะสมความรู้และความเข้าใจในตัวระบบและพฤติกรรมผู้ใช้มากขึ้น (Understanding Backward) จากนั้นเราจึงนำความเข้าใจนั้นย้อนกลับมาปรับโครงสร้างโค้ดเดิมให้ดีขึ้น โดยที่ระบบยังสามารถส่งมอบฟีเจอร์ใหม่ๆ ต่อไปได้เรื่อยๆ โดยไม่หยุดชักงัก
บทสรุปสำหรับคนทำ Tech
ความจริงที่โหดร้ายแต่สวยงามในโลกของ Tech คือ เราถูกกำหนดให้ต้องทำงานภายใต้ข้อมูลและเวลาที่จำกัดเสมอ
หากคุณนำ Quote ของ Kierkegaard มาสกรีนแปะไว้ที่ฝาผนังของห้องทีมพัฒนา มันจะเป็นสิ่งเตือนใจชั้นดีให้กับ Developer ทุกคนว่า:
“เราเขียนโค้ดวันนี้ด้วยความรู้ที่ดีที่สุดที่มี แต่อย่ากลัวที่จะกลับมาแก้ไขมันในวันพรุ่งนี้เมื่อเราฉลาดขึ้น”
ลองนำแนวคิดนี้ไปปรับใช้กับทีมของคุณดูครับ แล้วคุณจะพบว่าการ “มองย้อนหลัง” ไม่ได้ทำให้เราช้าลง แต่มันช่วยให้เรา “ก้าวไปข้างหน้า” ได้อย่างมั่นคงและถูกทิศทางมากขึ้น
หากคุณชอบบทความแนวการเชื่อมโยงปรัชญาเข้ากับการทำงานในโลกยุคใหม่ ฝากกดเลิฟ กดแชร์ และกดติดตามช่องของเราด้วยนะครับ!
