ต้องทำอย่างไรดีเมื่อต้องไปแก้ไข Legacy Code ?

เป็นเรื่องปกติของ Developer ทุกคนที่ต้องผจญภัยกับ Legacy Code แต่สำหรับ Developer หน้าใหม่ ๆ นั้น อาจจะมีความคิด และ ความคาดหวังว่า เมื่อเข้ามาทำงานแล้ว ต้องมาพัฒนา feature ใหม่ ต้องมีเขียน code ใหม่ โดยไม่สนใจใคร แต่ในโลกความเป็นจริงมันไม่เคยเป็นเช่นนั้นเลย เนื่องจากต้องเข้าไปแก้ไขสิ่งเล็ก ๆ ที่เรียกว่า Legacy Code บางคนเรียกว่า Death Star !! บางคนอาจจะบอกว่า ซวยล่ะ งานเข้าแน่นอน !! ดังนั้นเรามาดูกันหน่อยว่าจะรับมือกับมันอย่างไรบ้าง ?

อย่างแรก คือ เตรียมตัวและเตรียมใจไว้ก่อน

สิ่งแรกที่คุณต้องเจออย่างแน่นอนคือ Code ที่มันยุ่งเหยิง ทั้งในระดับ method ที่มีจำนวนบรรทัดเยอะ ๆ ทั้งในระดับ fiel/class ที่มีขนาดใหญ่มาก ๆ บางคงเรียกว่า God class Code ที่มี dependency ทั้งจากภายในและภายนอกมากมาย แน่นอนว่า น่าจะไม่มีชุดของการทดสอบ หรือ มีน้อยมาก ๆ

จึงเป็นที่มาของคำพูดจากปากหลาย ๆ คน คือ อย่าไปยุ่งกับมันเลย มันดีอยู่แล้ว อย่า ... แต่ ... รอเขียนใหม่ดีกว่า !! (ได้ Legacy code ชุดใหม่ขึ้นมาอีก)

แต่ Legacy Code เหล่านี้ กลับเป็นส่วนที่สร้างรายได้ให้กับทีมและบริษัท และนำเงินเหล่านั้นมาจ่ายเป็นเงินเดือน และ ค่าจ้างให้คุณ มีแต่คนไม่ชอบ Legacy Code เหล่านี้ !! มันขัดแย้งกันดีนะเออ !!

จากนั้นสิ่งที่ต้องทำคือ ทำตามแนวคิด The Boy Scout Rule

เป็นแนวคิดที่ Developer ทุกคนควรทำตามเสมอ นั่นคือ ถ้าพบว่า code มันซับซ้อน ถ้าพบว่า code มันแย่ ถ้าพบว่า code มันเข้าใจยาก ให้ทำการแก้ไขและปรับปรุงให้ดีขึ้นซะ แต่ ... ปัญหามันมักจะเกิดขึ้นจากคำถามเหล่านี้

• รู้ไหมว่า ถ้าแก้ไขส่วนนี้ไปแล้วมันจะกระทบส่วนไหนบ้าง ?
• รู้ไหมว่า การทำงานส่วนนี้มันสำคัญมาก ๆ ?
• รู้ไหมว่า มันเสี่ยงมาก ๆ ?
• รู้ไหมว่า ? มั่นใจไหมว่าจะไม่กระทบ ?

คำตอบที่มักได้รับกลับมาคือ ก็ไม่รู้เหมือนกัน .. น่าจะไม่ ... !! สุดท้ายจึงได้ข้อสรุปว่า อย่าไปยุ่งกับมันเลยนะ !! ทั้ง ๆ code มันแย่มาก แต่ทำงานได้นะ เช่น

• Loop​ ซ้อนกัน 5-10 ชั้น
• ใช้ Global variable เยอะมาก
• แต่ละ method มีขนาดใหญ่มาก ๆ
• และอื่น ๆ อีกมากมาย !!

คำถามคือ เราจะทำอย่างไรดีล่ะ ? ควรแก้ไข หรือ แตะต้องมันไหม ?

