ทำงานกับ Legacy code  มันสนุกไหม ?

จากหนังสือ Lean from the Trenches บทที่ 18 เรื่อง Reducing the Test Automation Backlog ทำการอธิบายเกี่ยวกับ การทำงานร่วมกับ Legacy code ได้อย่างน่าสนใจ ซึ่งคิดว่า น่าจะมีประโยชน์สำหรับใครก็ตามที่เผชิญกับมันอยู่ ว่าจะคิด และ ลงมือจัดการอย่างไรดี ?

หลาย ๆ บริษัท และ ทีม ที่ยังคงทำงานกับ Legacy code เป็นหลักนั้น

มักจะประสบปัญหาอย่างแรง เมื่อต้องการปรับเปลี่ยน แก้ไข ทั้งระบบงาน และ ขั้นตอนการทำงาน ปัญหามันเกิดมาจาก "Lack of test automation" หรือขาดชุดการทดสอบแบบอัตโนมัติ !! ผลที่ตามมาประกอบไปด้วย การแก้ไข code เป็นไปได้ยากมาก ๆ เพราะว่า แก้ที่หนึ่งอาจจะไปกระทบส่วนอื่น ๆ โดยที่เราไม่รู้เลย เมื่อทำการ deploy และ release ขึ้น production server แล้ว คนที่เจอ defect คือ ผู้ใช้ หรือ ลูกค้า สิ่งเหล่านี้มันสร้างความไม่พอใจให้กับลูกค้า สิ่งเหล่านี้มันสร้างความวิตกกังวลให้กับทีมพัฒนา และ ฝั่ง business เสียทั้งเวลา และ ค่าใช้จ่าย สำหรับการแก้ไขความผิดพลาดบน production server (Hotfix) บ่อยครั้งพบว่า เมื่อแก้ไขปัญหาหนึ่ง ๆ จะมีอีกหลาย ๆ ปัญหาตามมาอีกเพียบ แม้แต่ปัญหาที่เคยแก้ไขไปแล้ว ยังกลับมา

สิ่งเหล่านี้มันทำให้ทีมพัฒนา กลัวการแก้ไข Legacy code

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

คำถาม คือ เราไม่คิดจะทำอะไรให้ Legacy code มันดีขึ้นบ้างหรือไง ?

ประเด็นหลัก คือ แล้วมันมีทางเลือกอะไรบ้างล่ะ ?

1. ไม่ต้องไปสนใจมัน และหวังว่าเดี๋ยวก็เลิกใช้กันไปเอง
2. สร้างใหม่กันดีกว่า พร้อมกับใช้ Test-Driven Development (TDD) เพื่อทำให้มั่นใจว่าการทดสอบมันครอบคลุมระบบทั้งหมด
3. สร้าง project สำหรับ test automation แยกออกมา สร้างทีมใหม่ขึ้นมา เพื่อดูแลโดยเฉพาะ เพื่อปรับปรุง test coverage ให้ดีขึ้น และ เพียงพอต่อการใช้งาน
4. ให้ทีมทำการปรับปรุง code และ test coverage ให้ดี ให้เยอะขึ้นเรื่อย ๆ เป็นรอบการทำงานไป (Iteration)

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

1. เขียน test case ทั้งหมดออกมา
2. แบ่งกลุ่มของ test case ตามความเสี่ยง ตามค่าใช้จ่ายในการทำ manual test และค่าใช้จ่ายในการทำ test automation
3. จัดเรียงลำดับตามความสำคัญของ test case​ ซะ
4. เริ่มเขียน test case ที่ทำงานแบบอัตโนมัติแบบ iteration ไป จากความสำคัญมากไปน้อย ซึ่งให้แบ่งการทำงานเป็นงานหลัก 80% และ test automation อีก 20% ส่วนงานใหม่ ๆ ก็ให้มี test automation ซะ

ส่วน 3 แนวทางแรกนั้น น่าจะเป็นแนวทางที่หลาย ๆ คนชอบทำ !!

เพราะว่า มันง่ายสำหรับเรา แต่เต็มไปด้วยความเสี่ยงต่าง ๆ มากมาย เช่น ใครล่ะที่จะเขียน และ ดูแล test automation​ ? จะแยกเป็นอีกทีมหรืออย่างไร ? ถ้าแยกทีมมาเพื่อดูแลโดยเฉพาะ หมายความว่า ทีมพัฒนาไม่ต้องสนใจ test automation นะสิ ? ซึ่งนั่นคือ ปัญหาใหญ่ระดับโลกเลยนะ !! หรือจะให้ทั้งทีมพัฒนา มาเขียน test automation กันอย่างเดียวเลย มันก็จะกระทบกับทาง business อีก เนื่องจากจะไม่มีการพัฒนา feature ใหม่ ๆ หรือแก้ไขปัญหาต่าง ๆ เลย จนกว่าจะเขียน test automation เสร็จ !!

คำถามที่ตามมาก็คือ แล้วเมื่อไรที่จะเขียน test automation เสร็จล่ะ ? อะไรคือตัวชี้วัดว่าเสร็จนะ ?

แต่ว่ามันขึ้นอยู่กับระบบงานด้วยเช่นกัน ว่าจะเลือกแนวทางไหน !!

ยกตัวอย่างเช่น ถ้า Legacy code เป็นระบบที่ทำงานอยู่บน framework และ platform ที่เก่ามาก ๆ ไม่มีใครที่รู้เรื่อง หรือ มีประสบการณ์เลย เช่น Visual Basic 6, Visual FoxPro ปัญหาที่พบเจอคือ ขาดคน ที่จะทำ !! ดังนั้น แนวทางที่เหมาะสมน่าจะเป็น แนวทางที่สอง คือ การเขียนใหม่ กับ TDD

Legacy code มันคือปัญหาที่แท้จริง

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

คำถาม แล้วคุณล่ะ เลือกทางไหนกัน เพื่อจัดการกับ Legacy Code ?