เรื่องที่ 18 ที่นักพัฒนาควรรู้ และ เข้าใจก็คือ Don’t Ignore that Error!
เราพบว่านักพัฒนาส่วนใหญ่
- ชอบเขียน code แบบให้เสร็จๆ ไปที
- ชอบเขียน code ที่มักก่อให้เกิดหายนะใหญ่หลวงตามมา
- ชอบเขียน code …
มันแปลกไหมนะ ?
คำพูดที่มักได้ยินอยู่เป็นประจำจากนักพัฒนา software
นาย กอ :: บอกว่า มี Error เกิดขึ้นในระบบงาน
นาย ขอ :: ถามกลับไปว่า เกิด Error อะไรล่ะ ?
นาย กอ :: บอกว่า มี Error …
นาย ขอ :: บอกนาย กอ ไปว่า ไม่ต้องกังวลไปนะ เราสามารถยกเลิก หรือ ไม่สนใจมันได้
คำถาม
คุณคิดว่าวิธีการของนาย ขอ นั่นมันดีแล้วหรือยัง ?
คำตอบ
คุณก็รู้ว่า มันไม่ใช่วิธีการที่ดีเลย
แต่มันเป็นวิธีการที่สามารถมองข้ามปัญหาไปได้เลย แต่ปัญหาก็ยังคงอยู่ !!
แน่นอนว่า มันคือการแก้ไขปัญหาของคนขี้เกียจ
หรือบางคนอาจจะมีคำแก้ตัวสวยๆ ว่า ไม่มีมีเวลานะ งานล้นมือ !!
ถ้าคุณยังแก้ไขปัญหา ด้วยการซ่อน หรือ ปิดบังปัญหาไว้แบบนี้
แล้วมันจะกลับกลาย หรือ แปลงร่าว มาเป็นปัญหาที่สำคัญในอนาคตได้
ไม่ว่าจะต่อคุณ หรือ คนอื่นๆ ก็ตาม
ดังนั้น สิ่งที่เราควรกระทำใน code ก็คือ
- ทำการตรวจสอบ error
- ทำการจัดการ error ในทางที่เหมาะสม
ปกติใน code เราทำการตรวจสอบ และ รายงาน error กันอย่างไรบ้าง
ตัวอย่างเช่น
1. การ Return code
ในแต่ละ method/function การทำงาน จะส่ง code หรือหมายเลขของผลการทำงานออกมาว่าเป็นอย่างไร
เช่น
- 200 หมายถึง ทำงานสำเร็จ
- 404 หมายถึง หาข้อมูลไม่พบ
- 501 หมายถึง ระบบทำงานผิดพลาด
รูปแบบการ Return code นั้น ผู้ที่ทำการเรียกใช้งาน
จะทำการตรวจสอบผล แล้วจึงทำงานตามผลนั้นๆ
แต่ว่า นักพัฒนาอย่างเราๆ ท่านๆ ตรวจสอบผล นอกจากว่ามันสำเร็จหรือไม่ ?
การตรวจสอบแบบนี้ มันง่ายมากที่นักพัฒนาจะละเลย
2. การใช้ตัวแปร Global ในการจัดเก็บ error
เป็นรูปแบบการจัดการที่ง่าย สำหรับคนขี้เกียจ
แต่มันยากสำหรับการดูแลรักษาระบบมากๆ
และมันนำมาซึ่งปัญหามากมายต่อไป
รวมทั้งมันง่ายต่อการยกเลิก หรือ ไม่สนใจมันอีกเลย
เพียงแค่ไม่ต้องเก็บผลการทำงานเท่านั้นเอง
น่ากลัวมากมาย !!
3. การโยน Exception ออกมา
เป็นรูปแบบที่ได้รับความนิยมพอๆ กับแบบที่ 1 คือ การใช้ try-catch มาครอบการทำงาน
เมื่อเกิด error ขึ้นมา ก็ไม่ต้องสนใจมันอีกเลย
เช่น
try {
// ...do something...
} catch (...) {} // ignore errors
แต่มันเป็นรูปแบบการจัดการ error ที่เลวร้ายมากๆ
เนื่องจากคุณพยายามซ่อน หรือ ปกปิดการทำงานผิดพลาดของระบบไว้
โดยทำเป็นมองไม่เห็นมัน ทั้งๆ ที่ปัญหามันก็ยังเกิดอยู่
และเชื่อไหมว่า ถ้าคนอื่นๆ มาเห็นการจัดการ error แบบนี้
ก็จะไม่ไปยุ่งกับ code ส่วนนั้น เพราะว่า มันทำงานได้นะ อย่าไปยุ่งเลย
หรือซ้ำร้ายกว่านั้น ก็ทำตามวิธีการนั้นไปเลย
สุดท้าย มันยิ่งก่อให้เกิดปัญหา ที่ร้ายแรงตามมาด้วยกันทั้งหมดทั้งสิ้น ..
เรียกปัญหารูปแบบนี้ว่า Broken Windows
ดังนั้น
เมื่อพบเห็นปัญหาเหล่านี้ ให้รีบแก้ไขมันซะ
ก่อนที่คุณจะเดินหรือก้าวต่อไป
การจัดการ error ที่ไม่ดี หรือ ไม่ทำ หรือ พยายามซ่อนปัญหาไว้ ส่งผลให้เกิด
- Brittle code คือ code ที่คุณเข้าไปมีส่วนร่วมแล้วรู้สึกตื่นเต้น น่ากลัว และ ค้นหาจุดผิดพลาดยากมากๆ
- Insecure code คือ code ที่เปราะบางเหลือเกิน ง่ายต่อการโจมตี รวมทั้งสามารถทำให้ระบบหยุดทำงานได้ง่ายมาก
- Poor structure คือ code ที่มีรูปแบบ หรือ โครงสร้างที่แย่ เช่น มี interface/abstract class ที่แปลกๆ หรือ แย่ๆ ทั้งชื่อ และ จำนวน method ที่ไม่สัมพันธ์กับชื่อของมัน
ดังนั้น เราไม่ควรดักจับ หรือ ตรวจสอบ Error ใช่ไหม ?
เช่น
- การดักจับ error มันทำให้ code นั้นอ่านยากมากขึ้น รวมทั้งยากต่อการหาขั้นตอนการทำงานปกติอีกต่างหาก
- การดักจับ error มันทำให้เรามีงานที่ต้องทำเยอะขึ้น แต่ deadline ยังคงเช่นเดิม
- ฉันรู้ว่าเมื่อเรียกใช้งาน method/function นี้แล้ว มันไม่เคย error อะไรออกมาเลย เพราะว่า ทำการแสดงผลการทำงานออกมาตลอด (แต่ถ้ามันเกิด error ขึ้นมานะ มันจะเป็นปัญหาใหญ่มากๆ)
- มันเป็นเพียงส่วนเล็กๆ เท่านั้น ไม่จำเป็นต้องเขียนหรอกนะ !!
แล้วคุณล่ะ คิดว่าเหตุผลเหล่านี้มันฟังขึ้นไหม ?
อาจจะฟังขึ้นมาบ้างสำหรับบางข้อ แต่ส่วนใหญ่ไม่น่าจะฟังขึ้นนะ
ทางที่ดีคุณควรจะ
ทำการตรวจสอบ error ต่างๆ ที่เป็นไปได้ทั้งหมดใน code หรือระบบของคุณซะ
ควรที่จะโยนแต่ละ error ออกมา อย่าพยายามซ่อนมันไว้
เพื่อให้ service หรือ ระบบของคุณทำงานได้อยู่ตลอดเวลาเป็นเด็ดขาด
วันนี้คุณทำการดักจับ Error และจัดการมันอย่างไรกันล่ะ ?
