ข้ามไปยังเนื้อหาหลัก

การตั้งชื่อ (Naming)

นักพัฒนาแต่ละคนมีประสบการณ์และบริบทที่ต่างกัน ซึ่งอาจนำไปสู่ความเข้าใจผิดในทีมเมื่อเรียก Entities เดียวกันด้วยชื่อที่ต่างกัน ตัวอย่างเช่น:

  • Components สำหรับแสดงผล อาจเรียกว่า "ui", "components", "ui-kit", "views", …
  • โค้ดที่นำมาใช้ซ้ำทั่วทั้งแอปพลิเคชัน อาจเรียกว่า "core", "shared", "app", …
  • โค้ด Business logic อาจเรียกว่า "store", "model", "state", …

การตั้งชื่อใน Feature-Sliced Design​

ระเบียบวิธีนี้ใช้คำศัพท์เฉพาะ เช่น:

  • "app", "process", "page", "feature", "entity", "shared" เป็นชื่อ Layers
  • "ui', "model", "lib", "api", "config" เป็นชื่อ Segments

การยึดตามคำศัพท์เหล่านี้สำคัญมาก เพื่อป้องกันความสับสนระหว่างสมาชิกในทีมและนักพัฒนาใหม่ที่เข้าร่วมโปรเจกต์ การใช้ชื่อที่เป็นมาตรฐานยังช่วยเมิื่อขอความช่วยเหลือจากคอมมูนิตี้ด้วย

ความขัดแย้งของการตั้งชื่อ (Naming Conflicts)​

ความขัดแย้งของการตั้งชื่ออาจเกิดขึ้นเมื่อคำศัพท์ที่ใช้ใน FSD methodology ทับซ้อนกับคำศัพท์ที่ใช้ในธุรกิจ:

  • FSD#process vs process จำลองในแอปพลิเคชัน
  • FSD#page vs หน้า log
  • FSD#model vs โมเดลรถยนต์

ตัวอย่างเช่น นักพัฒนาที่เห็นคำว่า "process" ในโค้ด อาจเสียเวลาเพิ่มในการพยายามทำความเข้าใจว่าหมายถึง process ไหน การชนกันแบบนี้อาจขัดขวางกระบวนการพัฒนาได้

เมื่อ Glossary ของโปรเจกต์มีคำศัพท์ที่เฉพาะเจาะจงกับ FSD จำเป็นอย่างยิ่งที่จะต้องระมัดระวังเมื่อหารือคำศัพท์เหล่านี้กับทีมและผู้ที่ไม่เกี่ยวข้องทางเทคนิค

เพื่อสื่อสารกับทีมอย่างมีประสิทธิภาพ แนะนำให้ใช้คำย่อ "FSD" นำหน้าคำศัพท์ของ Methodology ตัวอย่างเช่น เมื่อพูดถึง process คุณอาจพูดว่า "เราเอา process นี้ไปไว้ที่ layer features ของ FSD ได้นะ"

ในทางกลับกัน เมื่อสื่อสารกับ Stakeholders ที่ไม่ใช่สายเทคนิค ควรจำกัดการใช้คำศัพท์ FSD และละเว้นการพูดถึงโครงสร้างภายในของ Codebase

ดูเพิ่มเติม​