(โพสต์นี้อิงจากที่ส่งให้ list ไปไม่กี่เดือน ถ้าอยากอ่านแบบนี้ทุกสัปดาห์ สมัครที่นี่!)
ใน "Using a Little Bit of Convenience to Save Your Programming Flow" ผมพูดถึงว่า abstraction เรียบง่ายที่สุดทำให้ codebase สนุกขึ้น
แต่ถ้ามี bad abstraction จะเป็นยังไง?
ขุด API reference ทุกครั้ง เข้าใจว่าเมธอดที่ ชัดเจน ควรชื่อ leaderboard จริงๆ ชื่ออะไร พยายาม refactor รอบๆ แตส่วนหนึ่งส่ง structured data อีกส่วนส่ง raw text ทุกครั้งที่แตะโค้ด ก็พัง ใช้เวลาวัน debug เพราะ tweak position แตไม่อัปเดต score พร้อมกัน
ดังนั้น สร้าง good abstractions หลีกเลี่ยง bad อย่างไร?
ใช้ Metaphor ดี เขียนโค้ดชัดเจน
Good abstractions มาจาก good metaphors
Metaphor อธิบายสิ่งในระบบ โดยเชื่อมโยงกับ concept ที่อยู่ในหัวคุณแล้ว เช่น:
-
Command lines ใช้ metaphor ของ pipe
ใส่ข้อมูลปลายหนึ่ง ออกอีกปลาย ง่ายต่อการจินตนาการและใช้งาน
-
ใน concurrent programming lock เป็น metaphor ดี
ไม่รู้ internal lock works ยังรู้ว่า resource ถูกล็อก ไม่ได้ใช้ ต้องรอ unlock
-
ใน OOP message passing สร้างภาพจิต: object ส่ง message ให้ object อีกตัว ตัวที่สองทำอะไรกับ message หรือส่งต่อ
ไม่ต้องรู้ implementation ก็เข้าใจได้ (ทำให้ proxy pattern เข้าใจง่าย)
Good metaphor สำคัญมาก ถ้าเห็น abstraction based on good metaphor คุณจะแทบไม่ต้องอ่าน docs หรือ source dive เข้าใจโค้ด ยิ่ง metaphors ดี ยิ่งง่ายอธิบายระบบให้คนอื่น และทำงานระบบต่อได้ง่าย
หา Metaphor ดี อย่างไร?
Good metaphor คือ specific, self-contained, สร้าง mental image ชัดเจน ไม่ทิ้งที่สำหรับเข้าใจผิด และ match พฤติกรรมโค้ดมากที่สุด ถ้าคนสมมติสิ่งจาก metaphor สมมติฐานควรถูกต้อง
หา good metaphors ยาก จะผ่าน leaky metaphors หลายตัวก่อนเจอตัวถูก และโอเค! จะง่ายขึ้นกับการฝึก แต่กระบวนการนี้ช่วยผม:
คิดว่า อะไร โค้ดทำ โดยไม่คิด อย่างไร มันทำ ภาพอะไรมาในใจ? โค้ดอื่นใช้มันยังไง? ถ้าอธิบายใน 1-2 คำ จะใช้คำไหน? เขียนไว้
จากนั้น คิดภาพนั้น ตรงกับโค้ดไหม? มี edge cases รั่วไหม? มีอะไร นอกจาก metaphor ที่ contributor ใหม่ต้องเข้าใจก่อนใช้โค้ด? คิด metaphor ภาพชัดหรือเบลอ?
นี่คือ indicators ว่า metaphor ไม่ match โค้ดพอ แตยิ่งใกล้ good metaphor ยิ่งกระโดดน้อย
สุดท้าย ใช้ในประโยค "โค้ดนี้ คือ (บางอย่าง) เพราะ…" อธิบาย metaphor ให้คนไม่มี technical background เข้าใจได้ไหม? ยิ่งต้องการ background น้อย ยิ่ง metaphor ช่วยได้มาก
ถ้าใกล้แตยังไม่ถึง ดู thesaurus ความแตกต่างเล็กน้อยระหว่างคำใกล้เคียง อาจแปลกใจว่าเป็น OK metaphor หรือ perfect metaphor
Metaphors และ OOP
OOP พัฒนามาจาก metaphor นั่นแหละที่มาพลัง! Well-designed classes ไม่แค่ซ่อน implementation จาก classes อื่น แต่ซ่อนจาก คุณ
ด้วย metaphor ดี คุณควรบอกได้แค่จากชื่อคลาส ว่าใช้ objects ยังไง ถ้าชื่อ classes ดี และสร้างภาพจิตถูกต้อง ไม่ต้องดู implementation เข้าใจได้
ตอนนี้ ผมอยากให้คุณคิดถึง classes ในโค้ดล่าสุดที่ทำงาน มีที่มี metaphors ชัดเจนไหม? คลาสไหนรู้สึกว่า ทำงานร่วม ไม่ใช่ ต่อสู้? บ่อยแค่ไหนที่ขุดเข้าไปหาวิธีใช้?
ผมอยากรู้ คอมเมนต์บอกผมหน่อย
เพื่อเป็น software developer เก่งเร็ว ต้องคิดจागरูบเกี่ยวกับโค้ดที่เขียนและ processes ที่ทำ และผมช่วยคุณได้
ดาวน์โหลด sample ฟรี 32 หน้าของ Practicing Rails เรียนรู้ลองไอเดียแบบนี้ใน scale เล็ก โดยไม่ overwhelmed
