Screen Shot 2558-05-12 at 10.06.14 AM
บ่อยครั้งมากที่ developer มักจะต้องทำงาน
อยู่บน code ที่ไม่มี test
อยู่บน code ที่มี test นะ แต่คุณภาพไม่ดี
อีกทั้ง test coverage ก็มีค่าที่ต่ำอีก

แน่นอนว่า มันก่อให้เกิดปัญหาตามาอย่างมากมาย
ลองมาดูหน่อยสิว่า แต่ละปัญหามันเป็นอย่างไร ?

คำถาม
คุณกลัว code ที่มีคุณสมบัติตามข้างบนไหม ?

ปัญหาแรก ค่าของ test coverage ต่ำมาก

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

ปัญหานี้มันคือเรื่องของการ regression test เลยนะ
คุณจำเป็นต้องหาวิธีการแก้ไขปัญหานี้ด้วยนะ !!

ปัญหาที่สอง มันคือผลกระทบจากปัญหาแรก คือ เรื่องการออกแบบ

ถ้า code ที่คุณออกแบบมานั้น มันทำการทดสอบ หรือเขียน test ยาก
แสดงว่า การออกแบบของคุณมีปัญหาแล้วล่ะนะ

ดังนั้นส่วนใหญ่มักจะแก้ไขด้วยการพัฒนาแบบ TDD หรือ Test-first
โดยทำการพัฒนาระบบจากการเขียน test ก่อน
ซึ่งเป็นแนวคิดการพัฒนาแบบ Outside-in
นั่นคือ สนใจพฤติกรรมการทำงานที่เราจะทดสอบ
ก่อนการ implement หรือพัฒนา code และ ส่งมอบต่อไป

ลองคิดดูสิว่า
ถ้าคุณยังไม่รู้จะทดสอบอะไรเลย
แล้วคุณจะเริ่มเขียน code ได้อย่างไร ?

จากทั้งสองปัญหา คือ ค่าของ test coverage ต่ำ และ การออกแบบก็แย่
ส่งผลให้เกิดปัญหา กลัวการ refactor code หรือ การปรับปรุง code ให้ดีขึ้น
จึงทำให้เกิดคำพูดที่ว่า

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

ส่งผลให้ ไม่มีใครกล้าทำการแก้ไข หรือ ปรับปรุง code ให้ดีขึ้น
สุดท้าย เราจึงได้ code ที่มันซับซ้อน ยุ่งเหยิง ผูกติดกันไปหมด

ซึ่ง developer ส่วนใหญ่น่าจะติดอยู่ใน
กงเกวียนกำเกวียนในโลกของการพัฒนา software
แสดงดังรูป

slop_feedback_loop

ผลที่ออกมาน่าจะได้ระบบดังรูปนะครับ ฮาๆ กันไป
แต่ความจริงมันแสนจะเจ็บปวดรวดร้าว ทรมานสิ้นดี !!

Screen Shot 2558-05-12 at 9.26.40 AM

ระบบแบบนี้เรามักจะเรียกว่า Legacy system
หรือบางคนจะเรียกว่า Big ball of mud

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

แน่นอนว่ามันไม่ใช่เรื่องง่ายๆ เลยก็ใช่ว่าจะทำไม่ได้เลยนะ

เริ่มด้วยการขายของสิ ไปพูดคุยกับทางคนที่มีอำนาจตัดสินใจเสียก่อนทั้ง

  • เจ้าของ product
  • Business
  • Analyst
  • Stakeholder ที่เกี่ยวข้อง

เพื่ออธิบายให้ชัดเจนถึงปัญหา ผลกระทบ และ วิธีการแก้ไข ที่จะเดินต่อไป
เป็นเรื่องแปลกมากว่า

พวกระบบที่ developer ไม่ชอบ หรือ บ่นๆ กันอยู่นั้น
มันกลับเป็นระบบที่มีความสำคัญมากๆ …

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

จากนั้นเริ่มต้นเขียน Acceptance test ขึ้นมาในแต่ละขั้นตอนการทำงาน
ใช้เครื่องมืออะไรก็ได้ที่ถนัดนะ เช่น

  • Robot framework
  • Selenium
  • Cucumber/Capybara
  • RSpec

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

สำหรับ code ชุดใหม่ๆ ก็ให้เริ่มต้นการพัฒนาด้วย การเขียน test ก่อนซะ
เพื่อเพิ่มความมั่นใจให้กับเรา
ว่า feature ใหม่ๆ ที่เราสร้างขึ้นมามันทำงานได้ตามที่เราคาดหวังนะ
จะได้ไม่เป็นภาระให้คนรุ่นหลัง…

และสุดท้าย
เมื่อคุณได้รับ bug มาให้แก้ไข
แนะนำให้ทำการเขียน test เพื่อทำให้เห็นว่ามันเกิด bug จริงๆ
จากนั้นจึงทำการแก้ไข code เพื่อให้ test ผ่าน
ทำให้ Legacy code เริ่มมีชุดการทดสอบขึ้นมา
และค่าของ test coverage ก็สูงขึ้น
แน่นอนว่าจะเริ่มทำการแก้ไข code ให้ดีขึ้น หรือ ทดสอบได้ง่ายขึ้น
วิธีการนี้เรียกว่า Bug-Driven Development

คำถาม
แล้วคุณล่ะ สร้าง code ที่น่ากลัวขึ้นมาบ้างหรือไม่ ?