ว่าด้วยเรื่อง Code Quality

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

เริ่มต้นของปัญหาเรื่องคุณภาพของ code

แน่นอนว่างานหลักของเราชาว developer ก็คือ การส่งมอบงานให้กับลูกค้า ( Working software )
นั่นคือการส่งมอบสิ่งที่มีคุณค่าต่อลูกค้านั่นเอง

ในโลกแห่งอุดมคติ เรื่องคุณภาพของ code ต้องถูกรวมเข้าไปในงานอยู่แล้ว !!!
แต่ในความเป็นจริงแล้วไม่มีทาง เพราะว่า

• ถูกบีบด้วยเวลา
• ทีมบอกว่า ทำไม่ได้หรอก
• ทีมบอกว่า ทำไม่ทันหรอก

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

ดังนั้นในการทำงานจริงๆ  เรื่อง คุณภาพของ code จึงไม่ใช่เรื่องนามธรรมหรือจับต้องไม่ได้
มันมีคุณค่าต่อ developer อย่างเราๆ ท่านๆ โดยตรง (เรื่องจริงไหม ?)
โดยคุณภาพของ code นั้นสามารถแปลงไปอยู่ในรูปของตัวเงินได้
เป็นทั้งรายรับและรายจ่าย แต่ส่วนใหญ่มันจะเป็นรายจ่ายสำหรับการดูแล code มากกว่า

สิ่งที่หลายๆ คนมักตกหลุมพลางในเรื่อง คุณภาพของ code ก็คือ

code จะต้องสมบูรณ์แบบตั้งแต่เริ่มต้น
เชื่อเถอะว่า code ไม่เคยสมบูรณ์หรือ perfect หรอกนะ

แต่ว่าเราสามารถปรับปรุงให้ code มีคุณภาพที่ดีขึ้นเรื่อยๆ ได้เสมอ
คุณจะแก้ไขเรื่อยๆ อย่างสม่ำเสมอ หรือจะรอไปทำทุกๆ 1, 5, 10 ปี ( คุณต้องเลือก ? )

แล้วคำว่า คุณภาพของ code ที่ดี มันคืออะไร

มาทำความเข้าใจกันก่อน ซึ่งสามารถอธิบายได้ดังนี้

• เป็น code ที่มีโครงสร้างที่เหมาะสม เช่น
  • แต่ละส่วนทำงานตามหน้าที่ของมัน
  • class, method, function จะต้องสั้นและเล็ก
  • ลดการผูกมัดของ code ในส่วนต่างๆ ให้น้อยที่สุดเท่าที่จะทำได้ ทั้ง class และ module
• เป็น code ที่สามารถอ่าน และ ทำความเข้าใจได้ง่าย
• เป็น code ที่สามารถทดสอบได้ หรือมี unit test นั่นเอง

เพียงมีคุณสมบัติ 3 ข้อนี้ แสดงว่า code ของคุณมีคุณภาพที่ดีแล้ว

คำถาม :: มีข้อแนะนำสำหรับการเขียน code ให้มีคุณภาพที่ดีบ้างไหม ?
คำตอบ :: มีสิ ลองทำตามกฏ 4 ข้อของการออกแบบที่เรียบง่าย ของลุง Kent Beck ดูสิ ( Four Simple Design Rule )
โดยเป็นแนวปฏิบัติตามแนวคิด Extreme Programming ( XP )
กฏทั้ง 4 ข้อประกอบไปด้วย

1. Unit test ทั้งหมดจะต้องทำงานผ่านทั้งหมดอยู่เสมอ
2. ลด ละ เลิก สร้าง code ที่ซ้ำซ้อน
3. ทำให้ code ที่สร้างขึ้นมา ให้เข้าใจง่ายมากที่สุด เช่น การตั้งชื่อตัวแปร การตั้งชื่อ method เป็นต้น
   • โดยในส่วนนี้จะเป็นเรื่องของการออกแบบ ไม่ใช่การลงรายละเอียดของการทำงานนะ
   • โครงสร้างคลาสต่างๆ หรือขั้นตอนการทำงานของ code จะต้องเข้าใจได้ง่าย
   • การใช้ชื่อที่เหมาะสมและสื่อความหมาย
   • ลดการสร้าง code ที่ผูกมัดกันมากๆ เช่น ใช้ abstraction layer มาใช้งาน
4. ลดขนาดของ class และ method ให้เล็กที่สุดเท่าที่จะเป็นไปได้  เพื่อลดสิ่งที่อาจจะซ้ำซ้อน และให้แต่ละส่วนทำงานอย่างใดอย่างหนึ่ง

ดังนั้น ถ้า code มีคุณภาพที่ต่ำ หรือ มีคุณภาพที่แย่ คุณอาจจะต้องจ่ายมากกว่าที่คิด

ถ้าคุณไม่ได้สนใจเรื่องคุณภาพของ code เลย สิ่งที่คุณจะได้รับก็คือ spaghetti code
ซึ่งจะราดซอสหรือใส่อะไรไป ก็แล้วแต่จะสรรค์สร้างกันขึ้นมา
โดย code มันจะผูกมัดกันจนไม่มีใครสามารถแยกส่วนการทำงานออกจากกันได้
มี code ที่มีขั้นตอนการทำงานยาวๆ
มีการ copy-and-paste มาใช้
ซึ่งล้วนแต่ทำให้ระบบงานมีความสลับซับซ้อนมาก แสงดังรูป

จากการไปร่วมงาน Thailand PHP User Group พบว่า code มี if ถึง 1,000 if
ผมไม่อยากจะจินตนาการเลยว่า ทีมจะดูแลรักษา code ในส่วนนี้กันอย่างไร ??

จะมีใครกล้าเข้าไปแก้ไข code หรือไม่
ยิ่งถ้าเป็นคนที่ทำงานมานานๆ มักจะพูดว่า  code มันทำงานดีอยู่แล้ว อย่าไปแก้ไขมันเลย !!!
จะกล้า refactor code ไหม ถ้า code ส่วนนั้นไม่มี unit test ( มีความเสี่ยงสูงมากๆ )

ลองคิดเล่นๆ ถ้าระบบงานมีขนาดใหญ่มากๆ แล้วมันจะเป็นอย่างไรนะ ?

มีหลายคนถามมาว่า ถ้าเป็น code ที่พัฒนามา 1, 5, 10 ปีแล้วจะทำอย่างไรดี ?
ตรงนี้ตอบยากมาก เพราะว่า code แต่ละที่แตกต่างกันในหลายเหตุผล

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

โดยสรุปแล้ว

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

แต่ผมมีแนวคิดหนึ่ง สำหรับการทำให้ code มีคุณภาพดีขึ้นอยู่เสมอ คือ Boy Scoute Rule ของลุง Uncle Bob
กล่าวไว้ว่า

เมื่อคุณเข้าไปทำงานในส่วน code ส่วนใดส่วนหนึ่งก็ตาม
code ส่วนนั้นจะต้องมีคุณภาพที่ดีขึ้นกว่าเดิมเสมอ

ดังนั้น ถ้าจุดเล็กๆ มันดีขึ้น ก็จะส่งผลต่อภาพใหญ่ว่ามันต้องดีขึ้นด้วย ดังภาพ

และอย่าลืมว่า

I know it When I see it ….