การอพิปรายล่าสุดเกี่ยวกับการใช้ custom types แทนการใช้ basic data types ได้จุดประกายการถกเถียงอย่างเข้มข้นในหมู่นักพัฒนาเกี่ยวกับความสมดุลระหว่างความปลอดภัยของระบบ type และความซับซ้อนของโค้ด การสนทนานี้มีจุดศูนย์กลางอยู่ที่เทคนิคที่สร้าง types เฉพาะสำหรับแนวคิดต่างๆ แทนที่จะพึ่งพา generic types เช่น strings หรือ integers
ปัญหาหลัก: เมื่อ Simple Types ทำให้เกิดบั๊กที่ซับซ้อน
ปัญหาพื้นฐานเกิดจากสิ่งที่นักพัฒนาเรียกว่า primitive obsession - การใช้ basic data types มากเกินไปสำหรับแนวคิดเฉพาะโดเมน เมื่อทุกอย่างถูกแทนด้วย string, integer หรือ UUID จะทำให้เกิดความผิดพลาดได้ง่าย เช่น การส่ง user ID ไปในตำแหน่งที่ควรจะเป็น account ID หรือการสับสนลำดับของพารามิเตอร์ในฟังก์ชัน ข้อผิดพลาดเหล่านี้มักจะผ่าน code reviews ไปได้และปรากฏขึ้นในระหว่าง runtime บางครั้งถึงขั้นใน production environments
วิธีแก้ไขที่เสนอมาคือการสร้าง distinct types สำหรับแนวคิดต่างๆ แม้ว่าจะมีโครงสร้างพื้นฐานเหมือนกันก็ตาม แนวทางนี้ใช้ประโยชน์จาก compiler ในการตรวจจับ types ที่ไม่ตรงกันก่อนที่โค้ดจะทำงาน ซึ่งช่วยขจัดบั๊กทั้งหมวดหมู่ได้อย่างมีประสิทธิภาพ
ข้อดีเทียบกับข้อเสียของ Custom Types:
ข้อดี:
- การตรวจจับข้อผิดพลาดในขณะ compile-time
- โค้ดที่อธิบายตัวเองได้
- ขจัดความผิดพลาดในการเรียงลำดับพารามิเตอร์
- ป้องกันความสับสนของหน่วยในการคำนวณ
ข้อเสีย:
- ความซับซ้อนของโค้ดที่เพิ่มขึ้น
- เส้นทางการเรียนรู้ที่ชันขึ้นสำหรับนักพัฒนาใหม่
- ศักยภาพของการ over-engineering
- ความท้าทายในการใช้งานที่เฉพาะเจาะจงกับภาษาโปรแกรม
ความท้าทายในการนำไปใช้ข้ามภาษาต่างๆ
ภาษาโปรแกรมมิ่งต่างๆ จัดการกับเทคนิคนี้ด้วยระดับความสง่างามที่แตกต่างกัน นักพัฒนา Go ได้สังเกตเห็นความไม่สอดคล้องที่น่าหงุดหงิด ซึ่งภาษานี้จะแปลงระหว่าง related types โดยอัตโนมัติในบางบริบทแต่ไม่ทำในบริบทอื่น ความไม่สามารถคาดเดาได้นี้สามารถทำลายประโยชน์ด้านความปลอดภัยที่เทคนิคนี้ควรจะให้ได้
นักพัฒนา TypeScript เผชิญกับความท้าทายของตัวเองกับ structural typing มักจะต้องใช้วิธีแก้ไขที่รู้สึกแปลกๆ และเป็นแบบ hacky ในขณะเดียวกัน ภาษาอย่าง Rust และ C# ให้การสนับสนุนที่เป็นธรรมชาติมากกว่าสำหรับแพทเทิร์นนี้ แม้ว่าแต่ละภาษาจะมาพร้อมกับความซับซ้อนของ syntax ของตัวเอง
รูปแบบ Type Safety ทั่วไปแยกตามภาษา:
| ภาษา | รูปแบบ | ข้อดี | ข้อเสีย |
|---|---|---|---|
| Go | type UserID uuid.UUID |
ไวยากรณ์เรียบง่าย | การแปลงอัตโนมัติไม่สม่ำเสมอ |
| TypeScript | type UserID = string & { __tag: unique symbol } |
ทำงานได้ดีกับ structural typing | รู้สึกเหมือนเป็นวิธีที่ไม่เป็นทางการ |
| C | readonly struct Id32<M> { public readonly int Value; } |
ใช้ generic ได้และนำกลับมาใช้ใหม่ได้ | การตั้งค่าเริ่มต้นมีความซับซ้อนมากกว่า |
| Rust | รูปแบบ Newtype | รองรับจาก compiler อย่างแข็งแกร่ง | มีเส้นโค้งการเรียนรู้สำหรับผู้เริ่มต้น |
 |
