จากหนังสือ Programming Beyond Practices (Be more than just a code monkey)
ได้แนะนำขั้นตอนการ review code ที่น่าสนใจดังนั้น
ลองคิดดูสิว่า ถ้าเราเป็นลูกค้า หรือ ผู้ว่าจ้าง
โดยที่รู้ด้วยว่าการเปลี่ยนแปลง code ต่าง ๆ จะเกิดผลกระทบ หรือ มีความเสี่ยงอะไรบ้าง ?
เราน่าจะลดขั้นตอนการ review ต่าง ๆ ลงไป
แล้วมาพยายามส่งมอบระบบงานให้ได้บ่อย ๆ ดีกว่าไหม ?
เป้าหมายคือลดขั้นตอนการ review code ลง
ทั้งวิธีการเขียน code
ทั้งโครงสร้างของ code
ทั้งชุดการทดสอบ
ทั้งเรื่องของเอกสารต่าง ๆ
สุดท้ายคือ ไม่มีสิ่งต่าง ๆ เหล่านี้เลย !!
คำถามคือเริ่มอย่างไรดีล่ะ ?
เริ่มต้นด้วย Production Testing
มันคือสิ่งที่สำคัญมาก ๆ และเป็นสิ่งแรกเลย
นั่นคือการสร้าง code ที่สามารถทำงานบน
production environment หรือคล้าย ให้ได้เร็วที่สุด
เพราะว่าสิ่งที่ต้องการคือ feedback ที่เหมือนจริง
ไม่ใช่พัฒนาด้วยระบบหนึ่ง
แต่พอตอนส่งมอบก็ออกระบบหนึ่ง !!
มันจะทำให้เราเห็นว่า
สิ่งที่คิด
สิ่งที่ออกแบบ
สิ่งที่สร้าง
มันสามารถทำงานบน environment จริง ๆ ได้หรือไม่ ?
หรือว่ามันเหมาะสมหรือไม่ ?
ผลที่ได้รับคือ เรากล้าที่จะเปลี่ยนแปลงและแก้ไข feature ต่าง ๆ อีกด้วย
รวมทั้งรู้ความเสี่ยงต่าง ๆ อีกด้วย
เช่นจากการ deploy ระบบเป็นต้น
สิ่งที่ต้องเน้นคือ Product มากกว่าการ review code
ดังนั้นสิ่งที่ต้องพูดคุยกันก่อนจะมาดู issue ต่าง ๆ ของ code คือ
คุณภาพของ product และความสามารถต่าง ๆ เช่น
- การเปลี่ยนแปลงนี้มันแก้ไขปัญหาของลูกค้าจริง ๆ ใช่ไหม ?
- วิธีการนี้มันเสถียรและครอบคลุมแล้วใช่ไหม ?
- ปัญหาที่จะตามมาจากการแก้ไขคืออะไรบ้าง ?
- ต้องทำการ migrate ระบบกันอย่างไรบ้าง ?
- สามารถ rollback การเปลี่ยนแปลงกัลบได้ง่ายไหม ถ้าเกิดข้อผิดพลาดขึ้นมา ?
- ค่าใช้จ่ายที่ตามมาในการดูแลเป็นอย่างไร ?
คำถามเหล่านี้
มันจะช่วยให้เรารู้ปัญหาต่าง ๆ ก่อน
ที่จะมาทำการ review code จริง ๆ
ทั้ง code ดีหรือไม่ ?
ทั้งโครงสร้างดีหรือไม่ ?
ทั้งต้อง refactor code ไหม ?
ทั้งการเขียน automated testing ?
มันเป็นการวิเคราะห์ปัญหาแบบ outside-in
นั่นคือการมองภาพของ product
จากมุมมองของลูกค้าและผู้ใช้งาน
ดังนั้นเริ่มต้นด้วยความต้องการของลูกค้า
ทำให้ลูกค้ามีความสุขกับ product
แน่นอนว่าทีมพัฒนาต้องมีความสุขด้วย
จากนั้นจึงลงไปในระดับ code ต่อไป
