The Second Law of Software: ทำไม Code ของเราถึงรกขึ้นตามกาลเวลา?

ในโลกของฟิสิกส์ มีกฎเหล็กข้อหนึ่งที่ไม่มีใครหนีพ้น ไม่ว่าจะเป็นดวงดาวที่ดับสูญ หรือกาแฟที่เย็นชืดลงในทุกเช้า กฎข้อนั้นคือ “กฎข้อที่สองของอุณหพลศาสตร์” (The Second Law of Thermodynamics)

แต่รู้หรือไม่ว่า กฎข้อนี้ไม่ได้อยู่แค่ในตำราฟิสิกส์ แต่มันกำลังทำงานอยู่ใน Project Folder ของคุณตอนนี้เลย

Entropy: แขกที่ไม่ได้รับเชิญใน Codebase

ในทางฟิสิกส์ Entropy คือค่าที่ใช้วัด “ความไร้ระเบียบ” (Disorder) ของระบบ กฎข้อที่สองบอกเราว่า ในระบบปิด ค่า Entropy จะเพิ่มขึ้นเสมอ

ลองจินตนาการถึงห้องที่สะอาดกวาดถูอย่างดี ถ้าคุณปล่อยทิ้งไว้โดยไม่ทำความสะอาดเลยเป็นปีๆ มันจะเต็มไปด้วยฝุ่นและหยากไย่ Software ก็เช่นกัน:

• Day 1: ทุกอย่างสวยงาม Clean Architecture, SOLID Principles จัดเต็ม
• Month 6: เริ่มมี “Logic พิเศษ” สำหรับลูกค้าเจ้าใหญ่
• Year 2: ทุกคนในทีมกลัวการแตะโค้ดส่วนนั้น เพราะกลัวทำพัง

ความเน่าเฟะนี้ไม่ใช่เรื่องบังเอิญ แต่มันคือ “Software Entropy”

ทำไม Code ถึง “รก” เองได้?

ทำไมเราถึงรักษาความสะอาดของโค้ดไว้ไม่ได้ตลอดไป? ในมุมมองของฟิสิกส์ มีสาเหตุหลัก 3 ประการ:

1. The Pressure of Change (แรงดันจากการเปลี่ยนแปลง): ทุกครั้งที่มี Requirement ใหม่เข้ามา มันคือการใส่แรงกระแทกเข้าไปในโครงสร้างเดิม ถ้าเราไม่ได้ออกแบบมาเพื่อรองรับแรงนั้น โครงสร้างจะเริ่มมี “รอยร้าว”
2. Knowledge Decay (การสลายตัวของความรู้): เมื่อคนเขียนคนเดิมลาออก หรือเราลืมว่าทำไมวันนั้นถึงเขียนแบบนี้ ความเข้าใจในระบบ (Information) จะลดลง ซึ่งในทางฟิสิกส์ การสูญเสียข้อมูลคือการเพิ่มขึ้นของ Entropy โดยตรง
3. External Dependencies: Library ที่เราใช้มีการ Update หรือเลิก Support (Deprecation) สิ่งนี้เหมือนสภาพแวดล้อมภายนอกที่กัดกร่อนระบบของเราให้ผุพังลง

Technical Debt คือ “ความ(หัว)ร้อน” ที่สูญเสียไป

ในเครื่องจักรความร้อน ไม่มีเครื่องยนต์ไหนที่มีประสิทธิภาพ 100% พลังงานบางส่วนจะสูญเสียไปในรูปของความร้อนเสมอ

ในการพัฒนา Software พลังงานของนักพัฒนา (Developer Energy) ก็สูญเสียไปกับ Technical Debt เช่นกัน:

• ในระบบที่ Entropy ต่ำ: คุณใช้พลังงาน 10 หน่วย เพื่อสร้าง Feature ใหม่ได้ 10 หน่วย
• ในระบบที่ Entropy สูง: คุณใช้พลังงาน 10 หน่วย แต่ต้องหมดไปกับการแก้ Bug และไล่หา Logic ที่ซับซ้อน 8 หน่วย เหลือสร้าง Feature จริงได้แค่ 2 หน่วย

ความร้อนที่สูญเสียไปนี้เอง คือต้นทุนที่แท้จริงของ Technical Debt

วิธีสู้กับกฎของจักรวาล: Negentropy

เราไม่สามารถหยุด Entropy ได้ แต่เราชะลอและลดมันได้ด้วยการสร้าง Negative Entropy (Negentropy) หรือการใส่ “พลังงานสะอาด” กลับเข้าไปในระบบ:

• Refactoring: คือการยอมจ่ายพลังงานในวันนี้ เพื่อลดความไร้ระเบียบในวันหน้า เป็นการจัดเรียงโมเลกุลของโค้ดให้กลับมาเข้าที่
• Automated Testing: ทำหน้าที่เป็น “ขอบเขต” (Boundary) ที่ช่วยกั้นไม่ให้ความไร้ระเบียบกระจายตัวไปส่วนอื่นๆ
• Documentation & Knowledge Sharing: คือการรักษาค่า Information ไม่ให้หายไปตามกาลเวลา

บทสรุป: Software ไม่ใช่ตึก แต่คือสวน

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

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

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

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

• Spotify
• YouTube
• Apple Podcasts

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

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

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