สรุปเรื่องของ Code Quality จาก Code Climate

นั่งดู VDO เรื่อง Code Quality Lessons Learned จาก CodeClimate.com ตั้งคำถามที่น่าสนใจเกี่ยวกับ Code Quality ไว้ดังนี้

1. Code Quality คืออะไร ?
2. ใช้อะไรวัดค่าความซับซ้อนของ code ?
3. ทำไม code ของ project เก่า ๆ ถึงดูแลยากนักล่ะ ?
4. ขนาดของ code ในแต่ละ Pull request สำหรับการ review ควรเป็นเท่าไรดี ?
5. เมื่อไรที่ code แย่ ๆ ไม่ใช่ปัญหา ?
6. อะไรบ้างที่เป็นตัวขัดขวาง Clean code ?

เท่านี้ก็น่าสนใจแล้ว จึงทำการสรุปไว้นิดหน่อย ส่วนตัวเต็ม ๆ ลองไปฟังจาก VDO ได้ครับแค่ 1 ชั่วโมงเอง

1. Code Quality คืออะไร ?

สิ่งที่ตรงข้ามกับ Code Quality คือ Legacy code ซึ่งมีความหมายมากมาย เช่น

• Code ที่เขียนจากคนอื่น ๆ
• Code ที่เขียนจากตัวเราเองเมื่อ 2 สัปดาห์ก่อน
• Code ที่ไม่มี test

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

• Code ที่อ่านง่าย เข้าใจง่าย
• Code ที่มีการทดสอบที่ดี
• Code ที่มีชุดการทดสอบครอบคลุม
• Code ที่ไม่มี bug
• Code ที่ทำการ refactor มาแล้ว
• Code ที่มีเอกสารอธิบายชัดเจน
• Code ที่สามารถขยายเพิ่มได้ง่าย
• Code ที่ทำงานได้อย่างรวดเร็ว

พูดคุยและตกลงกันภายในทีมให้เรียบร้อยนะ เพราะว่า นั่นคือเป้าหมายของทุกคนในทีม ซึ่งมีคำพูดที่น่าสนใจคือ

Any code less decomposed than mine is a mess. Any code more decomposed.

นั่นคือ code ที่เอาทุกสิ่งทุกอย่างมารวมกันไว้ในที่เดียว หรือพวก God class/method ทำให้เกิด Spaghetti code ก็ไม่ใช่สิ่งที่ดี หรือ code ที่แยกการทำงานต่าง ๆ ออกจากกัน มากจนเกินไป เราจะพบได้จากระบบที่นำเอา Design pattern มาใช้งานตั้งแต่แรกเริ่ม ซึ่งเราเรียกว่า over-engineering ก็ไม่ใช่สิ่งที่ดี ดังนั้นแต่ละระบบล้วนแตกต่างกัน ต้องปรับเปลี่ยนให้เหมาะสมกันไป

2. ใช้อะไรวัดค่าความซับซ้อนของ code ?

และใช้ตัวชี้วัดอะไรบ้าง เช่น

• Cyclomatic Complexity
• ABC metric
• Lines of Code (LOC)

ทีมลองตัดสินใจร่วมกันนะครับ ซึ่งอย่างน้อยให้ใช้ LOC มาเป็นตัวชี้วัด เช่น ในแต่ละ class/method ควรไม่เกินกี่บรรทัดดี ?

3. ทำไม code ของ project เก่า ๆ ถึงดูแลยากนักล่ะ ?

เนื่องจาก code แย่ ๆ มันถูกสร้างออกมาอย่างต่อเนื่องไงล่ะ เริ่มจากแรงกดกันจากส่วนต่าง ๆ ทั้งจากภายนอกและภายใน รวมทั้งสิ่งเล็ก ๆ ที่เรียกว่า Deadline ทำให้นักพัฒนาทุกคนสนใจแต่ ทำให้เสร็จ ทำให้เสร็จ ทำให้เสร็จ โดยไม่ได้สนใจ และ ใส่ใจใน code เลยว่าดีหรือไม่ และ code เหล่านั้นมันกลับทำให้ project พัฒนาช้าไปกว่าเดิม !! และจะอยู่ในวงจรนี้ไปเรื่อย ๆ แสดงดังรูป นั่นคือเมื่อเวลาผ่านไป Technical Debt ก็ยิ่งมากขึ้น รวมทั้ง Domain หรือ Business ก็เปลี่ยนไปเรื่อย ๆ ทำให้ code มีจำนวนสูงขึ้น Code ที่ไม่ใช้งานก็เยอะขึ้น เป็นแบบนี้ไปเรื่อย ๆ ทำให้ code เหล่านี้ดูแลได้ยากขึ้นเรื่อย ๆ ดังรูป จากปัญหาเหล่านี้เราจะทำอย่างไรดีล่ะ ? เพื่อทำให้ code หรือระบบของเรามันดีขึ้น ซึ่งมีให้เลือก 2 แบบคือ

