หมายเหตุการย้ายบทความ: บทความนี้เผยแพร่ครั้งแรกเมื่อ 2024-09-22 บน Medium และย้ายมาเผยแพร่ในบล็อกนี้เมื่อ 2026-10-18 โดยคงเนื้อหาและบริบทเดิม ตัวอย่างโค้ดไม่ได้ผ่านการรันทดสอบใหม่
Photo by David Clode on Unsplash
สวัสดีครับพี่ๆ เพื่อนๆ น้องๆ ทุกคน 🙏 … Helloooooo ห่างหายไปนานจริงๆกับการเขียน blog ฮ่าๆ วันนี้เป็นไข้ไม่สบายเลยรู้สึกว่าอยากจะแชร์อะไรที่มันพอมีสาระให้กับทุกคนได้บ้าง
คือว่าผมมีโอกาสได้ไปเจอหนังสือดีๆเล่มหนึ่งที่กดซื้อมา 9.99$ มั้งเมื่อประมาณต้นปี หนังสือเล่มนี้มีชื่อว่า Naming Things: The Hardest Problem In Software Engineering ของ Tom Benner หน้าปกเหลืองๆเล่มเล็กๆน่ารักแต่ข้างในอัดแน่นด้วยสาระล้วนๆ เพราะ Tom เอาประสบการณ์ส่วนตัวจากงาน รวมทั้งเทคนิคและสาระสำคัญต่างๆที่เป็นวิธีการตั้งชื่อของเหล่าศาสดาในวงการมาย่อยให้เราได้เข้าใจง่ายขึ้นอีกที
ผมรู้สึกว่ามันเป็นหนังสือที่ดีเล่มนึงที่จะช่วยในการเขียนโปรแกรมของเรานั้นดีขึ้นได้มากๆ เนื้อหาในเล่มเล่าถึงประโยชน์ ผลกระทบและเทคนิคหลายๆอย่างของการตั้งชื่ออะไรต่างๆตอนที่เราเขียนโปรแกรมได้เป็นอย่างดี จนผมรู้สึกว่าน่าจะหาโอกาสมาเขียนแชร์ความรู้ที่ได้ไปอ่านมาสักหน่อย… (รอโอกาสนานมากกกก เจอต้นปี มาสรุปตอนท้ายปี ฮ่าๆ)
วันนี้เลยถือโอกาสอยากจะแชร์สรุปหนังสือ Naming Things ไว้ให้สำหรับคนที่สนใจอยากจะพัฒนาทักษะในการเขียนโปรแกรมของตัวเองหรือคนที่เคยรู้สึกปวดหัวกับเรื่องการตั้งชื่อนู่นนี่นั่นเวลาเขียนโปรแกรม ได้เข้าใจว่า “การตั้งชื่อ” นั้นสำคัญยังไง แล้วทำไม ทำไม ทำไม มันถึง “ยากจัง”
เกริ่นอะไรยาวจังเลยเนี่ย… งั้นไปลุย Part 1 กันเลยครับ 🚀
Introduction
อย่างที่เราๆชาว Dev ทราบกัน การตั้งชื่อพวก class, variable, function อะไรต่างๆพวกนี้ จริงๆแล้วเป็น “งานหลัก” อย่างนึงที่เราต้องทำทุกครั้งเวลาเราเขียนโปรแกรม ซึ่งหลายๆครั้งเราเองกลับพบว่า “การตั้งชื่อ” ของพวกนี้เนี่ย มันกลับเหมือนไม่ค่อยถูกใส่ใจเท่าไหร่และทำไมมันถึงได้ยากจัง
หนังสือเล่มนี้ได้กล่าวสั้นๆเกี่ยวกับ codebase ไว้สองแบบว่า
A codebase with good names is a joy
โค้ดที่มีการตั้งชื่อดีๆ ถือว่าเป็นความสุขอย่างนึง เราลองนึกภาพเรากำลังอ่านโค้ดที่อ่านเข้าใจง่าย สื่อสารตรงไปตรงมา ชัดเจน อ่านปุ๊บ เข้าใจปั๊บ อ่านปั๊บ เข้าใจปุ๊บ แฮ่
A codebase with bad names is drudgery
ส่วน โค้ดที่มีการตั้งชื่อแย่ๆเนี่ย ถือว่าเป็นความน่าเบื่อหน่ายอย่างนึง เคสนี้เราอาจนึกภาพได้ไม่ยากเลย อ่านดูกว่าจะเข้าใจแต่ละบรรทัด อ่านไปกำหมัดไป ต้องเดาจากการทำงานข้างใน ต้องมาเสียเวลาถามตัวเองหรือเพื่อนในทีมว่าเขียนอะไรไป ซึ่งพวกนี้มันทำให้เราๆเสียพลังงานโดยไม่จำเป็นกันไปพอสมควร
และหนังสือเล่มนี้เอง จะพาเราไปเข้าใจว่า ทำไมกะเรื่องแค่การตั้งชื่อนู่นนี่ตอนเขียนโปรแกรมที่ฟังดูเหมือนจะธรรมดาๆที่เราต้องทำมันทุกครั้ง มันสำคัญมากแค่ไหน ผลกระทบแค่จากการตั้งชื่อส่งผลยังไง รูปแบบและวิธีการที่ดีควรเป็นแบบไหน หนังสือเล่มนี้จะช่วยให้ทุกคนได้เข้าใจและลองนำไปปรับใช้กันครับ
Why is naming important?
ลุง Martin Fowler ศาสดาฝั่ง Software Engineering ของเราๆนั้น เคยกล่าวไว้ในหนังสือ Refactoring ว่า
Your code is for a human first and a computer second.
โค้ดของเรานั้นมีไว้ให้สำหรับมนุษย์เป็นอันดับแรก ส่วนคอมพิวเตอร์ให้เป็นอันดับสอง — คมกริ๊บบบบบบบ
ในหลายช่วงเวลาที่ผ่านมา เหล่าโปรหรือศาสดาฝั่ง Software Engineering หลายๆคนได้เน้นย้ำถึงความสำคัญของการตั้งชื่อ เราจะพบได้ว่ามีหนังสือดีๆหลายเล่ม ที่จะมีการกล่าวถึงความสำคัญหรือเทคนิคการตั้งชื่อ ยกตัวอย่างเช่น
- Clean Code ของ Robert C.Martin — หัวข้อ Variable Names
- Code Complete ของ Steve McConnell: หัวข้อ Meaningful Names
- The Pragmatic Programmer ของ Andrew Hunt, David Thomas: หัวข้อ Naming Things
- The Practice of Programming ของ Brian W.Kernighan, Rob Pike) — หัวข้อ Names
- Refactoring ของ Martin Fowler — หัวข้อ Mysterious Name, Rename Variable, Rename Field
จากลิสต์ของหนังสือด้านบน เราจะพบว่าหนังสือที่ดังๆในเรื่องการเขียนโปรแกรมหลายเล่มจะให้ความสำคัญกับการตั้งชื่อถึงขั้นแยกเป็นอีกหัวข้อเลยทีเดียว
จากการศึกษาทางชาติพันธุ์วิทยาได้เรียนรู้ว่า นักเรียนหรือเหล่า Dev มืออาชีพตัวท๊อปทั้งหลาย จะมอง การตั้งชื่อที่ดีว่าเป็นสิ่งที่ “จำเป็น” และ “สำคัญ” ซึ่งคนเหล่านี้จะให้ความสำคัญน้อยมากกับ comment ที่เอาไว้อธิบายตัวโค้ด เพราะพวกเขามองว่า การตั้งชื่อในโค้ดที่ดี ก็เหมือนเป็นการอธิบายและเป็นเครื่องมือในการช่วยทำความเข้าใจตัวในตัวโปรแกรมอยู่แล้ว
ซึ่งในปัญหาด้าน Software Engineering นั้น เราจำเป็นที่จะต้องเข้าใจปัญหาและผลกระทบที่จะตามมาก่อน เพราะว่าความเข้าใจนี้เอง จะนำพาเราไปหาวิธีการแก้ปัญหาที่ถูกและเหมาะสมที่สุด (ไม่เข้าใจแล้วจะแก้ปัญหายังไงอะเนาะ 😅)
Understandable code
ทำไมการตั้งชื่อที่เข้าใจได้ง่ายมันดีกว่า? เขียนๆไปมันก็ทำงานได้เหมือนกันหนิ?
การตั้งชื่อที่ดีจะช่วยให้เราเข้าใจการทำงานของโปรแกรมมากขึ้น พอเข้าใจมากขึ้น เวลาเกิดปัญหาหรือจะแก้ไขอะไรมันก็จะมีประสิทธิภาพมากขึ้น สะดวกและง่ายต่อการดูแล ทุกสิ่งจะดีขึ้นตามลำดับเป็นลูกโซ่ก็ว่าได้
Good naming -> Understandable Code -> Efficient maintenance
ชื่อที่ดี -> โค้ดเข้าใจง่าย -> ดูแลสบาย
ในข้อความนึงในหนังสือเขียนไว้ว่า “Codebases are knowledge bases”
ประโยคนี้ไม่เกินจริงเลย โค้ดที่เราๆเขียนกันนั้น พอมองให้ลึกลงไปตัวโค้ดเองนั้นเป็นแหล่งเก็บความรู้อย่างหนึ่ง เก็บว่าเค้าทำงานยังไง ทำงานแบบไหน โค้ดจุดนี้แก้ปัญหาอะไร ยิ่งเรามีโค้ดที่เข้าใจง่ายแค่ไหน ก็แปลว่าเรามีแหล่งความรู้ที่ดีเท่านั้น ถ้าเราหรือคนอื่นๆอ่านแล้วเข้าใจได้ง่าย ก็จะช่วยให้สามารถซึมซับความรู้ได้ไวจากแหล่งความรู้ชนิดนี้ พอจะเอาไปใช้งานหรือปรับเปลี่ยนก็จะช่วยให้สะดวก รวดเร็ว มีความมั่นใจมากขึ้นในการแก้ปัญหาด้าน Software Development
คำถามต่อมาก็คือ เราสามารถวัดค่าความสำคัญของโค้ดที่เข้าใจง่ายได้หรือไม่? จากการศึกษาค้นพบว่า ต้นทุนประมาณ 60% — 80% ของ software development life cycle นั้นไปตกอยู่ที่กระบวนการบำรุงรักษา (maintenance) ราวๆ 40% — 60% จะเป็นช่วงที่เราใช้เวลาทำความเข้าใจก่อนมีสร้างหรือแก้ไข และอีกประมาณ 25% — 50% เป็นเวลาที่เราทำความเข้าใจเกี่ยวกับตัว software โดยเฉพาะ ถึงแม้ตัวเลขที่กล่าวมาอาจจะขึ้นอยู่กับความซับซ้อนของแต่ละโปรแกรม แต่อย่างน้อยเราก็ได้เห็นว่า จุดสำคัญของการมีโค้ดที่เข้าใจง่ายนั้น มีผลกระทบมากแค่ไหน
ยกตัวอย่างโปรแกรมหนึ่งตัว เราจะพบว่าการตั้งชื่อ class, variable, function และตัวแปรอื่นๆจะมีความสำคัญต่อความเข้าใจในตัวโค้ดคิดเป็นสัดส่วนประมาณ 70% เลยทีเดียว นั่นหมายความว่าการตั้งชื่อสิ่งพื้นฐานเหล่านี้ให้ดีนั้น สามารถส่งผลให้เกิดความเข้าใจในโค้ดได้ดีขึ้นกว่าเดิม
การศึกษาเกี่ยวกับความสำคัญของการตั้งชื่อนั้น จะขึ้นอยู่กับ 3 อย่าง
- Comprehension — ความเข้าใจ
ความสามารถของเดฟที่จะเข้าใจลอจิค โครงสร้างและจุดประสงค์ต่างๆของโค้ด - Recall — การรำลึกถึง
ความสามารถของเดฟที่สามารถจดจำหรือนึกถึงลอจิค โครงสร้างหรือจุดประสงค์ต่างๆของโค้ดที่อาจจะเคยเขียนไปแล้ว - Defect resolution time — เวลาที่ใช้แก้ไขข้อบกพร่อง
ระยะเวลาระหว่างที่เดฟเริ่มแก้ไขข้อบกพร่องนั้นๆจนถึงแก้ไขเสร็จ
ยกตัวอย่างการแก้ไขโค้ดสักจุด การแก้ไขโค้ดนั้นหมายความว่าเราเองจำเป็นที่จะต้องเข้าใจการทำงานของมันเสียก่อน รู้ว่าถูกจึงรู้ว่าผิด… นั่นหมายความว่า ถ้าโค้ดที่กำลังจะแก้นั้นเข้าใจง่ายหรือไปช่วยให้เรานึกถึงลอจิคได้ทันที ก็จะช่วยเราไม่ต้องกลับไปทำความเข้าใจลอจิคใหม่ทั้งหมด
เพื่อให้เห็นภาพมากขึ้น ขอยกตัวอย่างผลการศึกษาเกี่ยวกับ Comprehension, Recall และ Defect resolution time งานศึกษาชิ้นนี้ทดสอบโดยการให้โปรแกรมเมอร์ ได้ทำการแก้บั๊กในโค้ด โดยโค้ดนั้นแบ่งออกเป็น 2 ชุด
- ชุดที่ 1 จะเป็นโค้ดที่ส่วนใหญ่เป็นการใช้คำ “คำเดียว” (single-word) ในการเขียน class, variable, function ต่างๆ และ
- ชุดที่ 2 จะเป็นโค้ดที่ส่วนใหญ่ใช้คำ “หลายคำ” (multi-word) ในการเขียน class, variable, function ต่างๆ
ผลการศึกษาชิ้นนี้พบว่า โปรแกรมเมอร์ที่ได้แก้ไขบั๊กในโค้ดทั้งสองชุดนั้น จะแก้บั๊กชุดที่ 2 ที่ใช้ multi-word ในการเขียนได้เร็วขึ้นถึง 14% ซึ่งความเร็วในการแก้ไขนี้นั้น เกิดจากการที่โปรแกรมเมอร์เองไม่ต้องคอยเลื่อนกลับไป กลับมา ทำให้อ่านโค้ดได้ลื่นไหลไม่สะดุด แก้ไปแบบไม่กำหมัดเท่าไหร่และยังมีผลการศึกษาอีกชิ้นหนึ่งที่พบว่า เมื่อมีการใช้คำที่มีความหมายแทนการใช้คำย่อหรืออักษรย่อนั้น จะทำให้โปรแกรมเมอร์แก้ไขบั๊กได้เร็วเพิ่มขึ้นถึง 19% เลยทีเดียว
Productivity and happiness
จริงๆแล้วผลของการตั้งชื่อต่างๆ เราอาจวัดได้ง่ายในช่วงเวลาสั้นๆ น่าเสียดายที่การศึกษาผลของการตั้งชื่อในระยะยาวนั้นยังถือว่ามีน้อย แต่อย่างไรก็ตาม ถ้าเรายกการใช้ภาษาเป็นตัวอย่างในการเขียนโค้ด ตัวภาษาเองจะมีอิทธิพลต่อวิธีคิด วิธีสื่อสารในขั้นตอนการพัฒนาซอฟแวร์ ลองนึกภาพว่าถ้าเรามีการใช้ภาษาและสื่อสารได้ดี จุดนี้จะส่งผลกระทบต่อประสิทธิภาพการทำงานและความสุขได้แค่ไหน
ผลกระทบเรื่องประสิทธิภาพและความสุขในการทำงาน เราสามารถยกตัวอย่างให้เห็นชัดขึ้นได้ง่ายๆอย่างเช่นในกรณีที่มีโปรแกรมเมอร์คนใหม่เข้ามาร่วมทีม ลองนึกภาพเราเองที่เป็นคนเข้ามาใหม่ แล้วมาเจอสภาพโค้ดที่ทำความเข้าใจยาก เราก็อาจจะเริ่มรู้สึกไม่ค่อยโอเคเท่าไหร่ พี่ๆทำอะไรไว้ครับเนี่ยยยย เพราะเราเองต้องใช้เวลาในการทำความเข้าใจโค้ดนั้นมากขึ้น ซึ่งผลกระทบเหล่านี้ก็จะส่งผลกระทบต่อต้นทุนของ software development life cycle ตามมาอีก
หรืออีกตัวอย่างอาจจะใกล้ตัวมากขึ้นก็ได้ อย่างเช่นโค้ดจุดนี้เป็นโค้ดที่เราเขียนเอง แต่กลับว่าพอเวลาผ่านไปสักพักแล้วเราต้องกลับมาปรับปรุงหรือแก้ไข เราเองดันต้องใช้เวลาทำความเข้าใจมากเกินความจำเป็น เนื่องจากตัวโค้ดเองนั้นสื่อสารได้ไม่ชัดเจนหรือเข้าใจได้ยากเกินไป
ดังนั้น ต้นทุนที่เกิดจากการตั้งชื่อที่ไม่ดีนั้นอาจมหาศาล เนื่องจากอาจไม่ใช่โปรแกรมเมอร์คนเดียวในทีมที่ไม่เข้าใจ อาจเป็นหลายๆคนในทีม ตามสมการด้านล่าง
totalCost(engineers) = minimum(recallCost(engineers), comprehensionCost(engineers) * comprehensionCount(engineers))อย่างที่เราทราบกัน หลายๆ codebase นั้นมีอายุมานานมาก ในนั้นจะมีทั้งชื่อ class, variable, function ต่างๆ และ เมื่อเวลาผ่านไป codebase นั้นอาจโตขึ้นได้เรื่อยๆ จำนวนโค้ดที่เพิ่มมากขึ้น ณ จุดนี้ต้นทุนความเข้าใจของตัว codebase เองก็จะสูงขึ้นมาด้วย เช่นต้นทุนความเข้าใจที่มาจากการสื่อสาร การตั้งชื่อที่ไม่ดีอาจทำให้โปรแกรมเมอร์คนหนึ่งอธิบายให้อีกคนเข้าใจได้ยากขึ้น ผลที่ตามมาก็จะเกิดการแก้ไขที่ยากขึ้นและเกิดค่าใช้จ่ายต่างๆที่ไม่จำเป็นตามมา
จากที่กล่าวมาด้านบน ปัญหาของการตั้งชื่อที่ไม่ดีนี้จะส่งผลกระทบต่อความสุขและประสิทธิภาพของโปรแกรมเมอร์อย่างแน่นอน แบบแค่เห็นโค้ดก็ปวดประสาทแล้วอะไรประมาณนี้
Photo by JESHOOTS.COM on Unsplash
Career growth
จากที่เราเห็นผลกระทบด้านประสิทธิภาพการทำงานและเรื่องของความสุขในการทำงานแล้ว การที่เราฝึกฝนตั้งชื่อให้ดียังเป็นการส่งผลที่ดีในด้านของการเป็นผู้นำ การตั้งชื่อที่ดีนั้นช่วยให้เราได้ฝึกฝนและสามารถเข้าใจระบบได้อย่างลึกซึ้งมากขึ้น ทำให้มีโอกาสที่องค์กรจะเลือกเราเป็นผู้นำทีมในการพัฒนาตัวโค้ด
เพราะการที่เราตั้งชื่อต่างๆได้ดีนั้นสามารถส่งผลกระทบที่ดีต่อเพื่อนร่วมทีมได้ในทางตรง เมื่อเพื่อนร่วมทีมได้อ่านวิธีการตั้งชื่อรวมถึงวิธีการเขียนที่ดีก็เกิดความเคารพหรือแรงจูงใจ พร้อมทั้งยังสามารถขอความคิดเห็นหรือคำแนะนำจากเราได้ ซึ่งผลลัพธ์เหล่านี้ยังช่วยลดเวลาที่เสียไปของเพื่อนร่วมทีมในการทำความเข้าใจในโค้ดที่เราเขียน หรือเราเองก็ไม่ต้องคอยอธิบายการทำงานให้เพื่อนร่วมงานฟัง
ทั้งนี้ทั้งนั้น การเลือกตั้งชื่อที่ดีในกรณีที่ทำงานเป็นทีมควรเป็นการเลือกชื่อที่เข้าใจได้ง่ายและมีแนวทางหรือข้อตกลงเดียวกันทั้งทีม หรือที่เราๆอาจเรียกกันว่า Code Convention นั่นเอง
Summary
จากที่กล่าวมาทั้งหมดด้านบนนั้น เราจะพบว่าการตั้งชื่อนั้นมีผลกระทบอย่างมาก มาก มาก ตั้งแต่การทำความเข้าใจในตัวโค้ดไปจนถึงความสุขและประสิทธิภาพในการทำงานทอดยาวไปจนถึงความก้าวหน้าในการทำงานของเราเลยทีเดียว
มันชัดมากๆว่า “การตั้งชื่อ” นั้นมันสำคัญแค่ไหน ทำไมพวกเรายังรู้สึกว่ายังเจอปัญหานี้กันอยู่เป็นประจำ?
เดี๋ยวใน part ต่อๆไป ผมจะมาช่วยเล่าต่อทั้งด้าน Abstract + Technical ว่า ทำไมกับแค่การตั้งชื่อเนี่ย ทำไมมันยากจัง ทำไมมันถึงเรียกว่าเป็น Hardest Problem In Software Engineering
สุดท้ายนี้ ชอบกดไลท์ ใช่กดรีพอร์ท แฮ่
ขอบคุณทุกคนที่อ่านมาจนจบ
อยากให้ทุกคนสนุกกับการเขียนโค้ดครับ
Be Lazy & Happy Coding 🤤🖥🤗