ทำความเข้าใจกับ Legacy code ด้วยการเขียน Test สิ

พอดีมีโอกาสแลกเปลี่ยนแนวทางในการจัดการ Legacy code จึงทำการสรุปสิ่งที่พูดไปไว้นิดหน่อย

Legacy code คือ code ที่ไม่มี Test ซึ่ง Test คือชุดการทดสอบแบบอัตโนมัตินะ

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

เมื่อเอกสารเชื่อถือไม่ได้ ดังนั้นก็ต้องเชื่อ code นะสิ

ดังนั้นอ่านและทำความเข้าใจ code กันดีกว่า การทำความเข้าใจ code ของ programmer ก็ไม่ยาก เริ่มต้นด้วยการ debug หรือเรียกว่า Debug programming !! โดยการ debug มันมีหลายรูปแบบแตกต่างกันไป เช่น

• ใช้ debug tool ผ่าน IDE
• ใช้การ print ค่าต่าง ๆ ออกมาทาง console
• ใช้การดูผลจากข้อมูลใน database
• ใช้การส่ง mail
• และอื่น ๆ อีกมากมาย

แน่นอนว่า มันไม่สนุกเลย !!

ดังนั้นขอแนะนำวิธีการที่ดีกว่า คือ การเขียน Unit test

แทนที่จะทำการ debug เพื่อดูการทำงานของ code อย่างเดียว ก็มีเขียน Unit test เพื่อตอบคำถามต่าง ๆ ที่เราต้องการดีกว่า น่าจะทำให้ชีวิตดีขึ้นกว่าเดิม ทำไมต้องเริ่มต้นด้วย Unit test ล่ะ ? Programmer ส่วนใหญ่จะคิดว่า Legacy code มันต้องมีจำนวนบรรทัดเยอะแน่ ๆ เป็นพัน เป็นหมื่น เป็นแสน มาบอกให้เขียน Unit test แล้วจะเริ่มกันตรงไหน ? จะทดสอบตรงไหน ? จะทดสอบอะไร ? มันเป็นไปไม่ได้หรอกนะ ยังไม่พอ code เหล่านี้มันไม่พร้อมต่อการเขียน Unit test ด้วยซ้ำ ลองคิดใหม่ ไม่มี code อะไรหรอกที่ทดสอบไม่ได้ (ยกเว้น code หาย !!) มันต้องมีการทดสอบสัก level ล่ะที่สามารถทดสอบได้ ทั้ง unit, component, integrate, system เป็นต้น ดังนั้นเราสามารถเขียน test เพื่อครอบคลุมการทำงานส่วนต่าง ๆ

แต่ก่อนที่จะเขียน Test ต้องเรียนรู้สิ่งเหล่านี้ก่อน

• Input ที่ต้องใช้งานเป็นอย่างไร ?
• Output ที่สร้างหรือส่งออกมาเป็นอย่างไร ?
• ข้อมูลต่าง ๆ ที่ทำให้การทำงานสำเร็จคืออะไร ?
• ข้อมูลต่าง ๆ ที่ทำให้การทำงานผิดพลาดคืออะไร ?
• มี dependency อะไรบ้าง เช่น function/method, database, service และ system เป็นต้น
• มันจะเกิดผลกระทบต่ออะไรบ้าง ?
• และอื่น ๆ ที่คุณต้องเรียนรู้จากระบบที่ดูแล

มันคือการทำความเข้าใจการทำงานของระบบในส่วนนั้น ๆ นั่นเอง รู้นะว่ายาก แต่การ debug อยู่ตลอดเวลา มันไม่น่าจะเป็นเส้นทางที่ดีนะ อย่าผิดซ้ำที่เดิม !!

เมื่อเราเริ่มเขียนชุดการทดสอบแรก เราจะได้

• ทำให้ programmer กล้าแก้ไข Legacy code มากขึ้น
• ลดปัญหาจากการแก้ส่วนหนึ่ง แล้วกระทบอีกส่วนหนึ่ง
• ลดปัญหาจากการแก้ bug แล้วเกิด bug อีกหลายตัว
• ชุดของ Regression test ที่อาจจะทำงานแบบอัตโนมัติได้อีกด้วย
• ทำให้การทดสอบง่าย และ เร็วขึ้น

แน่นอนว่า ในช่วงเริ่มต้นมันอาจจะเจ็บ และ ยาก บ่อยครั้งทำให้ programmer ส่วนใหญ่เลิกล้มความตั้งใจไป แต่ผมคิดว่า มันมีประโยชน์ตามมาที่คุ้มค่ากว่านะ

วันนี้ programmer เขียน test แล้วหรือยัง ? ถ้ายังก็เขียนสิครับ รออะไรกันอยู่