สรุปหนังสือ Naming Things: The Hardest Problem In Software Engineering (Part 5— List of Principles: 3. Consistency)

หมายเหตุการย้ายบทความ: บทความนี้เผยแพร่ครั้งแรกเมื่อ 2024-11-22 บน Medium และย้ายมาเผยแพร่ในบล็อกนี้เมื่อ 2026-10-18 โดยคงเนื้อหาและบริบทเดิม ตัวอย่างโค้ดไม่ได้ผ่านการรันทดสอบใหม่

Photo by David Clode on Unsplash

สวัสดีครับทุกคน กลับมาฝึกวิชาตั๊กแตน เอ้ย ลุยกันต่อสำหรับ Part 5 ของสรุปหนังสือ Naming Things ซึ่งเราก็น่าจะผ่านตากันมาบ้างแล้วสำหรับ 4 Part แรก ใจนึงผมเองก็อยากสรุปสั้นๆ แต่ก็รู้สึกว่ามันจะย่อจนเกินไป เลยคิดว่าเป็นแนวนี้น่าจะดีแล้ว คือกึ่งแปลกึ่งสรุปไป ผมรู้สึกว่าเหนื่อยหน่อย แต่เนื้อหาดูมีสาระดีแถมผมก็ได้ฝึกสกิลด้วยครับ (หมายถึงตอนผมกลับมาอ่านเองก็จะได้เข้าใจได้ง่ายด้วย 555) อย่าพึ่งเบื่อหน้าปกตั๊กแตนกันนะครับ 🤣

แต่ก่อนอื่น เรามาทบทวนกันอีกรอบก่อนครับ ว่า List of principle ในหนังสือเล่มนี้มีอะไรบ้าง

List of principle

• Understandability: ชื่อที่ดีควรอธิบายสิ่งที่มันจะสื่อถึงได้ดี
• Conciseness: ชื่อที่ดีควรใช้แค่คำที่จำเป็นในการอธิบายตัวมันเอง
• Consistency: ชื่อที่ดีควรมีความสม่ำเสมอของรูปแบบในการตั้งชื่อ
• Distinguishability: ชื่อที่ดีควรแยกความแตกต่างจากชื่ออื่นๆได้ง่าย

ส่วนใครอยากทบทวน ก็สามารถย้อนกลับไปอ่านดึงความจำได้อีกรอบตามลิงก์ด้านล่างครับ

• Part 1 — Introduction
• Part 2 — Why is naming hard?
• Part 3 — List of Principles: 1. Understandability
• Part 4 — List of Principles: 2. Conciseness

ถ้ากลับไปทบทวนกันแล้ว เรามาลุยกันต่อเลยสำหรับเรื่อง Consistency ครับ

Consistency

Names should be used and formatted uniformly.
ชื่อควรถูกใช้และจัดรูปแบบอย่างสม่ำเสมอ

👆ในโค้ดก็เช่นกัน:P

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

1. Each concept should have only one name — แต่ละแนวคิดควรมีชื่อเพียงหนึ่งชื่อเท่านั้น
2. Similar concepts should have similar names — แนวคิดที่คล้ายกันควรมีชื่อที่คล้ายกัน
3. Similar names should have similar formats — ชื่อที่คล้ายกันควรมีรูปแบบที่คล้ายกัน

ตามหลักการย่อยด้านบนนั้น การที่เราไม่สนใจหลักการข้อใดข้อหนึ่งอาจทำให้อาจทำให้เราเองหรือทีมของเราเกิดความสับสน ลดความเข้าใจ ลดความง่ายของการจำ หรือแม้แต่ตอนที่เราแก้ไขหรือค้นหาโค้ดของเราครับ

ซึ่งปัญหานี้ก็อาจเกิดขึ้นได้จากหลายสาเหตุ เช่นการขาดความเอาใจใส่หรือจากการสื่อสารที่ไม่ดีในทีม ผมขอยกตัวอย่างง่ายๆเช่น โปรแกรมเมอร์ที่เข้ามาใหม่ ใช้ตัวแปรที่ชื่อว่า “Customer” สำหรับเรียกผู้ใช้งาน แต่ทว่าก่อนหน้านี้ เพื่อนๆในทีมต่างใช้คำว่า “User” กันหมด ทั้งๆที่ “Customer” และ “User” นั้นคือกลุ่มคนคนเดียวกัน

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

Rules

ในเรื่องกฎของ Consistency ก็จะมี 5 ข้อครับ เดี๋ยวเรามาไล่กันดูทีละข้อเลย

1. Obey popular naming conventions

