เมื่อ “Rewrite” เอาไม่อยู่: ถึงเวลาที่ซอฟต์แวร์สถาปนิกต้อง “Rework”
ในฐานะซอฟต์แวร์สถาปนิก เรามักถูกฝึกมาให้มองหาโครงสร้างที่ซ้ำซ้อนเพื่อปรับปรุงมันให้ดีขึ้น วินาทีที่เราเปิดเข้าไปเจอซอร์สโค้ดที่รกรุงรังเหมือนสปาเก็ตตี้ สัญชาตญาณแรกของเราคือการสแกนหา Pattern ความผิดพลาด หรือสิ่งที่เรียกว่า Code Smells จากนั้นเราจะเริ่มลงมือเปิดพิมพ์เขียวเพื่อทำการ “Rewrite” หรือ Refactor โค้ดชุดนั้นให้กลับมาสะอาด ทรงประสิทธิภาพ และอ่านง่ายภายใต้หลักการ Clean Code
กระบวนการกวาดบ้านทาสีใหม่นี้ หากมองผ่านเลนส์ของทฤษฎีคอมพิวเตอร์ระดับคลาสสิก มันดูคล้ายกับกลไกที่เรียกว่า Lambda Calculus (λ-calculus) ของ Alonzo Church ในระบบปิดทุกอย่างถูกขับเคลื่อนด้วยฟังก์ชันและกฎการย่อยรูปที่ตายตัว สิ่งที่เราทำในฐานะนักพัฒนาคือการรันกระบวนการ β-reduction หรือการนำอินพุตเข้าไปแทนที่ตัวแปร แล้วยุบย่อโครงสร้างที่เยิ่นเย้อลงมาเรื่อยๆ จนกว่ามันจะไปถึง Normal Form ซึ่งก็คือสถานะโค้ดที่กระชับและสมบูรณ์ที่สุด โดยที่ พฤติกรรมภายนอกและผลลัพธ์ของระบบยังคงเดิมไม่เปลี่ยนแปลง
แต่คำถามที่สำคัญกว่าคือ จะเกิดอะไรขึ้นถ้าวันหนึ่งเราพบว่าต่อให้เราทำ β-reduction ยุบโค้ดจนสะอาดหมดจดขนาดไหน ผลลัพธ์ปลายทางที่ได้ออกมากลับเป็นสิ่งที่ไม่มีใครต้องการอีกต่อไป?
นี่คือจุดเปลี่ยนผ่านที่น่าเจ็บปวดที่สุดในโลกการทำงานจริง เมื่อเทคโนโลยีเปลี่ยน พฤติกรรมผู้ใช้เปลี่ยน หรือสมมติฐานทางธุรกิจเมื่อหลายปีก่อนมันผิดฝาผิดตัวมาตั้งแต่ต้น ระบบเก่าไม่ได้พังเพราะมันเขียนมาไม่ดี แต่โครงสร้างแกนหลักของมันไม่สามารถตอบโจทย์ความจริงในปัจจุบันได้อีกแล้ว วินาทีนั้น การฝืนนั่งขัดเช็ดถูเสาเข็มที่หักพังเพื่อหวังให้ได้ผลลัพธ์เดิมคือเรื่องเปล่าประโยชน์ การ Rewrite เอาไม่อยู่แล้ว และระบบกำลังต้องการการ “Rework” พลิกแผ่นดินใหม่ทั้งหมด
เมื่อคำว่า Rewrite กลายร่างความแตกต่างที่ทรงพลังที่สุดระหว่างสองระบบนี้คือ อิสรภาพในการกำหนดกฎเกณฑ์ ในขณะที่ Lambda Calculus บังคับให้เราทำตามกฎการยุบรูป แต่ Term Rewriting เปิดโอกาสให้เราสวมบทบาทเป็น Rule Maker หรือผู้สร้างกฎการเปลี่ยนรูปขึ้นมาเอง โดย TRS มองระบบหรือข้อมูลเป็นโครงสร้างต้นไม้ที่มีความสัมพันธ์ซับซ้อน และทำงานผ่านสมการอย่างตรงไปตรงมาคือ
Pattern → Replacement
เมื่อเราสแกนพบ Pattern ฝั่งซ้ายมือที่เป็นตัวแทนของโครงสร้างที่หมดอายุการใช้งานหรือสร้างปัญหาซ้ำซาก แทนที่เราจะแค่ยุบมันให้เล็กลง TRS อนุญาตให้เราเขียนลูกศรชี้ไปทางขวา เพื่อ “รื้อและสลับร่าง” มันให้กลายเป็นสถาปัตยกรรมชุดใหม่ (Replacement) ที่เราดีไซน์ขึ้นมาทดแทนทันที มันคือการเปลี่ยน Logic พลิก Data Flow หรือแม้กระทั่งเปลี่ยนพฤติกรรมระบบเพื่อสลัดข้อจำกัดเดิมทิ้งไปเป็น Rework ขอบเขตของ Lambda Calculus จึงต้องถูกขยายออกไปสู่ทฤษฎีที่ยืดหยุ่นและดุดันกว่า นั่นคือ Term Rewriting System (TRS)
อย่างไรก็ตาม การลุกขึ้นมาเป็นสถาปนิกผู้คุมกฎเพื่อ Rework ระบบแบบพลิกกระดานนั้นมีความเสี่ยงสูง หากปราศจากการควบคุมที่ดี มันอาจนำพาระบบไปสู่ความวินาศยิ่งกว่าเก่า ในทฤษฎี Term Rewriting จึงได้ระบุคุณสมบัติสำคัญสองประการที่กฎการ Rework ที่ดีต้องมีอย่างเคร่งครัด
คุณสมบัติข้อแรกคือ Termination (การสิ้นสุด) กฎเกณฑ์ใหม่ที่เราสร้างขึ้นเพื่อรื้อระบบต้องมั่นใจว่าจะนำพาสถาปัตยกรรมเดินไปข้างหน้าจนถึงจุดที่นิ่งและจบงานได้จริง ไม่ใช่การตั้งกฎที่วนลูปไปมา วันนี้เปลี่ยนตามเทรนด์นี้ เดือนหน้าเปลี่ยนไปอีกเวย์อย่างไร้จุดหมาย เพราะนั่นจะทำให้ทีมงานเหนื่อยล้าจนหมดไฟ และโปรเจกต์จะไม่มีวันส่งมอบได้สำเร็จ
คุณสมบัติข้อที่สองคือ Confluence (การบรรจบกัน) ในระบบที่ยุ่งเหยิงขนาดใหญ่ มักมีจุดให้เราเลือก Rework ได้พร้อมกันหลายส่วน คุณสมบัตินี้คือการันตีว่า ไม่ว่าทีมงานคนไหนจะหยิบกิ่งก้านของปัญหาจุดใดขึ้นมา Rework ก่อนก็ตาม ทุกแรงรื้อถอนและทุกเส้นทางการแปลงรูปจะต้องวิ่งกลับมาบรรจบที่ “ภาพความจริงภาพเดียวกัน” เสมอ เพื่อให้แน่ใจว่าระบบภาพรวมจะยังคงสามารถประกอบร่างกลับมาทำงานร่วมกันได้อย่างเสถียร
สุดท้ายนี้ การก้าวเข้าไปเผชิญหน้ากับความโกลาหลเพื่อหา Pattern แล้วทำ Rework ไม่ใช่เครื่องหมายของความล้มเหลว แต่มันคือวิวัฒนาการตามธรรมชาติของซอฟต์แวร์และมนุษย์ ถ้าเงื่อนไขทุกอย่างยังคงเดิม หน้าที่ของเราคือการรักษาความสะอาดและทำระบบให้มีประสิทธิภาพ (Rewrite) แต่ถ้าโลกเปลี่ยนไปจนกรอบเดิมกลายเป็นกรงขัง หน้าที่ของเราคือการก้าวขึ้นมาเป็น Rule Maker สร้างกฎข้อใหม่ ทุบสิ่งเก่าเพื่อสลับร่างสู่สิ่งที่ดีกว่าอย่างเด็ดขาด (Rework)
แล้วในโปรเจกต์หรือระบบที่คุณกำลังดูแลอยู่ตอนนี้… คุณกำลังพยายามขัดเช็ดถูเสาเข็มที่หัก หรือพร้อมที่จะลุกขึ้นมาวางฐานรากใหม่แล้วหรือยัง?
หากคุณชอบบทความแนวการเชื่อมโยงปรัชญาเข้ากับการทำงานในโลกยุคใหม่ ฝากกดเลิฟ กดแชร์ และกดติดตามช่องของผมด้วยนะครับ!
