นั่งดู VDO เรื่อง Code Quality Lessons Learned จาก CodeClimate.com
ตั้งคำถามที่น่าสนใจเกี่ยวกับ Code Quality ไว้ดังนี้
- Code Quality คืออะไร ?
- ใช้อะไรวัดค่าความซับซ้อนของ code ?
- ทำไม code ของ project เก่า ๆ ถึงดูแลยากนักล่ะ ?
- ขนาดของ code ในแต่ละ Pull request สำหรับการ review ควรเป็นเท่าไรดี ?
- เมื่อไรที่ code แย่ ๆ ไม่ใช่ปัญหา ?
- อะไรบ้างที่เป็นตัวขัดขวาง 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 ?
และใช้ตัวชี้วัดอะไรบ้าง เช่น
ทีมลองตัดสินใจร่วมกันนะครับ
ซึ่งอย่างน้อยให้ใช้ LOC มาเป็นตัวชี้วัด
เช่น ในแต่ละ class/method ควรไม่เกินกี่บรรทัดดี ?
3. ทำไม code ของ project เก่า ๆ ถึงดูแลยากนักล่ะ ?
เนื่องจาก code แย่ ๆ มันถูกสร้างออกมาอย่างต่อเนื่องไงล่ะ
เริ่มจากแรงกดกันจากส่วนต่าง ๆ ทั้งจากภายนอกและภายใน
รวมทั้งสิ่งเล็ก ๆ ที่เรียกว่า Deadline
ทำให้นักพัฒนาทุกคนสนใจแต่ ทำให้เสร็จ ทำให้เสร็จ ทำให้เสร็จ
โดยไม่ได้สนใจ และ ใส่ใจใน code เลยว่าดีหรือไม่
และ code เหล่านั้นมันกลับทำให้ project พัฒนาช้าไปกว่าเดิม !!
และจะอยู่ในวงจรนี้ไปเรื่อย ๆ
แสดงดังรูป
นั่นคือเมื่อเวลาผ่านไป Technical Debt ก็ยิ่งมากขึ้น
รวมทั้ง Domain หรือ Business ก็เปลี่ยนไปเรื่อย ๆ
ทำให้ code มีจำนวนสูงขึ้น
Code ที่ไม่ใช้งานก็เยอะขึ้น
เป็นแบบนี้ไปเรื่อย ๆ ทำให้ code เหล่านี้ดูแลได้ยากขึ้นเรื่อย ๆ
ดังรูป
จากปัญหาเหล่านี้เราจะทำอย่างไรดีล่ะ ?
เพื่อทำให้ code หรือระบบของเรามันดีขึ้น
ซึ่งมีให้เลือก 2 แบบคือ
- Big design คือ คิดใหม่ ทำใหม่ ออกแบบใหม่ เขียนใหม่หมดเลย !!
- 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 แล้วหรือยัง ?
