𝗢𝗻𝗲 𝗦𝗶𝗺𝗽𝗹𝗲 𝗡𝗮𝗺𝗶𝗻𝗴 𝗧𝗿𝗶𝗰𝗸 𝗧𝗵𝗮𝘁 𝗦𝘁𝗼𝗽𝘀 𝗖𝗼𝗱𝗲 𝗥𝗼𝘁
เลิกตั้งชื่อคลาสของคุณว่า Service, Manager หรือ Handler เสียที
ชื่อเหล่านี้คลุมเครือเกินไป และมันทำหน้าที่เหมือนเป็นการอนุญาตให้เกิดการออกแบบที่แย่
หากคุณตั้งชื่อคลาสว่า UserService คุณจะสามารถใส่ทุกอย่างที่เกี่ยวข้องกับผู้ใช้ลงไปในนั้นก็ได้ คุณอาจจะเพิ่มการรีเซ็ตรหัสผ่าน, การกำหนดบทบาท (role assignments) และการคำนวณส่วนลด ซึ่งทั้งหมดนี้ล้วนเกี่ยวข้องกับผู้ใช้ ชื่อนี้จึงดูเหมือนจะถูกต้อง
แต่ภารกิจเหล่านี้มีกฎและสิ่งที่ต้องพึ่งพา (dependencies) ที่แตกต่างกัน UserService เพียงคลาสเดียวจึงกลายเป็นความวุ่นวายขนาดใหญ่
ลองเปลี่ยนมาใช้การตั้งชื่อแบบ agentive naming แทน โดยใช้ชื่อที่อธิบายการกระทำที่เฉพาะเจาะจง:
• UserRegistrar • PasswordResetter • RoleAssigner • DiscountCalculator
ชื่อเหล่านี้จะสร้างแรงเสียดทาน (friction) ขึ้นมา หากอยู่ดีๆ PasswordResetter จำเป็นต้องใช้เครื่องมือสำหรับออกใบแจ้งหนี้ (invoices) ความผิดพลาดนั้นจะเห็นได้อย่างชัดเจน ชื่อที่เฉพาะเจาะจงจะทำให้การออกแบบที่แย่นั้นยากที่จะมองข้าม
ชื่อที่คลุมเครืออย่าง UserService ก็เหมือนกับ type "any" ในการเขียนโปรแกรม คือมันยอมรับทุกอย่าง ในขณะที่ชื่อที่แม่นยำจะช่วยสร้างขอบเขต (boundaries)
เรื่องนี้มีความสำคัญมากขึ้นในยุคของ AI
AI coding agents จะดูโค้ดที่คุณมีอยู่เพื่อตัดสินใจว่าจะวาง logic ใหม่ไว้ที่ไหน หากคุณให้ UserService แก่ AI มันจะเพิ่มฟีเจอร์ใหม่ๆ ลงในคลาสที่วุ่นวายเดิมนั้น และมันจะทำสิ่งนี้ได้อย่างรวดเร็วมาก
แต่ถ้าคุณให้ PasswordResetter แก่ AI มันจะทำงานอยู่ภายใต้ขอบเขตที่เฉพาะเจาะจงนั้น
Codebase ของคุณคือ prompt สำหรับ AI การใช้ชื่อที่คลุมเครือคือการสอนให้ AI ออกแบบอย่างคลุมเครือเช่นกัน
ชื่อไม่ได้สร้างสถาปัตยกรรมที่ดี แต่มันทำให้สถาปัตยกรรมที่แย่นั้นปรากฏให้เห็นชัดเจน
จงตั้งชื่อให้ทุกความรับผิดชอบ (responsibility) ให้แม่นยำพอจนกระทั่งโค้ดที่ไม่เกี่ยวข้องดูผิดที่ผิดทาง
Source: https://dev.to/caeus/one-simple-naming-trick-that-keeps-vibe-coded-code-from-rotting-5hf5
Optional learning community: https://t.me/GyaanSetuAi