จากหนังสือ 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 มันดีขึ้นบ้างหรือไง ?
ประเด็นหลัก คือ แล้วมันมีทางเลือกอะไรบ้างล่ะ ?
- ไม่ต้องไปสนใจมัน และหวังว่าเดี๋ยวก็เลิกใช้กันไปเอง
- สร้างใหม่กันดีกว่า พร้อมกับใช้ Test-Driven Development (TDD) เพื่อทำให้มั่นใจว่าการทดสอบมันครอบคลุมระบบทั้งหมด
- สร้าง project สำหรับ test automation แยกออกมา สร้างทีมใหม่ขึ้นมา เพื่อดูแลโดยเฉพาะ เพื่อปรับปรุง test coverage ให้ดีขึ้น และ เพียงพอต่อการใช้งาน
- ให้ทีมทำการปรับปรุง code และ test coverage ให้ดี ให้เยอะขึ้นเรื่อย ๆ เป็นรอบการทำงานไป (Iteration)
คำถาม คือ เราจะเลือกทางไหนดีล่ะ ?
ทางที่ดีที่สุดใน 4 เส้นทางนี้ ตอบได้ยากนะ
แต่ทางที่ 4 น่าจะเหมาะสมที่สุด
ในหนังสือได้อธิบายรายละเอียดของแนวทางที่ 4 ไว้ดังนี้
- เขียน test case ทั้งหมดออกมา
- แบ่งกลุ่มของ test case ตามความเสี่ยง ตามค่าใช้จ่ายในการทำ manual test และค่าใช้จ่ายในการทำ test automation
- จัดเรียงลำดับตามความสำคัญของ test case ซะ
- เริ่มเขียน 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 ?