1. Big design คือ คิดใหม่ ทำใหม่ ออกแบบใหม่ เขียนใหม่หมดเลย !!
2. Iterative design คือ ค่อย ๆ ปรับเปลี่ยน ค่อย ๆ แก้ไขไปเรื่อย ๆ ซึ่งให้นำแนวคิด The Boy Scout Rule มาใช้

4. ขนาดของ code ในแต่ละ Pull request สำหรับการ review ควรเป็นเท่าไรดี ?

นั่นคือในการ review code แต่ละครั้งนั้น จำนวน LOC ควรเป็นเท่าไรดี ? จากบทความเรื่อง 11 proven practices for more effective, efficient peer code review อธิบายไว้ว่า ยิ่ง Pull request มีขนาดใหญ่มาก ยิ่งหา issue/bug ต่าง ๆ ได้น้อยลง ดังนั้นคำแนะนำคือ ในการ review code แต่ละครั้ง LOC ไม่ควรเกิน 400 บรรทัดนะ ซึ่งเป็นการ review code โดยใช้คน ไม่ได้ใช้เครื่องมือ นั่นหมายความว่า คนเรามีข้อจำกัดนะ ยิ่ง code เยอะ ก็ไม่อยากจะ review กัน !!

5. เมื่อไรที่ code แย่ ๆ ไม่ใช่ปัญหา ?

เรื่องนี้มันขึ้นอยู่กับ business ล้วน ๆ เช่น

• ทำแล้วทิ้ง
• ต้องการพิสูจน์อะไรบางอย่าง
• business model เปลี่ยนบ่อยมาก ๆ
• code ที่ไม่มีการเปลี่ยนแปลงเลย

ดังนั้นการจะเขียน code แย่ ๆ จึงไม่ใช่ปัญหาอะไรมากมาย แต่ถ้าเป็น product ที่คุณต้องดูแลไปนาน ๆ แล้ว code แย่ ๆ จะสร้างปัญหาให้คุณแน่นอน

6. อะไรบ้างที่เป็นตัวขัดขวาง Clean code ?

ซึ่งทำให้เกิด code ที่แย่ ๆ ขึ้นมามากมายขนาดนี้ !! เริ่มด้วยการขาดความสนใจ ขาดความใส่ใจในสิ่งที่กำลังทำ ต่อมาคือ ขาดความรู้และความสามารถ บางครั้งเราไม่รู้ด้วยว่า สิ่งที่เราทำไปนั้นเป็นสิ่งที่ไม่ดี บางครั้งเราไม่รู้ด้วยซ้ำว่า จะแก้ไขอย่างไร และบ่อยครั้งที่ requirement เปลี่ยนบ่อยมาก ๆ ดังนั้นเราก็ทำให้มันเสร็จ ๆ ไปเถอะ เดี๋ยวก็เปลี่ยนแปลงอีก ซึ่งมันกลายเป็นสาเหตุหรือข้ออ้างหลักสำหรับการสร้าง code แย่ ๆ เลยนะ !! จากบทความเรื่อง Why do teams fail to sustain code quality? อธิบายสาเหตุของ code ที่ซับซ้อน แน่นอนว่า มันยากต่อการดูแล และ ง่ายต่อการเกิด bug อย่างมาก แสดงดังรูป แต่สาเหตุหลักของ Code แย่ ๆ คือ ความกลัว (Fear) กลัวที่จะไม่ทัน กลัวที่จะโดนด่า กลัวที่แก้ไขไปแล้ว จะทำให้ระบบทำงานไม่ได้ ทั้งที่รู้และไม่รู้ กลัวที่แก้ไขไปแล้ว จะทำให้ตัวเองมีภัย กลัวที่จะ ... ดังนั้นมาลดความกลัวเหล่านี้กันเถอะ เช่น

• Automated testing
• Operational metrics
• Code review
• Static analysis
• Pair programming

สุดท้ายแล้ว

ยังมีอะไรให้เรียนรู้อีกมากมาย ยังมีอะไรให้ปรับปรุงอีกมากมาย ดังนั้น เรื่องของวินัย เรื่องของความสามารถ เรื่องของอารมณ์และความรู้สึกร่วม มันต้องมาและไปพร้อม ๆ กัน

วันนี้เราเรียนรู้อะไรบ้างแล้วหรือยัง ? วันนี้เราปรับปรุงความสามารถให้ดีขึ้นแล้วหรือยัง ? วันนี้เราเขียน code แล้วหรือยัง ?