Screen Shot 2558-06-23 at 4.47.25 PM
เคยบ้างไหมที่ต้องอยู่กับ code ที่ 50-70% มันคือ การเขียน log
ส่วนที่เหลือคือ code ที่เราต้องการจริงๆ
เคยถามไหม หรือ คิดไหมว่า ทำไมถึงเป็นแบบนั้นนะ ?
ตัวอย่าง code

คุณคิดไหมว่า code เหล่านี้มันดี หรือ ไม่ดี อย่างไร ?
หรือว่า เราก็เขียนตามรูปแบบเดิมๆ กันต่อไป …

Code แบบนี้ทำให้เกิดปัญหาอะไรบ้างนะ ?

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

แต่สิ่งที่ได้กลับมาก็คือ

  • มี code ที่ไม่เกี่ยวข้องกับการทำงานเพียบเลย ซึ่งนั่นคือสิ่งรบกวน
  • แน่นอนว่าทำให้ความซับซ้อนของ code เพิ่มขึ้น

จากตัวอย่าง มีเพียงบรรทัดเดียวเท่านั้น ที่จำเป็น มันหมายความว่าอย่างไร ?

โดย code ลักษณะนี้จะเจอมากๆ ในสิ่งเล็กๆ ที่เรียกว่า Legacy code
จะพบเจอทั้ง code ที่ไม่ถูกใช้งาน
จะพบเจอทั้ง code ที่ใช้งานแบบผิดๆ
จะพบเจอทั้ง code ที่ over design ใช้ pattern ร้อยแปดพันเก้า
จะพบเจอทั้ง comment ที่มีมาก และ เชื่อถือไม่ได้

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

มาลองเดาเหตุผลของการเขียน code แบบนี้กันหน่อยสิ ?

  • อย่างแรกมันน่าจะเอาไว้ช่วยเหลือเรานะสิ เพื่อให้รู้ว่าระบบมันทำงานอย่างไร ถูกไหม อ่านจาก log เอาสิ
  • น่าจะไม่เขียน unit test อะไรไว้มาก ดังนั้นเพื่อความมั่นใจต้องเขียน log ไว้กันเหนียว
  • เราไม่สามารถควบคุมอะไรได้มาก หรือ มักจะเกิดเหตุการณ์แปลกๆ ขึ้นมาเสมอ ทำให้ต้องใช้ log เอาไว้ช่วยตรวจสอบ ซึ่งมาจากความซับซ้อนของระบบนั่นเอง
  • การที่ logging สามารถเปิดหรือปิดได้ มันช่วยทำให้สะดวกมากขึ้น ไม่ต้องมานั่งแก้ไข code บ่อยๆ
  • เพื่อเพิ่มความมั่นใจ ว่าการทำงานมันจะซ้ำๆ เดิมตลอด ซึ่งดูจาก log นั่นแหละ

แต่เรามักพบว่า มีการใช้ทุกมันซะทุกที่ !!!
ซึ่งไม่น่าจะเป็นแนวทางที่ดีเลยนะ ?

แล้วจะใช้ หรือ ไม่ใช้ อย่างไรดีล่ะ ?
พยายาม ลด ล่ะ เลิก หรือใช้ในส่วนที่จำเป็นเท่านั้น

ตัวอย่างการลดการใช้งาน log
ถ้าเราไม่มั่นใจใน code ก็ให้เขียน unit test ซะ
เพื่อเพิ่มความมั่นใจต่อ code !!

แต่ในความจริงแล้วนั้น การเขียน log มันมาจาก 2 เหตุผลหลัก คือ

1. เขียน log อย่างมีเป้าหมาย ไม่ใช่คิดอยากเขียนก็เขียน
บางครั้งเจ้าของ requirement ต้องการข้อมูลบางอย่าง
เพื่อนำไปใช้งาน นำไปวิเคราะห์

ตัวอย่างเช่น
Log เก็บพฤติกรรมของผู้ใช้งาน และ ประวัติการใช้งาน
เพื่อนำมาใช้ในการตรวจสอบเรื่องต่างๆ
หรือใช้ในการวิเคราะห์เรื่องประสิทธิภาพของระบบ

ซึ่งในกรณีนี้ ข้อมูลต่างๆ ที่จัดเก็บใน log
ควรเป็นส่วนหนึ่งของความต้องการลูกค้า
และทีมพัฒนาก็ควรเขียน unit test เพื่อตรวจสอบว่ามันทำงานได้อย่างถูกต้อง

2. เขียน log เพื่อช่วยเหลืองาน operation
ในส่วนนี้มันก็อยู่ที่ความต้องการแล้ว
แต่ถ้าคุณทำงานร่วมกับฝ่าย operation แล้ว
ดังนั้น ก็ควรจะคุยกันให้รู้เรื่อง ว่าจะเก็บข้อมูลอะไรบ้าง ?

บ่อยครั้งเราพบว่า ทีมพัฒนา และ ทีม operation ไม่ค่อยถูกกัน
สาเหตุมาจากอะไรบ้างนะ ?
ระบบมันมีปัญหาบ่อยหรือไม่ ?

การแก้ไขคือ เขียน log ให้ได้มากที่สุด
และคาดหวังว่า มันจะช่วยเหลือ
สุดท้ายมันช่วยอะไรบ้างไหม ?
หรือเพียงโยน log กันไปมา เมื่อระบบเกิดปัญหา !!

คำถามก็คือ
คุณจะดู log เหล่านี้บ่อยแค่ไหนกัน ?
ปกติจะดู log เมื่อเกิดปัญหาเท่านั้นหรือไม่ ?
แล้ว log มันช่วยเหลืออะไรคุณบ้างล่ะ ?

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

ท้ายที่สุดแล้วนั้น

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

ยิ่งเขียน log มากเท่าไร คุณยิ่งหาสิ่งที่คุณต้องการยาก หรือ หาได้น้อยลงไปเท่านั้น
เพราะว่าจะโดน code ของ log มันบดบังไปหมด

ถ้าคุณไม่แน่ใจใน code แนะนำว่าให้เขียน unit test ซะ
เพื่อเพิ่มความมั่นใจใน code

ให้เขียน log เท่าที่จำเป็น และ มีประโยชน์เท่านั้น
ตัวอย่างเช่น
เขียนเพราะว่า มันคือ requirement
เขียนเพราะว่า มันมีประโยชน์และช่วยเหลือ operation

ดังนั้น code ทุกตัวอักษรที่คุณเขียนนั้น มันต้องมีความหมาย และ มีคุณค่า เสมอนะครับ

คำถาม
เคยไหม ? ระบบมันล่มเพราะว่า disk เต็มจากการเขียน log …