หมายเหตุการย้ายบทความ: บทความนี้เผยแพร่ครั้งแรกเมื่อ 2024-09-29 บน Medium และย้ายมาเผยแพร่ในบล็อกนี้เมื่อ 2026-10-18 โดยคงเนื้อหาและบริบทเดิม ตัวอย่างโค้ดไม่ได้ผ่านการรันทดสอบใหม่
Photo by David Clode on Unsplash
สวัสดีครับทุกคน เรากลับมาลุยต่อ Part 2 ของสรุปหนังสือ Naming Things กันเลย Part 2 นี้จะยังไม่ได้ลงไปที่ Technical มากครับ ยังออกเป็นแนว Abstract เพื่อที่เราจะได้เข้าใจมุมมองกว้างๆก่อนที่จะไปลงรายละเอียดกันใน Part ต่อๆไป
ส่วนใครที่ยังไม่ได้อ่าน Part 1 — Introduction ตามย้อนกลับไปอ่านได้ตรงนี้นะครับ
Why is naming hard?
เออ นั่นสินะ ทำไมการตั้งชื่อมันถึงยากจัง? 😢
There are only two hard things in Computer Science: cache invalidation and naming things. — Phil Karlton
“มีแค่สองสิ่งที่ยากในโลก Computer Science นั่นก็คือการจัดการแคชกับการตั้งชื่อนี่แหละ”
Phil Karlton ได้กล่าวไว้เมื่อนานมาแล้ว ซึ่งเป็นประโยคที่ถูกหยิบมาคุยกันบ่อยเหมือนกันในกระทู้ด้านโปรแกรมมิ่งต่างๆ ขนาดลุง Martin Fowler ศาสดาของเราๆยังเอาประโยคด้านบนไปลง blog ตัวเองอะ ฮ่าๆ
ประโยคด้านบนที่กล่าวมานั้น ทำให้เราๆรู้สึกประหลาดใจอยู่เหมือนกัน คือเราพอรู้ว่าอันแรกนี่มันยากชัวร์ๆแหละ ไอ้เรื่องจัดการแคช ล้างแคช อะไรพวกนี้ แต่ส่วนอันหลังนี่สิ การตั้งชื่อมันควรจะเป็นเรื่องง่ายที่พวกเราควรทำกันได้อย่างสบายไม่ใช่เหรอ?
คำตอบลึกๆในใจของพวกเราคงเป็น “ไม่… ไม่สบายเลยเพื่อน” เราจะเห็นว่าจากโค้ดที่ผ่านๆตาเรามาเนี่ย มันมีร่องรอยของชื่อที่ไม่ดีอยู่มากมายและพอเราเห็นแบบนี้หรือเคยปวดหัวกับการคิดชื่อและตั้งชื่อของพวกนี้ เราจะยอมรับได้ทันทีว่า การตั้งชื่อมันยากจริงๆ และที่สำคัญการตั้งชื่อมันก็ถือว่าเป็นสกิลที่สำคัญจากอีกหลายๆสกิลที่เราต้องมีในงานด้าน Software Engineering ถือว่าเป็นความท้าทายนึงที่เราต้องเจอกันและฝึกฝนกันเลยทีเดียว
Dynamic, subjective requirements 🕸️
เราพบว่า การที่เราระบุชื่ออะไรบางอย่างเนี่ย มันเป็นการสื่อสารของแนวคิดที่เป็นไดนามิคไปสู่คนรับสารที่เป็นไดนามิคเหมือนกัน (คือจะบอกว่ามันมีความยืดหยุ่นเปลี่ยนแปลงได้) เราเองที่เป็นคนตั้งชื่อจำเป็นที่จะต้องเข้าใจในโดเมนหรือแนวคิดนั้นอย่างชัดเจน แต่ในบางครั้งเราเองก็พบว่าในการพัฒนาซอฟแวร์ในยุคสมัยใหม่ หรือแนวคิดใหม่ๆ บางทีมันก็ยังไม่มีคำจำกัดความที่ชัดเจน
ลองนึกภาพว่าเราเป็นคนเขียนโค้ดชุดหนึ่งแล้วให้เพื่อนๆในทีมเป็นคนรีวิว เพื่อนๆในทีมแต่ละคนนั้นจะมีประสบการณ์ที่ต่างกัน พื้นฐานที่ต่างกัน เพื่อนคนแรกอาจจะบอกว่า ชื่อตัวแปรนี้โอเคละ เข้าใจง่าย ชัดเจน แต่เพื่อนคนที่สองอาจจะบอกว่า ถ้าเป็นชื่อนี้อาจจะเข้าใจได้ง่ายกว่านะ นั่นหมายความว่า สิ่งที่ทำให้ชื่อนั้นดีหรือไม่ดีเนี่ย อาจไม่ได้มาจากการตั้งชื่อของเราแต่เพียงคนเดียว แต่ยังมีตัวแปรอีกหลายอย่าง จากหลายมุมมอง ความเข้าใจและประสบการณ์ที่แตกต่างกันของเพื่อนร่วมทีมอีกด้วย
การตั้งชื่อนั้นไม่ได้มีความยากแค่ในวงการ Software Engineering แต่หลายๆวงการก็เจอปัญหานี้เหมือนกัน เช่น การคิดชื่อแบรนด์ การตั้งชื่อผลิตภัณฑ์ต่างๆ มีผลการศึกษาหนึ่งได้ทดลองว่า ถ้าให้คนสองคนตั้งชื่อวัตถุเดียวกันจะพบว่ามีเพียง 7% — 18% เท่านั้น ที่จะตั้งชื่อวัตถุชิ้นนั้นแล้วได้ชื่อที่เหมือนกัน
Insufficient best practices and tooling 🛠️
หนังสือเล่มนี้บอกว่า การตั้งชื่อที่ดีในด้าน Software Engineering ยังมีตัวอย่างที่ดีและเครื่องมือยังไม่เพียงพอ ถ้าจะให้อธิบายเพิ่มเติมเค้าได้บอกว่า ด้วยความที่วงการ Software Engineering ไม่ได้มีองค์กรหรือหน่วยงานที่จะมาจัดการเรื่องมาตรฐานในการตั้งชื่อ คู่มือการตั้งชื่อที่ดีส่วนใหญ่นั้นจึงเกิดจาก Software Engineer หลายๆคน สรุปความคิดตัวเอง สรุปไอเดียของทีม ข้อดี-ข้อเสียของการตั้งชื่อแบบนั้นแบบนี้ลงใน blog หรือ website ซึ่งแนวทางการตั้งชื่อที่ดีของแต่ละบทความนั้น ก็อาจจะมีความแตกต่างกันออกไป
เมื่อเรากลับมามองต่อที่ตัวเครื่องมือที่จะมาช่วยในการตั้งชื่อ เรายิ่งกลับพบว่ามีน้อยมากๆหรือแทบจะไม่ค่อยมีเลย ถ้าจะพูดให้เห็นภาพมากขึ้นเราอาจลองมองเปรียบเทียบกับเครื่องมือจำพวกที่ช่วยสแกนหาช่องโหว่หรือเครื่องมืออื่นๆเราจะพบว่ามีจำนวนที่ต่างกันมากๆจริงๆ
ถึงแม้กระนั้น ณ ปัจจุบันก็มีการใช้ Deep Learning เข้ามาเป็น Tool ที่ช่วยในการตั้งชื่อ แต่ก็ต้องบอกว่ายังไม่เป็นที่แพร่หลายในวงการเท่าไหร่ หลายๆตัวก็ยังอยู่ในช่วงการพัฒนาอยู่ (หลังๆหลายคนก็อาจจะเคยให้ AI ช่วยกันมาบ้างแล้ว)
Photo by Shahadat Rahman on Unsplash
Short-term costs and long-term value 💰
เรามองต้นทุนระยะสั้นกับมูลค่าระยะยาวจากปัญหาการตั้งชื่อนี้ยังไง ในการตั้งชื่อนั้นต้นทุนของมันฟังเหมือนอาจจะเกิดขึ้นในระยะสั้นๆ นึกตามว่าเราตัดสินใจเลือกชื่อในหัวออกมาอย่างรวดเร็ว ซึ่งมันก็อาจจะได้ชื่อที่ไม่เหมาะสม (เป็นการเลือกชื่อระยะสั้น) หรือเราอาจใช้เวลาเพิ่มขึ้นอีกหน่อย เพื่อได้ไตร่ตรองว่าชื่อไหนเหมาะไม่เหมาะ (เป็นการเลือกชื่อระยะยาว) แต่เราจะพบว่า เราเองมักจะเลือกชื่อในระยะสั้นๆที่ใช้เวลาในการคิดน้อยกว่าซะเป็นส่วนใหญ่
เราเองเลยต้องชั่งน้ำหนักระหว่าง “ความสะดวกในระยะสั้น” กับ “ความชัดเจนและความสามารถในการบำรุงรักษาในระยะยาว” การตัดสินใจอย่างรวดเร็วอาจนำไปสู่วิธีตั้งชื่อที่ไม่ดี ซึ่งอาจทำให้เกิดความสับสนในอนาคต
ต้นทุนของการตั้งชื่อเลยจะเกี่ยวข้องกับประสบการณ์ ความเข้าใจในตัวโดเมนหรือปัญหาที่กำลังจะแก้ไขของพวกเราด้วย ทำให้การประเมินมูลค่าในระยะยาวนั้น เป็นเรื่องที่คลุมเครือและยากพอสมควร
Summary 📝
สรุปคือ ทักษะการตั้งชื่ออย่างมีประสิทธิภาพนั้น ถูกมองว่าเป็นทักษะอย่างหนึ่งที่นักพัฒนาทุกคนควรจะต้องฝึกฝนเพื่อการสื่อสารที่ชัดเจนในโค้ด เราจะพบว่าค่าใช้จ่ายและมูลค่าจากชื่อที่เราได้ตั้งขึ้นมานั้นมีความสำคัญเป็นอย่างมาก ซึ่งทักษะการตั้งชื่อนั้นจะส่งผลดีต่อคุณภาพซอฟต์แวร์และการทำงานร่วมกันในทีมของเรานั่นเอง
เดี๋ยวใน Part ต่อไป จะมาลงตัวอย่างโค้ดมากขึ้น ทุกคนจะได้เห็นภาพที่ชัดมากขึ้นครับ ว่าไอเดียหรือวิธีคิดในการตั้งชื่อที่ดีจะเป็นประมาณไหน
สุดท้ายนี้ ชอบกดไลท์ ใช่กดรีพอร์ท แฮ่
ขอบคุณทุกคนที่อ่านมาจนจบครับ
อยากให้ทุกคนสนุกกับการเขียนโค้ดครับ
Be Lazy & Happy Coding 🤤🖥🤗