หลักการข้อแรกก็คือ “ปฏิบัติตามข้อตกลงการตั้งชื่อที่เป็นที่นิยม” เราๆจะรู้ว่าทุกภาษาโปรแกรมมิ่งและเฟรมเวิร์คดังๆที่คนใช้กันเยอะๆ ล้วนจะมีข้อตกลงในการตั้งชื่อที่เป็นที่ยอมรับกันอย่างกว้างขวางในภาษาหรือเฟรมเวิร์คนั้นๆ ซึ่งการแหกกฎเหล่านี้อาจนำมาซึ่งผลเสียหลายๆอย่าง

เราลองนึกภาพตามว่า โปรแกรมเมอร์ที่คุ้นเคยกับภาษานั้นๆ อาจรู้สึกเอ๊ะยังไงหรือแปลกใจ เมื่อเจอการตั้งชื่อที่แปลกๆ หรือหลุดตีมของภาษานั้นๆไป นอกจากจะขัดตาหรือไม่คุ้นเคยแล้ว ยังต้องใช้ความพยายามในการอ่านและเหนื่อยเพิ่มมากขึ้นด้วย เนื่องจากเป็นสิ่งที่เราไม่คุ้นเคย

บ่อยครั้งที่เราจะเห็นการเบี่ยงเบนเกิดขึ้นเมื่อโปรแกรมเมอร์ที่คุ้นเคยกับภาษาหนึ่งไปทำงานกับอีกภาษาที่ไม่คุ้นเคย แล้วเอาวิธีการตั้งชื่อจากภาษาที่คุ้นเคยมาใช้กับอีกภาษา เช่น เราที่เขียน Java อยู่เป็นประจำ แล้วมาเขียน Python ผลก็คือเราอาจเผลอใช้รูปแบบของ Java ในการตั้งชื่อ method แบบ camelCase และขึ้นต้นด้วย get และ set สำหรับ getter และ setter ซึ่งไม่ใช่วิธีที่ถูกต้องในภาษา Python ลองดูจากตัวอย่างด้านล่างครับ

# Bad
class User:
  def __init__(self):
    self.name = None

  def self.get_name():
    return self.name

  def self.set_name(name):
    self.name = name

# Good
class User:
  def __init__(self, name):
    self.name = name

วิธีที่ดีที่สุดในการป้องกันปัญหานี้ก็คือการใช้คู่มือการเขียนโค้ด (style guide) และเครื่องมือตรวจสอบรูปแบบโค้ด (linter) ที่จะมีกฎที่พัฒนามาอย่างดีและเป็นที่ยอมรับ

การยึดมั่นในหลักการนี้จะช่วยให้โค้ดของเราและทีมมีความสอดคล้องกัน อ่านง่าย และเป็นมืออาชีพมากขึ้น ซึ่งจะช่วยให้ทีมทำงานร่วมกันได้อย่างมีประสิทธิภาพมากขึ้นด้วยครับ

2. Avoid synonyms

การตั้งชื่อที่ดีเราควรหลีกเลี่ยงการใช้คำที่มีความหมายเหมือนกัน หรือที่เรียกว่า “synonyms” การใช้หลายชื่อเพื่อหมายถึงแนวคิดเดียวกันนั้นไม่ใช่เรื่องดีเลย ยกตัวอย่างเช่น แนวคิดเวลาที่เราจะสื่อถึง “ผู้ใช้” เราไม่ควรใช้หลายๆลายชื่อที่มีความหมายเหมือนกันเป๊ะหรือคล้ายกัน อย่างเช่น “user” และ “end-user” เพราะมันจะสร้างความสับสนโดยใช่เหตุ ทั้งๆที่ทั้งสองชื่อคือกลุ่มคน คนเดียวกัน

หรือแม้แต่แนวคิดที่ใช้ในบริบทต่างๆ ก็ควรใช้ชื่อเดียวกันเสมอ เช่น ถ้าเราพูดถึง “ชื่อจริง” ของคน ก็ควรใช้คำว่า “first name” เหมือนกันหมด ไม่ว่าจะอยู่ในส่วนไหนของโค้ดก็ตาม ลองดูจากตัวอย่างด้านล่าง

# Bad
end_user = users[0]

class Person:
  def __init__(self, full_name, given_name, family_name):
    self.full_name = full_name
    self.given_name = given_name
    self.family_name = family_name

# Good
user = users[0]

class Person:
  def __init__(self, full_name, first_name, last_name):
    self.full_name = full_name
    self.first_name = first_name
    self.last_name = last_name

หรือการใช้คำที่มีความหมายเหมือนกันสำหรับแนวคิดทั่วไปก็ควรหลีกเลี่ยงเช่นกัน แม้ว่าจะส่งผลเสียน้อยกว่าการใช้คำที่มีความหมายเหมือนกันสำหรับแนวคิดเฉพาะทางก็ตาม อย่างเช่น ถ้าเราใช้ทั้ง “start” และ “initiate” เพื่อหมายถึงการเริ่มต้นกระบวนการ หรือ เริ่มต้ม เอ้ย เริ่มต้นอะไรสักอย่าง มันอาจทำให้ยากต่อการค้นหาและอาจสร้างความสับสนให้กับทีมหรือเราเองเมื่อกลับมาอ่านหรือแก้ไขได้