ตอบง่าย ๆ คือ ให้ทำการแก้ไขเมื่อ code เหล่านั้นมีข้อผิดพลาด (Bug) หรือต้องการแก้ไข หรือ เพิ่มเติมความสามารถใหม่ ๆ เข้าไป นอกจากนี้ก็อย่าไปยุ่งกับมัน ? !!!

ถ้ายังไม่เข้าใจ มึนงงอยู่ ก็อย่าไปยุ่งกับมันสิ

มิเช่นนั้น ถ้าทำการแก้ไขแล้ว ทั้งที่ไม่เข้าใจ อาจจะส่งผลเสียมากกว่า ผลดีนะ ทั้งต่อตัวคุณเอง และ ระบบงาน บางครั้งผลมันอยู่เหนือการคาดเดาใด ๆ ทั้งสิ้น ดังนั้นก่อนจะทำการแก้ไข Legacy Code ต้องถามตัวเองว่ามั่นใจหรือเปล่า ? มีวิธีการอื่นที่ไม่ต้องแก้ไข code หรือไม่ ? เช่นการเพิ่ม Wrapper, Proxy, Facade และ Adapter เข้าไป ? หรือ extend มันมาได้ไหม ? ซึ่งให้ระมัดระวังเป็นอย่างมาก รวมทั้งต้องมีความมั่นใจด้วย

จากนั้นลองพิจารณาสิว่า การเปลี่ยนแปลงเหล่านั้นมันมีความเสี่ยงสูงไหม ?

เนื่องจากการเปลี่ยนแปลง Legacy Code ล้วนมีความเสี่ยงด้วยกันทั้งนั้น แต่จะเสี่ยงมากหรือน้อยเท่านั้นเอง ดังนั้นก่อนทำการแก้ไข ต้องตรวจสอบ และ ทำความเข้าใจก่อนว่า code เหล่านั้นมันส่งผลกระทบมากหรือน้อย ลองคิดกันเองนะว่า คุณจะแก้ส่วนไหน ระหว่างส่วนที่มีความเสี่ยงมาก และ น้อย ? อย่าลืม The Boy Scout Rule นะครับ ก่อนทำการแก้ไข ให้เรียนรู้พฤติกรรมการทำงานของ code ซะ เป็นเรื่องที่หลาย ๆ คนไม่อยากเรียนรู้ และเข้าใจ เพราะว่า มันซับซ้อน มันยาก (อะไรที่ไม่เขียนเองมันยากทั้งหมด) สุดท้ายก็ไม่ทำการแก้ไข !!

ดังนั้นให้เริ่มเรียนรู้ และ ทำความเข้าใจการทำงานของ code ว่าเป็นอย่างไร เพื่อลดความเสี่ยง ความอันตรายจากการเปลี่ยนแปลง

หนึ่งในวิธีการทำความเข้าใจคือ การเขียน unit test นั่นเอง ซึ่งอธิบายทั้งการทำงาน และ พฤติกรรมการทำงานจริง ๆ ของ code รวมทั้งการเขียนเอกสารเพิ่มอธิบาย code ก็เป็นอีกหนึ่งทางเลือก

โดยสรุปแล้ว

ก่อนที่จะทำการแก้ไข Legacy Code นั้น คุณต้องเข้าใจมันก่อนว่า ทำงานอย่างไร ? คุณต้องเข้าใจด้วยว่า ทำไมต้องแก้ไข ? คุณต้องเข้าใจด้วยว่า ผลจากการแก้ไขเป็นอย่างไร ? และอย่าลืมว่า ต้องทำการเปลี่ยนแปลง ปรับปรุงให้ดีขึ้นอยู่อย่างเสมอ แล้วคุณจะอยู่กับ Legacy Code ได้ดีขึ้น

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

Reference Website https://jvaneyck.wordpress.com/2015/07/27/legacy-code-retreat/ http://www.daedtech.com/know-touch-legacy-code/