|---|
| repository นี้แสดงให้เห็นการพัฒนาและการทดลองอย่างต่อเนื่องในด้านความปลอดภัยของประเภทข้อมูลและประเภทข้อมูลแบบกำหนดเองโดยนักพัฒนา |
ความกังวลเรื่อง Overengineering
ส่วนใหญ่ของชุมชนนักพัฒนาเตือนไม่ให้ใช้ type safety มากเกินไป นักวิจารณ์โต้แย้งว่าการสร้าง type มากเกินไปสามารถทำให้ codebase ซับซ้อนและเปราะบางโดยไม่จำเป็นเมื่อความต้องการเปลี่ยนแปลง พวกเขาชี้ไปที่ระบบที่มีหลายพันคลาสซึ่งการดำเนินการง่ายๆ ต้องการ glue code จำนวนมาก ซึ่งอาจนำไปสู่หมวดหมู่ใหม่ของบั๊ก
Type systems เช่นเดียวกับเครื่องมืออื่นๆ ใน toolbox มีกฎ 80/20 ที่เกี่ยวข้องกับพวกมัน การใช้ types มากเกินไปและทำให้การทำงานกับ library เป็นภาระอย่างมากสำหรับประโยชน์เพียงเล็กน้อยหรือไม่มีเลยหรือแม้แต่ให้ผลเสียนั้นเป็นเรื่องง่ายมาก
ความท้าทายอยู่ที่การหาความสมดุลที่เหมาะสม ในขณะที่การป้องกันการสับสน ID อาจจะสมควรกับการใช้ custom types การสร้าง unique types สำหรับความแตกต่างเล็กน้อยทุกอย่างสามารถนำไปสู่ฝันร้ายในการบำรุงรักษาและ learning curve ที่สูงชันสำหรับสมาชิกทีมใหม่
การประยุกต์ใช้ในโลกจริงและเรื่องราวความสำเร็จ
แม้จะมีการถกเถียง นักพัฒนาหลายคนรายงานความสำเร็จอย่างมีนัยสำคัญจากการประยุกต์ใช้เทคนิคนี้อย่างเลือกสรร ไลบรารีคำนวณสภาพอากาศ ระบบการเงิน และแอปพลิเคชันฐานข้อมูลล้วนได้รับประโยชน์จาก domain-specific types ที่ป้องกันความสับสนของหน่วยและการสับสนพารามิเตอร์
ทีมบางทีมได้นำแนวทางแบบ middle-ground มาใช้ โดยใช้เทคนิคนี้หลักๆ สำหรับ identifiers และการวัดที่สำคัญ ในขณะที่เก็บแนวคิดที่ง่ายกว่าไว้เป็น basic types ทีมอื่นๆ รวมเข้ากับ debugging workflow ของพวกเขา โดยกำหนดข้อจำกัดของ type ให้เข้มงวดขึ้นเมื่อเกิดบั๊กใน production เพื่อป้องกันปัญหาที่คล้ายกันในอนาคต
อนาคตของ Type Safety
การอพิปรายนี้สะท้อนคำถามที่กว้างขึ้นเกี่ยวกับว่าภาษาโปรแกรมมิ่งควรพัฒนาไปอย่างไร นักพัฒนาแสดงความสนใจใน type systems ที่ซับซ้อนมากขึ้นซึ่งสามารถบังคับใช้ value ranges ไม่ใช่แค่ความแตกต่างของ type เท่านั้น ภาษาบางภาษากำลังสำรวจ pattern types และฟีเจอร์ขั้นสูงอื่นๆ ที่อาจทำให้ type-driven development ใช้งานได้จริงมากขึ้นและ verbose น้อยลง
การถกเถียงนี้ในที่สุดก็เน้นย้ำถึงความตึงเครียดพื้นฐานในการพัฒนาซอฟต์แวร์ระหว่างความปลอดภัยและความเรียบง่าย ในขณะที่ typing ที่แข็งแกร่งกว่าสามารถป้องกันบั๊กได้หลายตัว แต่ก็ต้องการการตัดสินใจในการออกแบบล่วงหน้ามากขึ้นและสามารถทำให้การเปลี่ยนแปลงโค้ดซับซ้อนมากขึ้น ในขณะที่ทีมพัฒนาต่างๆ ยังคงสร้างสมดุลกับการแลกเปลี่ยนเหล่านี้ การสนทนาเกี่ยวกับ type safety ยังคงมีความเกี่ยวข้องเช่นเดิม
อ้างอิง: Use Your Type System