code-34
เรื่องที่ 8 ที่นักพัฒนาควรรู้ และ เข้าใจก็คือ Don’t Touch that Code!
หรือ อย่าไปเตะ code บนนั้นนะ !! เดี๋ยวเหอะ …

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

คำถาม
สิ่งที่ทางนักพัฒนาจะทำทันทีเมื่อได้ defect ก็คืออะไร ?
คำตอบ
ถามได้ ก็แก้ไขมันอย่างรวดเร็วไง ง่ายๆ สบายๆ เพราะว่าฉันรู้อยู่แล้วว่า code ตรงไหนมันผิด !! (Quick fix)
แต่ดันลืมไปว่า คุณมีสิทธิ์ในการเข้าถึงเครื่อง QA หรือ Staging server หรือไม่ ?
ปกติก็ไม่น่ามีสิทธิ์เนาะ !!

แต่ถ้าคุณมีสิทธิ์เข้าถึง คุณก็จะแก้ไขและ deploy บน เครื่อง QA หรือ Staging เลย
ทำแบบนี้มันดีไหมนะ ?

ปกติในการพัฒนาระบบ web application จะมี environment ดังต่อไปนี้

  • Local development คือเครื่องของนักพัฒนาแต่ละคน ต้องสามารถ run unit testing ได้
  • Development server คือเครื่องสำหรับการติดตั้งระบบที่พัฒนาของทีม สามารถทำการทดสอบแบบอัตโนมัติ ทั้ง unit testing และ integration test รวมทั้งการทดสอบแบบ manual
  • Staging/QA server คือเครื่องที่ทางทีมทดสอบ และ ผู้ใช้งาน ทำการทดสอบระบบ ก่อนที่จะยอมรับให้ทำการ deploy ไปยัง production server
  • Production server

แน่นอนว่า อาจจะมี environment อื่นๆ อีก ตามแต่ละที่กันไป

กฎเกณฑ์ปกติที่เขาทำกัน แต่เรามักไม่เคยทำกัน ก็คือ

ปกตินักพัฒนาจะไม่สามารถเข้าถึง development server ได้โดยตรง
นักพัฒนาทำการ coding ที่เครื่องของตัวเอง
เมื่อพัฒนา feature เรียบร้อย จะทำการ commit และ checkin code เข้ามายัง Version Control System(VCS)

ส่วนใหญ่จะมีระบบการ deploy code แบบอัตโนมัติบน development server
และทำการทดสอบระดับ unit test, integration test, acceptance test แบบอัตโนมัติ
เพื่อทำให้มั่นใจได้ว่า code ทั้งหมดมันสามารถทำงานร่วมกันได้นะ

เมื่อการทดสอบต่างๆ ผ่านไปอย่างเรียบร้อย
ก็ทำการ deploy ไปยัง Staging/QA server เพื่อให้ทางทีมทดสอบ
ทำการทดสอบระบบงาน หรือ ส่งให้ผู้ใช้งานทดสอบ
ก่อนที่จะทำการ deploy ไปยัง production server

ถ้ามีปัญหาอะไรก็ตามใน Staging/QA server
ก็จะเปิด ticket ของ defect/bug กลับมาให้นักพัฒนาแก้ไข
และเริ่มขั้นตอนการพัฒนาปกติอีกรอบ

แต่สิ่งที่มักพบเจอเป็นประจำก็คือ (มันคือสิ่งที่ผิดปกติ)

นักพัฒนาสามารถเข้าถึงทุกๆ environment ได้ทั้งหมด
ดังนั้น ถ้าเกิดปัญหาใดๆ นักพัฒนาจะทำการแก้ไขตรงนั้น และ deploy กันไปเลย
คุ้นๆ ไหม ?

ยิ่งถ้ามีปัญหาบน production server เมื่อไร
สิ่งที่นักพัฒนาจะทำก็คือ แก้ไข code บน production server ไปเลย
เมื่อทุกอย่างเรียบร้อยก็มักจะทำสิ่งที่เรียกว่า patch
กลับมายัง code based หรือลงใน Version Control System(VCS) อีกที
และบ่อยครั้งพบว่า code ที่ทำการแก้ไขมันไม่ถูกกลับมารวมยัง code-based เลย

บางครั้งทำให้เกิดปัญหา ว่า ทำไม defect/bug มันกลับมาอีกล่ะ ?

จากการกระทำแบบนี้ มันคือ หายนะ อันใหญ่หลวงของการพัฒนา software

ซึ่งมันคือการกระทำที่ขัดแย้งต่อแนวคิด Don’t Touch that Code!
นั่นก็คือ เมื่อเจอปัญหาใดๆ ก็ตาม
อย่าทำการแก้ไขบน production server หรือ staging server โดยเด็ดขาด
เพราะว่า มันไม่สมควรเลย ใช่ไหม ?

แปลกนะ!! นักพัฒนาชอบทำกัน