เป็นเรื่องปกติของ 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/
