วันนี้อ่านเจอกฎการเขียน code ของคุณ Sandi Metz
ทำการพูดไว้ตั้งแต่ปี 2013 ที่ Book Club: Practical Object-Oriented Design in Ruby with Sandi Metz
จากการอ่านพบว่าเป็นกฎที่น่าสนใจ
มาดูกันว่ากฎเหล่านั้นมีอะไรบ้าง
กฏของ Sandi Metz ประกอบไปด้วย 4 ข้อ
- แต่ละ class มีจำนวน Line of Code (LoC) ไม่เกิน 100 บรรทัด
- แต่ละ method มีจำนวน Line of Code (LoC) ไม่เกิน 5 บรรทัด
- แต่ละ method มีจำนวน parameter ไม่เกิน 4 ( บางคนจะโกงด้วยการสร้าง Object หรือ Hash เข้าไป อย่านะ !! )
- ใน controller ควรมีการสร้าง instance เพียงตัวเดียว นั่นคือ สิ่งที่จะส่งกลับไปนั่นเอง
สามารถแหกกฎนี้ได้ก็ต่อเมื่อ ..
คุณ Sandi Metz พูดไว้ว่า
คุณสามารถแหกกฎนี้ได้ก็ต่อเมื่อ คุณมีเหตุผลที่ดีพอ
เพื่อบอกให้คู่ pair หรือ ทีม หรือคนทำการ reviewode
เข้าใจ และ ยอมรับในเหตุผลนั้นๆ
ให้คิดซะว่า กฎนี้ไม่มีอยู่จริง แต่มันคือสิ่งที่คุณยอมรับ
และพยายามปฏิบัติตามมัน
และกฎนี้ไม่สามารถเปลี่ยนแปลงได้
บางคนบอกว่า กฎนี้มันยาก ทำตามไม่ได้หรอกในโลกของความจริง
ตอบได้เลยว่า ใช่แล้ว แต่ ..
คุณ Jbrains พูดเกี่ยวกับกฎนี้ได้อย่างน่าสนใจ ดังนี้
These are Novice Rules. They’re meant to teach you things. Your goal is to learn those things so that you can move away from the rules. Don’t bother following Novice Rules that don’t encourage you to do something you don’t like.
เราได้เรียนอะไรบ้างจากกฎทั้ง 4 ข้อ
1. แต่ละ class ไม่เกิน 100 LoC
มันบอกว่า ถ้า class คุณใหญ่มากไป มันอ่านยาก เขียนยาก เข้าใจยาก
แถมมีหน้าที่เยอะด้วย ดังนั้น คุณควรแยกหน้าที่การทำงานออกไปยัง class อื่นซะ
นั่นคือการเคารพใน Single Responsibility Principle (SRP)
และยังสามารถประยุกต์ใช้ในพวก specification ต่างๆ ได้นะ
เคยไหมที่เจอไฟล์เอกสาร หรือ specification ที่มันใหญ่ๆ เยอะๆ
แถมเปิดช้าอีก … แต่ก็ทนๆ กันไป
ทำไมไม่แยกออกเป็นไฟล์เล็กๆ ?
ทำไมไม่แยกตาม feature อะไรทำนองนั้นบ้างล่ะ ?
2. แต่ละ method ไม่เกิน 5 LoC
เป็นกฎที่น่าสนใจมากๆ ลองคิดดูสิว่า
ถ้า code คุณใช้ if-elseif-else เยอะ
มันก็กินไป 3 บรรทัดล่ะ !!
ดังนั้น มันจึงสอนให้เรา คิดหน่อยสิว่าจะทำอย่างไรดี ?
ลด ล่ะ เลิก การใช้งานมันไปเลยดีไหม ?
ถ้าดี ทำอย่างไรได้บ้างล่ะ ?
ดังนั้น สิ่งที่เราต้องทำ คือ คิดใหม่ทำใหม่ หาแนวทางใหม่ๆ เช่น
การแยกไปเป็น method ใหม่ ด้วยชื่อที่เหมาะสม
การทำงานภายใน method ต้องเป็นไปตามชื่อ method
แต่ละ method จะกลายเปป็นเอกสารที่ดีเลยนะ
ถ้าไม่เชื่อลองทำตามดูสิครับ
3. จำนวน paramater ไม่เกิน 4 ตัว
ยิ่งจำนวน parameter เยอะ แสดงว่า ขั้นตอนการทำงานใน method เยอะ
หรือมีการตรวจสอบเงื่อนไขต่างๆ เยอะ
ทำให้ code มีจำนวนเยอะ
ยังไม่พอนะ การทดสอบก็จะเยอะเป็นเงาตามตัวไปด้วย
ดังนั้นแต่ละ method ควรจะมีจำนวน parameter น้อยๆ เข้าไว้นะครับ
ดีที่สุด คือ ไม่มีเลย นั่นเอง
4. ในแต่ละ controller class ควรมีการสร้าง object เพียงตัวเดียว
เป็นกฎที่ช่วยทำให้แต่ละ controller จะส่งอะไรกลับไปยังผู้เรียกใช้ เช่น view เป็นต้น
ลองคิดดูสิว่า
ถ้าใน controller ส่ง object กลับไปผู็เรียกใช้จำนวนเยอะมากกว่า 1 ตัว
ทางผู้ใช้งานจะจัดการยากเพียงใด
ทำไมเราไม่ส่งเพียง object เดียวกลับไปล่ะ
นั่นคือ มันส่งผลให้เกิดพวก Bean/Model สำหรับแต่ละหน้าจอไปเลย
ซึ่งมันสะดวกมากเลยนะ ว่าหรือเปล่าครับ
และบรรดา framework ต่างๆ ก็ยึดตามกฎนี้ด้วยเช่นกัน
แต่ส่วนใหญ่เราทำกันไหมนะ ??
ดังนั้น ลองนำกฎนี้ไปทดลองใช้กันดูครับ
แล้วมาดูผลกันว่าดีอย่างไร และ สอนอะไรคุณบ้าง …
Reference Websites
https://robots.thoughtbot.com/sandi-metz-rules-for-developers
https://gist.github.com/henrik/4509394
http://www.sampierson.com/articles/sandi-metz-s-5-rules
https://github.com/makaroni4/sandi_meter
http://gistflow.com/posts/901-sandi_meter-tool-for-checking-sandi-metz-rules