# Bad
onboarding_workflow.start()
offboarding_workflow.initiate()

# Good
onboarding_workflow.start()
offboarding_workflow.start()

ถ้าหากมีความแตกต่างที่มีความหมายระหว่างชื่อต่างๆ และความแตกต่างนั้นไม่ชัดเจน ก็ควรมีการบันทึกคำจำกัดความของชื่อเหล่านั้นไว้ด้วย หรือที่เราเรียกว่า การใช้คำศัพท์ควบคุม (controlled vocabulary) (อันนี้ไว้มาสรุปให้ฟังอีกทีนะครับ ว่ามันเป็นยังไง)

การที่เราใช้คำที่มีความหมายเหมือนกันสำหรับแนวคิดเดียวกัน มักจะสร้างความสับสนให้กับทุกคนที่ต้องทำงานกับชื่อเหล่านั้น ยกตัวอย่างเช่น โปรแกรมเมอร์ใหม่ในทีมอาจจะคิดว่าแต่ละชื่อหมายถึงแนวคิดที่แตกต่างกันออกไป พวกเขาอาจเข้าใจผิดว่า “end-user” เป็นกลุ่มย่อยของแนวคิด “user” ที่มีความหมายกว้างกว่า นั่นหมายความว่า เมื่อโปรแกรมเมอร์ใหม่พบว่าชื่อเหล่านี้ซ้ำซ้อนกัน พวกเขาจะต้องใช้ความพยายามทางความคิดเพื่อแก้ไขความเข้าใจเดิมของตนเองก่อน แบบเอ๊ะในใจ สรุป “user” กับ “end-user” นี่เป็นคนเดียวกันใช่ไหมหรือไม่ใช่นะ? ซึ่งเป็นต้นทุนที่ไม่จำเป็นและสร้างประสบการณ์ที่ไม่ค่อยดีเท่าไหร่ครับ

3. Avoid abbreviations

หลักการข้อที่สามนี้เราน่าจะคุ้นๆกันมาบ้างแล้วจาก part ก่อนๆคือ “หลีกเลี่ยงการใช้คำย่อ” ซึ่งการใช้คำย่อหรือตัวย่อนอกจากจะส่งผลต่อความเข้าใจได้แล้ว ยังมีผลกระทบต่อความสม่ำเสมออีกด้วย คือเมื่อไหร่ก็ตามที่มีการใช้คำย่อ มันมักจะสร้างความไม่สอดคล้องในลักษณะเดียวกับการใช้คำพ้องความหมาย กล่าวคือ:

1. สร้างความสับสนให้กับผู้อ่านใหม่ (เช่น “AP ย่อมาจากอะไร?”)
2. ลดความสามารถในการค้นหา
3. สร้างภาระทางความคิดอย่างต่อเนื่อง (AP… AP อะไรรรรรร๊)

อย่างไรก็ตาม บางครั้งชื่อเต็มของแนวคิดบางอย่างอาจยาวมากจนการใช้บ่อยๆ อาจเป็นเรื่องยุ่งยาก ลองนึกถึงคำว่า CRM ถ้าใช้ชื่อเต็มก็ Customer Relationship Management คืออย่างยาว ในกรณีเช่นนี้ การใช้คำย่ออาจมีประโยชน์ แต่ทั้งนี้ทั้งนั้น เราเองควรคำนึงถึงผลกระทบต่อความกระชับ ความเข้าใจได้ และความสม่ำเสมออีกด้วยครับ

# Bad
ap
org

# Good
accounts_payable
organization

ดังนั้น การใช้คำย่อที่ดี เราควรจะดูข้อควรระวังเหล่านี้ด้วย

1. ใช้คำย่อเฉพาะเมื่อจำเป็นจริงๆ เท่านั้น
2. ตรวจสอบให้แน่ใจว่าคำย่อนั้นเป็นที่เข้าใจกันดีในทีม
3. อธิบายความหมายของคำย่อ เมื่อใช้ครั้งแรกในเอกสารหรือโค้ด
4. พยายามใช้คำย่อเดียวกันอย่างสม่ำเสมอทั่วทั้งในโปรเจค

การระมัดระวังในการใช้คำย่อจะช่วยรักษาความสม่ำเสมอของโค้ดและเอกสาร ทำให้ง่ายต่อการอ่าน เข้าใจ และบำรุงรักษาในระยะยาว ซึ่งเป็นสิ่งสำคัญมากสำหรับการพัฒนาซอฟต์แวร์ที่มีคุณภาพ

