GC กับ Refactor

GC = Garbage Collector เป็นพฤติกรรมของภาษาสมัยใหม่ที่อำนวยความสะดวกให้กับผู้พัฒนาที่ไม่ต้องมาจัดการ หน่วยความจำแบบ Manual โดยระบบจะไปตรวจสอบการใช้งาน Memory ของโปรแกรม ถ้าเจอก็จะทำความสะอาดและปล่อย memory ให้คนอื่นกลับเอามาใช้ได้

Refactor ประกอบด้วย คำว่า Factor ที่แปลว่าปัจจัย หรือองค์ประกอบ บวกกับ Prefix Re~ ซึ่งในที่นี้หมายถึงทำซ้ำ ทำอีกครั้ง ถ้าใครยังงงอยู่ ขอให้ไปนึงถึงการแยกองค์ประกอบทางคณิตศาสตร์ก็ได้ เช่น

20 = 5x4
20 = 10x2 

ถ้าตอนแรกเราเคยเขียนด้วย 5x4 เราอาจจะมองว่า มันดูยาก เราเปลี่ยนเป็น 10x2 มันก็จะดูง่ายกว่า และผลลัพธ์ยังเหมือนเดิม

ย้ำว่า ผลลัพธ์ ต้องเหมือนเดิม

ใน Garbage Collector ยังประกอบด้วย Minor GC และ Major GC

โดยที่ minor GC จะเป็นการทำงานแบบง่ายและรวดเร็ว ใช้จัดเก็บ ของที่สังเกตเห็นได้ชัด

Minor GC CR: https://dzone.com/articles/interesting-garbage-collection-patterns

ขณะที่ Major GC หรือ Full GC มันจะเกิดขึ้นเมื่อเราทำ Minor GC แล้ว ค่า memory ที่ได้กลับมาน้อย จน Memory ที่ใช้พุ่งสูงไปคนชนเพดานบางอย่าง ทำให้ต้องมีการ ไล่ดูอย่างละเอียด ใน Memory ที่ใช้ทั้งหมด ซึ่งรวมถึง Memory ที่ถูก Reference / Pointer ต่างๆ เพื่อ เรียกคืนให้ได้

และเนื่องจากว่ามันต้องขุดเยอะมาก มันทำให้ต้องใช้ CPU ในการ Process และ ในบางภาษา ระบบต้องหยุดทำงานอยู่คราว (Pause / Stall) เพื่อให้การคืน Memory มีประสิทธิภาพ นั่นหมายถึง ระบบจะไม่สามารถทำงานได้ในขณะหนึ่ง ซึ่งอาจจะมีตั้งแต่ระดับ millisecond ไปจนถึง 1–2 วินาที

Major GC CR: https://dzone.com/articles/interesting-garbage-collection-patterns

ถึงตรงนี้ อาจจะรู้สึกว่าไม่ได้ส่งผลอะไร แต่ถ้าเป็นระบบที่รับ Transaction ระดับ 10000/วิ 2 วินาที ทำธุรกรรมไม่ได้ 20000 แล้ว สูญเสียมูลค่าไปเท่าไหร่

ดังนั้นการตรวจสอบคุณภาพของโค้ด เพื่อให้เกิด Major GC ให้น้อยที่สุด ในบางบริการ ก็มีความจำเป็น

กลับมาที่ Refactor

ส่วนตัวก็พบว่า Refactor ก็เหมือนจะมี 2 ระดับ ไม่ได้แตกต่าง จาก GC

คือ Minor Refactor เช่น การ ทำ sub code ให้เข้าใจง่ายขึ้น การปรับเปลี่ยน โครงสร้างอะไรเล็กน้อย การเปลี่ยนชื่อตัวแปร พวกนี้จะใช้เวลา ไม่นานมาก และทำได้บ่อยๆ

ส่วน Major Refactor คือการปรับเปลี่ยนระดับโครงสร้าง ที่ใหญ่ขึ้น ใช้เวลานาน

แน่นอนว่าหลายที่หลีกเลี่ยงการทำ Major Refactor เพราะ ส่งผลต่อธุรกิจแน่นอน

ข่าวร้าย การหลีกเลี่ยงวันนี้ เดือนร้อนวันหน้า เช่นกรณีของบริษัท msg ชื่อดัง ที่จำนวนผู้ใช้ก้าวกระโดดจาก 2 -> 20 -> 200 ล้าน คน แต่ Stack ไม่ได้รองรับ ตรงนี้ส่วนหนึ่งอาจจะด้วยการออกแบบตอนแรกด้วย

หรือในบริษัทเล็กๆ การเขียนโค้ดผิดที่ผิดทาง พอนานๆ เข้า โค้ดมันก็โตเป็น Tech Debt ขึ้นมา จนอยู่ในระดับที่ Maintain ได้ยาก

ซึ่งนำไปสู่ ท่าไม้ตายสุดท้าย คือ เขียนใหม่ ไปเลยหล่ะกัน

CR: Agile Samurai

ส่วนตัวมี Software Code base อยู่ 2 ชุดที่ยังอยู่ในการดูแลมา 10 กับ 14 ปี และยัง active อยู่จนถึงทุกวันนี้ มันอาจจะไม่ได้ยิ่งใหญ่อะไรมากมาย แต่ยังคงรักษาการ maintain ถ้ามีปัญหาได้อย่างรวดเร็วเพียงพอ

สิ่งที่แนะนำ จึงมีอยู่เพียงว่าทำ Minor Refactor บ่อยๆ เพราะมันไม่ได้เสีย Cost อะไรมากมาย แต่ความสม่ำเสมอ จะทำให้ Code ดีขึ้นทุกวัน และ maintain ได้สบายใจขึ้น ส่วน Major Refactor ก็ควรเกิดเพราะความเหมาะสม เช่น เปลี่ยน stack เพื่อให้ทันสมัยขึ้น อย่างไรก็ตาม ตรงนั้น Design ที่ดีก็จะช่วยลดภาระการเจ็บตัวไปได้ ซึ่งอาจจะไม่ได้พูดถึงในตอนนี้

แต่สำคัญที่สุด จะ Minor หรือ Major ยังไง ต้องมีผลลัพธ์สุดท้ายก่อน หรือ Test นั่นเอง