- ใน วัฒนธรรมการพัฒนาซอฟต์แวร์ สมัยใหม่ ชื่อของโปรเจ็กต์และไลบรารีกำลังเต็มไปด้วย คำที่ตั้งขึ้นแบบสุ่ม ซึ่งไม่เกี่ยวข้องกับหน้าที่การทำงาน
- ในอดีต ชื่ออย่าง grep, awk, sed, FORTRAN, COBOL อธิบายหน้าที่หรือจุดประสงค์ได้โดยตรง แต่ปัจจุบันกลับมี ชื่อที่ไร้ความหมาย แพร่หลาย
- แนวโน้มนี้เร่งตัวขึ้นพร้อมกับการขยายตัวของ GitHub และวัฒนธรรมสตาร์ทอัพ จนความเชื่อมโยงระหว่างชื่อกับฟังก์ชันขาดออกจากกันโดยสิ้นเชิง
- ต้นทุนด้านความเข้าใจและภาระทางการรับรู้ สูงขึ้น ทำให้นักพัฒนาต้องค้นหาข้อมูลซ้ำ ๆ โดยไม่จำเป็นเพื่อทำความเข้าใจบทบาทของเครื่องมือแต่ละตัว
- บทความนี้เรียกร้องให้ ฟื้นคืนหลักการตั้งชื่อที่ชัดเจนและยึดหน้าที่เป็นศูนย์กลาง และเน้นย้ำว่าเครื่องมือทางเทคนิคควรให้ความสำคัญกับ ความชัดเจนและความเป็นมืออาชีพ มากกว่าแบรนด์
การเปลี่ยนแปลงของธรรมเนียมการตั้งชื่อซอฟต์แวร์
- Richard Stallman กล่าวในงาน EmacsConf ปี 2022 ถึงความสำคัญของ “ชื่อที่จำง่าย” พร้อมย้ำว่าชื่อแพ็กเกจควรบอกให้รู้ว่ามันทำอะไร
- ระบบนิเวศของ Emacs รักษาธรรมเนียมการตั้งชื่อแบบอิงหน้าที่มาโดยตลอด เช่น dired (ตัวแก้ไขไดเรกทอรี), eshell (เชลล์ของ Emacs)
- แต่ผู้พัฒนายุคใหม่มีแนวโน้มจะตั้งชื่อเครื่องมือด้วย คำนามสุ่ม สิ่งมีชีวิตในตำนาน ตัวละครสมมติ และอื่น ๆ
- ซึ่งในสาขาเทคนิคอื่น ๆ จะถูกมองว่าเป็น การขาดความเป็นมืออาชีพ
ปัญหาของชื่อที่ไร้ความหมาย
- ตัวอย่างเช่นชื่อเครื่องมืออย่าง “Viper”, “Cobra”, “Melody”, “Casbin”, “Asynq” ไม่ช่วยให้เดาหน้าที่ยังไงก็ไม่ได้
- ผู้เขียนเล่าถึงประสบการณ์ที่ต้อง ค้นหาในอินเทอร์เน็ต เพื่อทำความเข้าใจคำอธิบายโครงสร้างพื้นฐานของเพื่อน
- ในสาขาวิศวกรรมอื่น ๆ ชื่อมักอธิบายโครงสร้างหรือหน้าที่
- ตัวอย่าง: Golden Gate Bridge, Hoover Dam, I-beam, butterfly valve ล้วนสื่อรูปทรงหรือบทบาทได้ชัดเจน
- เช่นเดียวกับ ระบบการตั้งชื่อ IUPAC ในเคมี ที่กำหนดให้ชื่อชี้ไปยังวัตถุเพียงหนึ่งเดียวอย่างแม่นยำ
- ตัวอย่าง: 2,2,4-trimethylpentane หมายถึงโมเลกุลเดียวเท่านั้น และไม่มีใครเรียกมันแบบสุ่มว่า “Steve”
กฎการตั้งชื่อในอดีตและความขาดตอนในปัจจุบัน
- ในช่วงทศวรรษ 1980 ตัวย่อที่อิงหน้าที่อย่าง grep, awk, sed, cat, diff เป็นกระแสหลัก
- ชื่อภาษาโปรแกรมอย่าง FORTRAN, COBOL, BASIC, SQL, Lisp ก็สะท้อนจุดประสงค์ของมันเช่นกัน
- หลังปี 2010 เป็นต้นมา การแพร่กระจายของ ชื่อที่ไร้ความหมาย เริ่มเด่นชัด
- บางชื่ออย่าง MongoDB ยังพอมีความเชื่อมโยงทางหน้าที่หรือรากศัพท์อยู่บ้าง แต่หลังจากนั้นชื่อที่ไม่มีความหมายก็เพิ่มขึ้นอย่างรวดเร็วท่ามกลาง GitHub และวัฒนธรรมสตาร์ทอัพ
- บทความชี้ว่านี่เป็นผลจากแนวโน้มเลียนแบบความสำเร็จแบบเน้นแบรนด์ของบริษัทอย่าง Google
ต้นทุนทางการรับรู้และประสิทธิภาพการพัฒนาที่ลดลง
- ชื่ออย่าง libsodium ทำให้เดาหน้าที่ได้ยาก และบังคับให้นักพัฒนาต้อง สลับบริบท ซ้ำไปซ้ำมา
- เสียเวลาโดยไม่จำเป็นไปกับการตีความว่า “ทำไมต้อง sodium?”
- ยิ่งโปรเจ็กต์มี dependency มากขึ้น ภาษีทางการรับรู้ (cognitive tax) นี้ก็ยิ่งสะสม
- และนำไปสู่การลดลงของประสิทธิภาพการทำงานของนักพัฒนา
- ผู้เขียนชี้ว่าเมื่อประมวลผลประโยคอย่าง “Viper, Cobra, Melody…” ทรัพยากรทางความคิดจะถูกใช้ไปกับ การถอดรหัสโทเค็นที่ไร้ความหมาย
ข้อโต้แย้งที่พบบ่อยและคำโต้กลับ
- “ชื่อที่จำง่ายดีกับการตลาด” → เครื่องมือสำหรับนักพัฒนาไม่ใช่สินค้าผู้บริโภค และความชัดเจนของหน้าที่สำคัญกว่า
- “ชื่อเชิงอธิบายน่าเบื่อ” → ความน่าเบื่อเป็นราคาที่ยอมรับได้เพื่อแลกกับความชัดเจน เหมือนเครื่องมือผ่าตัดที่น่าเบื่อแต่แม่นยำ
- “ก็ตั้งเพื่อความสนุก” → ผู้ใช้ทุกคนต้องจ่ายต้นทุนของ ‘ความสนุก’ นั้น และสุดท้ายกลายเป็นการสูญเสียเวลาของทั้งอุตสาหกรรม
- “ชื่อดี ๆ ถูกใช้หมดแล้ว” → แก้ได้ด้วย namespace, prefix, คำประสม และอย่างน้อยที่สุดก็ควรเลือกชื่อที่ยังเกี่ยวข้องกับหน้าที่
ทิศทางต่อจากนี้
- ปัญหานี้อธิบายได้ว่าไม่ใช่ความจงใจร้าย แต่เป็นผลของ การเปลี่ยนแปลงทางวัฒนธรรม
- เมื่อการเขียนโปรแกรมเปลี่ยนจากโลกที่มีองค์กรกำกับไปสู่โลกแบบชุมชนเป็นศูนย์กลาง บรรทัดฐานทางสังคมจึงอ่อนแรงลง
- ทางออกคือ การฟื้นฟูทางวัฒนธรรมของหลักการตั้งชื่อ
- ไม่ใช่ผ่านการกำกับควบคุม แต่ผ่าน การฟื้นความเป็นมืออาชีพ การศึกษา และแรงกดดันทางสังคม
- ชื่อไลบรารีควรสะท้อนหน้าที่การทำงาน และหากจำเป็นก็สามารถใช้ คำประสมหรือถ้อยคำที่ยาวกว่า ได้
- ตัวอย่างเช่น “http-request-validator” ชัดเจนกว่า “zephyr” อย่างมาก
- ควร แยกมาสคอตออกจากชื่อ
- ตัวอย่างเช่น PostgreSQL ใช้ มาสคอตช้าง Slonik แต่ชื่อตัวระบบเองยังคงมีความหมายเชิงหน้าที่
- หากไม่ใช่ สินค้าผู้บริโภคที่การสร้างแบรนด์มีความสำคัญ ก็ควรให้ ความชัดเจนและความเป็นมืออาชีพ มาก่อน
- ก่อนจะตั้งชื่อตาม “ตัวละครอนิเมะที่ชอบ” ควรถามตัวเองก่อนว่า “วิศวกรโยธาจะตั้งชื่อระบบสะพานแบบนี้ไหม?”
- โดยสรุป เราควร หยุดการแพร่กระจายของชื่อที่ไร้ความหมาย และกลับไปใช้ภาษาวิชาชีพที่ชัดเจน
- ความชัดเจนไม่ใช่ความน่าเบื่อ แต่คือ การเคารพเวลาและทรัพยากรทางความคิดของผู้ใช้
7 ความคิดเห็น
แม้แต่ Awk เองก็ยังเรียกว่าเป็นชื่อที่อิงตามฟังก์ชันได้ไม่เต็มปากนัก....
ถ้าไม่ใส่ตัวอย่างมา ความน่าเชื่อถือก็น่าจะเพิ่มขึ้นสัก 10%..
ก็เห็นด้วยอยู่ประมาณหนึ่ง แต่ดูเหมือนพวกเขาไม่อยากเครียดกับการตั้งชื่อ
ชื่อที่พอใช้ได้ก็มีคนอื่นใช้กันหมดแล้ว
มีใครรู้ไหมว่า
emacsหมายความว่าอะไร? ถึงจะมีความหมายอยู่ก็เถอะ แต่ชื่อแบบตัวย่อมันดูแวบเดียวก็ไม่รู้หรอกทั้งที่มันเป็นชื่อ… แล้วตอนนี้ก็มีโปรเจกต์เยอะเกินไปแล้วที่จะตั้งชื่อกันด้วยฟังก์ชันอย่างเดียวเห็นโทษ GitHub ก็เหมือนเป็นการด่าแบบ RMS มั่ว ๆ นั่นแหละ 555
ความคิดเห็นจาก Hacker News
Yacc เวอร์ชันของ GNU มีชื่อว่า Bison. Pine เป็นตัวย่อของ “Pine Is Not Elm” และ UNIX ก็มีที่มาจาก UNICS ซึ่งเป็นการเล่นคำกับ MULTICS. ส่วน dd ย่อมาจากอะไรไม่แน่ใจ, nano เป็นโคลนของ pico และ Postfix เป็นคำผสมระหว่าง ‘post’ กับ ‘bug fix’. C++ คือ เวอร์ชันเพิ่มค่า ของ C, ส่วน C เป็นภาคต่อของ B และ B ก็เป็นภาคต่อของ BCPL. พูดจริง ๆ แล้วไม่ใช่ว่านักพัฒนาทำ “ปรัชญาการตั้งชื่อ” หายไป แต่คือไม่เคยมีมันตั้งแต่แรก. ในทางกลับกัน ผมคิดว่าโปรเจ็กต์สมัยใหม่อย่าง Clang, LLDB, jq, fzf, loc เป็นตัวอย่างของชื่อที่ดี. mise-en-place ก็เป็นอุปมาที่ตรงกับหน้าที่ของ mise ได้อย่างสมบูรณ์
key=valueที่ไม่ค่อยเหมือน UNIXคำสั่ง UNIX อย่าง grep, awk, sed, cat, diff มีชื่อที่ดูเป็นเชิงหน้าที่หรือมีระบบ แต่จริง ๆ แล้วมีแค่ diff เท่านั้นที่พอเดาความหมายได้ตรงไปตรงมา. จะเรียก awk ว่าเป็นชื่อที่ดีก็ดูเกินจริงไป
-libertyได้ผมขอโต้แย้งคำกล่าวที่ว่า “การตั้งชื่อแบบนี้ในสายเทคโนโลยีคือการฆ่าตัวตายในอาชีพ”. ถ้าดูรายชื่อรหัสชื่อของกระทรวงกลาโหมสหรัฐ จะเห็นว่ามีชื่อที่ จงใจคลุมเครือ อยู่มาก. Hoover Dam เองก็เดิมชื่อ Boulder Canyon Project และชื่อนั้นก็ไม่ได้อธิบายหน้าที่อะไร. Reitzlib จะเป็นชื่อที่ดีกว่า Requests จริงหรือ? สุดท้ายแล้วชื่อก็ขึ้นอยู่กับบริบท
ชื่ออย่าง awk จริง ๆ แล้วไม่ใช่ชื่อที่ดี มันเป็นเพียง อักษรย่อของผู้เขียน เท่านั้น และไม่ได้สื่อหน้าที่ใดเลย. ทุกวันนี้ก็มี tab completion แล้ว จึงไม่จำเป็นต้องย่อให้สั้นขนาดนั้น
ผมเห็นด้วยกับบทความโต้แย้งนี้. ตัวระบุที่ใช้อ้างอิงจากภายนอกจะเปลี่ยนความหมายไปตามเวลา ดังนั้นชื่อที่อธิบายได้แม่นยำตั้งแต่ต้นมักอยู่ไม่ทน. อีกทั้งชื่ออย่าง “X Manager” หรือ “X Service” ก็มีมากเกินไปจนแยกกันยาก
ผมเคยทำงานเป็นวิศวกรคาลิเบรตเครื่องยนต์ในบริษัท OEM รถยนต์ ตัวแปรและฟังก์ชันทั้งหมดเป็น คำย่อ แทบทั้งนั้น. เดือนแรกนี่เหนื่อยจนหัวแทบระเบิด. สุดท้ายเพื่อนร่วมงานคนหนึ่งบอกว่า “มันเหมือนกำลังเรียนภาษาใหม่” และมันก็เป็นแบบนั้นจริง ๆ. กล่าวคือ การมีชื่อเชิงเทคนิคเยอะไม่ได้ช่วยลดภาระทางความคิดเสมอไป
ผมเห็นด้วยได้ยากกับคำกล่าวที่ว่า “ชื่อเชิงหน้าที่ดีกว่าการตลาด”. ชื่อที่อิงตามหน้าที่สุดท้ายแล้วจะกลายเป็น ทะเลของตัวย่อที่ไม่มีวันจบ ทำให้เกิดสถานการณ์แบบสับสนระหว่าง ABDC กับ ADBC
แปลกดีที่มีโพสต์แบบนี้ขึ้น HN การยกชื่ออย่าง awk มาเป็นตัวอย่างแล้วบอกว่า “เราทำแก่นแท้ของการตั้งชื่อหายไป” นั้นขัดแย้งในตัวเอง. สุดท้ายแล้วมันดูเหมือนเป็นแค่ อคติส่วนตัวต่อชื่อแนวน่ารัก มากกว่า. สำหรับข้อมูลอ้างอิง ความเห็นนี้พิมพ์จาก Firefox — ซึ่งดูจากชื่ออย่างเดียวก็ไม่รู้เลยว่าเป็นเว็บเบราว์เซอร์
สำหรับข้ออ้างว่า “ชื่อเชิงอธิบายนั้นน่าเบื่อ” เครื่องมือในห้องผ่าตัดจำนวนมากก็ตั้งชื่อตาม ชื่อคน เช่นกัน. Adson, Allis, Babcock, Kocher เป็นชื่อที่ไม่ได้อธิบายหน้าที่อะไรเลย. ท้ายที่สุดพอคุ้นเคยแล้วมันก็มีความหมายขึ้นมาเอง. awk อาจไม่ดีนัก แต่ diff เป็นตัวอย่างที่โอเค
สำหรับคำกล่าวที่ว่า “วงการเราดูเหมือนสวนสัตว์ของคำนามสุ่ม ๆ” ผม ชอบชื่อที่สนุก. โปรเจ็กต์ Wimsey ของผมเป็นไลบรารีทดสอบข้อมูล แต่ดูจากชื่ออย่างเดียวไม่มีทางรู้. ถึงอย่างนั้นผมก็ยังชอบชื่ออย่าง Python, Cron, Zellij ที่มี ความรักและอารมณ์ขัน อยู่ในนั้น. เทคโนโลยีสุดท้ายแล้วก็เป็นสิ่งที่มนุษย์สร้างขึ้น และมันควรมีความสนุกอยู่บ้าง. “brown-dog-2” ไม่เป็นมนุษย์เท่า “cookie”