4. Use similar names for similar concepts

การตั้งชื่อที่ดีควรใช้ชื่อที่คล้ายกันสำหรับแนวคิดที่คล้ายกัน ในโปรเจคของเราส่วนมาก มักจะมีโค้ดที่ส่วนต่างๆ บางส่วนมีแนวคิดที่คล้ายกัน เช่น คลาสโมเดลที่คล้ายกับคลาสโมเดลอื่นๆ หรือคลาสหลายๆ คลาสที่มีการดึงข้อมูลจาก API ภายนอก

ซึ่งชื่อที่เราตั้งให้กับแนวคิดและโค้ดที่คล้ายกันเหล่านี้ ก็ควรมีความคล้ายคลึงกันด้วยตัวอย่างเช่น ถ้าเรามี method หนึ่งที่ไปดึงข้อมูล Person และอีก method หนึ่งที่ไปดึงข้อมูล Company จาก API ข้างนอก คำกริยาที่ใช้ในชื่อของ method เหล่านี้ก็ควรเหมือนกันครับ คือทั้งสอง method ส่ง HTTP request ไปเหมือนกัน

# Bad
# Both of these methods make an HTTP request
Person.fetch(person_id)
Company.get(company_id)

# Good
# Both of these methods make an HTTP request
Person.fetch(person_id)
Company.fetch(company_id)

5. Use consistent antonyms

กฎข้อที่ห้าที่เป็นข้อสุดท้ายของ Consistency ก็คือ เราควรใช้คำตรงข้ามกันอย่างสม่ำเสมอ ซึ่งเป็นอีกหนึ่งวิธีสำคัญในการรักษาความสอดคล้องของโค้ด

ตัวอย่างเช่น คำว่า “add” (เพิ่ม) ก็จะมีคำตรงข้ามคือ “remove” (ลบ) ชื่อที่ใช้สำหรับคำตรงข้ามเหล่านี้ควรมีความสอดคล้องกัน หากเป็นแนวคิดทั่วไปที่ไม่เฉพาะเจาะจงกับโดเมนใดโดเมนหนึ่ง ควรใช้ชื่อที่เป็นที่นิยมใช้กันมากที่สุดสำหรับแนวคิดเหล่านั้น ส่วนใหญ่แล้วในภาษาโปรแกรมมิ่งนั้นๆ มักจะมีคู่ของชื่อที่ใช้เป็นคำตรงข้ามกันอย่างแพร่หลาย เราเองก็ควรใช้ชื่อเหล่านั้นเหมือนกัน เพื่อให้เกิดความสอดคล้องกับมาตรฐานที่เป็นที่ยอมรับในภาษานั้นๆ ซึ่งหากทุกอย่างเท่าเทียมกัน เราก็ควรใช้คำตรงข้ามที่มีรากศัพท์คล้ายกัน อย่างเช่นตัวอย่างด้านล่างครับ

# Bad
add/uninstall
install/remove

# Good
add/remove
install/uninstall

ซึ่งถ้าเราสนใจในเรื่องของคำตรงข้าง หรือ Antonyms เราสามารถลองค้นหาต่อในกูเกิ้ลเพิ่มเติมด้วยคำว่า Common Antonyms ก็ได้ครับ ส่วนใหญ่จะเป็นคำที่เราคุ้นๆกันแล้วประมาณนึง

Conclusion

จากกฎทั้งหมดของเรื่อง Consistency ที่เราอ่านมานั้น เราจะเข้าใจได้ว่า การตั้งชื่อที่มีความสม่ำเสมอ สอดคล้องและเข้าใจง่ายนั้น จะช่วยสร้างความเป็นระเบียบในโค้ดของเรา ซึ่งจะส่งผลดีไปถึงคุณภาพของโค้ดเราโดยตรงอีกด้วย ผลลัพธ์ที่ได้นี้จะช่วยเราลดเวลาในการพัฒนา การบำรุงรักษาและทำให้การทำงานร่วมกันในทีมมีคุณภาพมากขึ้นในระยะยาวอีกด้วยครับ

และเราก็จบกันไปอีกหนึ่งหลักการสำหรับหนังสือ Naming Things ไว้ part หน้าเราจะมาลุยกันต่อกับหลักการสุดท้าย นั่นคือ Distinguishability — ที่หมายถึงความแตกต่าง ไว้มาลงรายละเอียดกันอีกทีครับ ว่ามันจะเป็นยังไง

สุดท้าย ชอบกดไลท์ ใช่กดรีพอร์ทเหมือนเดิมครับ 55+
ขอบคุณทุกคนที่อ่านมาจนจบครับ

อยากให้ทุกคนสนุกกับการเขียนโค้ดครับ
Be Lazy & Happy Coding 🤤🖥🤗