readability-lede
วันนี้เห็นบทความอธิบายเรื่อง 7 Rules on Code Readability จาก Crisp blog
ได้อธิบายกฎเกี่ยวกับ code ที่มันอ่านง่าย เข้าใจง่าย
ไว้อย่างน่าสนใจ ดังนั้นมาดูกันหน่อยว่ามีอะไรที่น่าสนใจ
และน่านำไใช้ปรับปรุงในการเขียน code ของ developer ทั้งหลาย

คำว่า code ที่ดีมันคืออะไร ?

code ที่มีคุณภาพที่ดีไงล่ะ
code ที่อ่านเข้า เข้าใจง่ายไงล่ะ

ลองคิดดูสิ
ถ้าคุณไม่สามารถอ่านและเข้าใจ code ได้
คุณก็ไม่สามารถเขียน หรือ แก้ไข code ได้ใช่ไหม ?

ดังนั้น เราจะเขียน code ที่มันอ่านง่าย และ เข้าใจง่ายได้อย่างไรล่ะ ?
มาดูวิธีการ และ กฎแปลกใหม่จาก Crisp blog กันดู

1. Rewrite what you wrote

ในครั้งแรกให้คุณเขียน code เพื่อแก้ไขปัญหาให้ได้ก่อน
เพื่อทำให้คุณมีสมาธิในการแก้ปัญหา
มันคือ Make it work
แต่เชื่อเถอะว่า code ที่ได้ออกมามันจะแย่มากๆ อ่านเข้าใจยากมาก
แต่รู้ว่า code ชุดนี้มันทำงานได้นะ !!

ดังนั้น ให้คุณทำการเขียน code ชุดนั้นใหม่ทันที
เนื่องจากตอนนี้คุณเข้าใจปัญหา และ วิธีการแก้ไขปัญหาแล้ว
ดังนั้น ได้เวลาปรับปรุง code ให้ดีขึ้น
ได้เวลาปรับปรุง code ให้มันอ่านง่ายขึ้น
มันคือ Make it Right

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

2. No comments

ให้พยายามหลีกเลี่ยงการเขียน comment
แต่ไม่ได้บอกว่า ห้ามเขียน comment นะ

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

บางคนบอกว่า เขียน comment นะดีแล้ว อธิบายได้ละเอียดดี
ซึ่งนั่นเป็นเหตุผลที่ดีในการเขียน comment
แต่มันจะ update ตามการเปลี่ยนแปลงใช่ไหม ?
ถ้าใช่ก็ดีไป แต่ถ้าไม่ก็ตัวใครตัวมัน

แต่ถ้าเป็น code ในกลุ่มของ APIs
ที่ต้องการใช้ comment เพื่อนำมาสร้างเอกสารต่างๆ
มันก็สมเหตุสมผลที่การเขียน comment นะ

แต่อย่าใช้ comment เพื่อมาอธิบาย code ที่มันอ่านไม่รู้เรื่องนะ !!

และใน code เรามักจะเจอ TODO เยอะมากๆ
มันบ่งบอกอะไรกับเราบ้าง ?
มันจำเป็นต้องมีไหม ?
มันมีมาเพื่ออะไร ?

TODO มีมาเพื่อบอกว่า เราจะต้องทำงานตรงไหนบ้าง !
ดังนั้น มันจึงมีเยอะไปหมด !
หมายความว่า งานคุณเยอะ หรือ ว่า คุณทำงานไม่เสร็จสักอย่างเลย
ดังนั้น ค่อยๆ ทำไปทีละงานนะครับ
แล้ว TODO มันจะไม่มีอีกเลย

3. Good Names

ชื่อนั้นสำคัญฉไน !!

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

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

4. Extract nested loops

เรามักจะเจอ code ที่มี loop ซ้อน loop ซ้อน loop ซ้อน loop
เข้าไปอย่างสวยงาม แต่พบว่า มันอ่านยาก และ ทำความเข้าใจยากมากๆ
จะแก้ไขหรอ … ขอบอกว่า มันสนุกมากๆ

ดังนั้นแก้ไขง่ายๆ ด้วยการ extract แต่ละ loop
ออกไปยัง method ใหม่เท่านั้นเองครับ

5. Maximum 7 lines

จากกฎของ Sandi Metz บอกไว้ว่าไม่เกิน 5 บรรทัด
มาถึงกฎใน blog นี้บอกว่า ไม่เกิน 7 บรรทัด
ซึ่งมันบ่งบอกว่า จำนวนบรรทัดในแต่ละ method น้อยๆ นะดีแล้ว

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

6. Formatting

ในการทำงานเป็นทีม เรื่องการจัดรูปแบบของ code มันสำคัญมากๆ
ถ้าแต่ละคนมีการจัด code ที่แตกต่างกัน แล้วจะทำงานร่วมกันได้ไหม ?
ดังนั้น ควรตกลงกันตั้งแต่ก่อนทำงาน
และสามารถเปลี่ยนได้อยู่เสมอนะ

คุณจะเว้นบรรทัดว่างๆ ไว้ปลูกผักหรอครับ ?

7. If you can’t read it, rewrite

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

ลองเปลี่ยนแนวคิดกันบ้างไหม ?
ถ้าคุณบอกว่า code ชุดนี้มันง่ายไม่เข้าใจ มันแย่
ก็ให้ทำการเขียนมันขึ้นมาใหม่สิ
ถ้ามันไม่มี test คลุม อาจจะมีความเสี่ยง
ดังนั้น ลดความเสี่ยงด้วยการเขียน test
และใช้เครื่องมือในการ refactoring ช่วยเหลือสิ

โดยการ rewrite นั้น มันจะช่วยทำให้คุณเข้าใจต่อ code และระบบมากยิ่งขึ้น
ซึ่ง code ที่เขียนขึ้นมาใหม่อาจจะ check in เข้า Source control หรือไม่ก็ได้นะ

สิ่งหนึ่งที่ต้องจำไว้
เมื่อคุณพบว่า code มันยาวมากๆ
แน่นอนว่า มันคือแหล่งกำเนินของ bug เลย
ดังนั้น ถ้าคุณต้องการ rewrite code ส่วนนี้
กรุณาเขียน test ด้วย ไม่เช่นนั้นจะมีความผิดพลาดสูงมากๆ
ถ้าไม่เขียน test กรุณาอย่า check in code ขึ้นไปนะ !!

ทั้ง 7 ข้อเป็นกฎที่น่าสนใจมากของ Crisp blog
ลองนำไปใช้และปฏิบัติดูนะ
ถ้าใครมีกฎดีๆ มาบอกกันได้นะครับ