วันนี้เห็น tweet ใน Twitter เรื่อง Seven Ineffective Coding Habits of Many Programmers
ทำการสรุป 7 อุปนิสัยที่ไม่ดีสำหรับการ coding
เก่าหน่อยแต่ก็ยังมีประโยชน์
เนื่องจากการพัฒนา software ซึ่งมีความซับซ้อนนั้น
นักพัฒนาต้องมีอุปนิสัยที่ดี
เพื่อที่จะได้นำมาใช้ในการพัฒนา software ได้อย่างคล่องแคล่วและเป็นธรรมชาติ
ทั้งการตั้งชื่อ
ทั้งรูปแบบของ code
ทั้งโครงสร้างที่ดี
ทั้งการ comment เพื่ออธิบาย code
ทั้งการเขียน unit testing
ทั้ง … มันเยอะมาก
ยากนะ
ดังนั้นใน VDO นี้จะทำการอธิบาย 7 อุปนิสัยที่ไม่ดีซึ่งไม่ควรทำ
จึงสรุปไว้นิดหน่อย
1. การเขียน comment ที่ไม่ดี หรือ ไม่มีประโยชน์
ส่งผลให้ code อ่านและทำความเข้าใจยาก
หรือทำให้เข้าใจผิดได้ง่าย
ที่สำคัญ code ควรอธิบายการทำงานของมันเองให้ได้ดีก่อน
ยกตัวอย่างที่เจอมา
// Step 1 step1(); // Step 2 step2(); // Step 3 step3();
2. แต่ละบรรทัดยาวเกินหน้าจอ
มันดูและอ่านยาก
พูดง่าย ๆ คือ ในการดู code ไม่ควรต้อง scroll ในแนวนอน
หรือไม่เกินหน้าจอนั่นเอง
หรือถ้าจอใครมันกว้าง ก็ให้ code แต่ละบรรทัดยาวแค่ครึ่งจอก็พอ
ลองเอา code ขึ้น projector ดูนะครับ จะเห็นว่า code อ่านยากหรือง่าย
3. การจัดการ argument ของ method ไม่ดี
4. การตั้งชื่อที่แย่ หรือ abstraction ที่แย่
ยกตัวอย่างเช่น int number
ตัวแปรชื่อ number มีชนิดเป็น int มันดูแปลก ๆ ไหม ?
หรือใช้คำกลาง ๆ เช่น Manage, Proxy, Factory, Service และ Process !!
คำมันกว้างไปนะ
ดังนั้นสิ่งที่ควรทำคือ
ชื่อต่าง ๆ นั้นควรอธิบาย domain ของ business ว่าเป็นอย่างไร
ทดสอบง่าย ๆ ด้วยการดูว่าใน code ของระบบงานนั้น มีคำอะไรเยอะ ๆ
นั่นจะบอกว่า คุณตั้งชื่อได้ดีหรือแย่
5. สร้าง method ที่ซับซ้อน พร้อมต้องส่ง parameter จำนวนมากเข้าไป
ใน VDO ขอว่า 326 คือจำนวนของ parameter ที่ต้องส่งเข้าไปยัง method !!
เยอะไปไหน ?
ยังไม่พอนะใน method ชอบให้ส่ง boolean parameter เข้าไปเช่น
methodName(true, false, true)
คำถามคือ มันคืออะไร ?
ทำไมไม่แยกเป็น method ย่อย ๆ
ทำไมไม่ลดจำนวน parameter ลงไป
6. การ Encapsulate ที่แย่
นักพัฒนาคือว่า การ encapsulate คือ
ไม่ให้ access ตัวแปรใน class ตรง ๆ ได้
ดังนั้นจึงสร้าง getter/setter method มาให้ใช้
มันใช่ไหม ?
ยกตัวอย่างเช่น
คำถามคือ มันใช่การ encapsulate หรือไม่นะ ?
7. ชุดการทดสอบต้องสะท้อน function หรือการทำงานของระบบนะ
แค่ให้เขียนชุดการทดสอบก็ยากพอดูแล้ว
การเขียนให้ดีมันยิ่งยาก และสำคัญมาก ๆ
เพื่อให้ง่ายต่อการอ่านและทำความเข้าใจ
ดังนั้นชื่อการทดสอบต้องเข้าใจได้ง่าย
เช่น
testcase0001 ไม่น่าจะรู้เรื่องนะ
should_success/should_fail ก็ไม่น่าจะรู้เรื่อง
should_be_empty_after_delete_all_item_in_basket น่าจะอ่านรู้เรื่องกว่าไหม ?
