คำแนะนำด้านการเขียนโปรแกรมที่มีมาช้านานว่า อย่าเขียนไลบรารีแปลงวันที่ของตัวเอง ได้จุดประกายการถกเถียงอย่างเข้มข้นในชุมชนนักพัฒนา หลังจากผู้สร้าง Eleventy ได้ทำลายกฎข้อนี้ แม้ว่าเขาจะเริ่มต้นบทความด้วยคำเตือนนี้เป็นคำแรก แต่เขากลับไปสร้าง @11ty/parse-date-strings ซึ่งเป็นไลบรารีแปลงวันที่แบบกำหนดเองที่รองรับ RFC 9557 และลดขนาดบันเดิลลงอย่างมากจาก 229 kB เหลือเพียง 2.3 kB
การเปรียบเทียบขนาด Bundle
| Package | Type | Disk Size | Bundle Size |
|---|---|---|---|
| [email protected] | Dual | 4.59 MB | 81.6 kB (min) |
| [email protected] | CJS | 4.35 MB | 204.9 kB (min) |
| [email protected] | CJS | 670 kB | 6.9 kB (min) |
| [email protected] | Dual | 22.6 MB | 77.2 kB (min) |
| @11ty/[email protected] | ESM | 6.68 kB | 2.3 kB (min) |
 |
|---|
| การถกเถียงเรื่องการเขียนไลบรารีสำหรับแยกวิเคราะห์วันที่แบบกำหนดเองถูกเน้นย้ำด้วยการอภิปรายในชุมชนนักพัฒนา |
ความแตกต่างระหว่างการเรียนรู้และการใช้งานจริง
การตอบสนองจากชุมชนเผยให้เห็นความขัดแย้งพื้นฐานในปรัชญาการพัฒนาซอฟต์แวร์ นักพัฒนาบางคนโต้แย้งว่าการจัดการกับสิ่งที่ยาก เช่น การแปลงวันที่ เป็นสิ่งสำคัญสำหรับการเติบโตและการเรียนรู้ พวกเขาชี้ให้เห็นว่าไลบรารีที่เป็นผู้ใหญ่ทั้งหมดที่เราพึ่งพาในปัจจุบัน เริ่มต้นจากการสร้างแบบกำหนดเองของใครบางคน อย่างไรก็ตาม คนอื่นๆ เน้นย้ำถึงความแตกต่างที่สำคัญระหว่างการฝึกฝนเพื่อการเรียนรู้และโค้ดที่ใช้งานจริง
เขียนได้เลย แต่อย่าเอาไปใช้ คำเตือนเหล่านี้มักจะอยู่ในบริบทของโค้ดที่คุณจะปล่อยออกมา ไม่ใช่การฝึกฝนเพื่อการเรียนรู้ด้วยตัวเอง
มุมมองนี้เน้นย้ำว่าคำเตือนเกี่ยวกับไลบรารีวันที่แบบกำหนดเองไม่ได้มีจุดประสงค์เพื่อกีดกันการเรียนรู้ แต่เป็นการตระหนักถึงการทดสอบและการจัดการกรณีพิเศษมากมายที่ไลบรารีที่พร้อมใช้งานจริงได้ผ่านมา ลักษณะที่ผ่านการทดสอบในสนามรบของไลบรารีที่มีชื่อเสียงมาจากการใช้งานจริงนับล้านครั้งที่เผยให้เห็นกรณีพิเศษที่นักพัฒนาแต่ละคนอาจไม่เคยพบ
ความซับซ้อนเบื้องหลังวันที่ที่ดูเรียบง่าย
การอภิปรายเผยให้เห็นว่าทำไมวันที่จึงเป็นดินแดนที่อันตรายเป็นพิเศษสำหรับการสร้างแบบกำหนดเอง นอกเหนือจากความซับซ้อนของเขตเวลาที่เห็นได้ชัด นักพัฒนาได้แบ่งปันเรื่องราวของความท้าทายที่ไม่คาดคิด แอปพลิเคชันทางการแพทย์ต้องดิ้นรนกับวันเกิดที่เปลี่ยนแปลงเมื่อผู้ป่วยย้ายเขตเวลา แอปพลิเคชันระหว่างประเทศต้องจัดการกับระบบปฏิทินหลายระบบ รวมถึงปฏิทินญี่ปุ่นที่มีระบบวันที่ตามยุคสมัย
ชุมชนยังเน้นย้ำถึงลักษณะทางการเมืองของเขตเวลา ซึ่งไม่ใช่โครงสร้างทางคณิตศาสตร์ แต่เป็นโครงสร้างทางกฎหมายที่เปลี่ยนแปลงตามการตัดสินใจของรัฐบาล สิ่งนี้เพิ่มชั้นของความซับซ้อนที่แตกต่างออกไปซึ่งเกินกว่าตรรกะการเขียนโปรแกรมแบบบริสุทธิ์
การเปรียบเทียบการรองรับรูปแบบวันที่
| รูปแบบ | ISO 8601 | Date.parse | Luxon | RFC 9557 |
|---|---|---|---|---|
| YYYY | ✔ | ✔ | ✖ | ✖ |
| YYYY-MM | ✔ | ✔ | ✔ | ✖ |
| YYYY-MM-DD | ✔ | ✔ | ✔ | ✔ |
| YYYY-MM-DDTHH:II:SS | ✔ | ✖ | ✖ | ✖ |
| YYYY-MM-DDTHH:II:SSZ | ✔ | ✖ | ✖ | ✔ |
✔ รองรับ ✖ ไม่รองรับ
วิธีแก้ปัญหาและทางเลือกในทางปฏิบัติ
นักพัฒนาหลายคนแบ่งปันแนวทางในโลกแห่งความเป็นจริงของพวกเขาต่อความท้าทายในการจัดการวันที่ สำหรับแอปพลิเคชันที่จัดการกับวันเกิด บางคนได้เปลี่ยนไปใช้การจัดการวันที่เป็นสตริงธรรมดาแทนที่จะเป็นออบเจ็กต์เวลา เพื่อหลีกเลี่ยงบั๊กที่เกี่ยวข้องกับเขตเวลาทั้งหมด คนอื่นๆ สนับสนุนการใช้ประเภทวันที่เฉพาะ เช่น LocalDate หรือ PlainDate ของ Temporal API ที่กำลังจะมาถึง สำหรับสถานการณ์ที่ข้อมูลเขตเวลาไม่เกี่ยวข้อง
การอภิปรายยังสัมผัสถึงการพิจารณาส่วนติดต่อผู้ใช้ โดยนักพัฒนาถกเถียงเกี่ยวกับข้อดีของตัวเลือกวันที่เทียบกับช่องป้อนข้อความ แม้ว่าตัวเลือกวันที่จะให้การควบคุมมากกว่า แต่อาจจะยุ่งยากสำหรับผู้ใช้ที่ป้อนวันที่ในอดีตไกล เช่น ปีเกิด
ผลกระทบต่อ Bundle ของ Eleventy
- การใช้งาน Luxon ใน @11ty/eleventy: 4.7 MB จาก 21.3 MB (22%)
- การใช้งาน Luxon ใน @11ty/client: 229 kB จาก 806 kB (28%)
- การประหยัดที่คาดการณ์ไว้: ~230 kB ใน client bundle, node_modules ลดลงจาก 21.3 MB เหลือ 16.6 MB
ความเป็นจริงของขนาดบันเดิล
การตัดสินใจของ Eleventy ในที่สุดมาจากข้อจำกัดในทางปฏิบัติมากกว่าเหตุผลทางปรัชญา เมื่อ Luxon กินพื้นที่ 22% ของบันเดิล Node.js และ 28% ของบันเดิลไคลเอนต์ ผลกระทบต่อประสิทธิภาพจึงมีนัยสำคัญ กรณีการใช้งานที่เฉพาะเจาะจงมากของพวกเขา - ต้องการเพียงการแปลง ISO 8601 โดยไม่ต้องจัดรูปแบบหรือแสดงผล - ทำให้วิธีแก้ปัญหาแบบกำหนดเองเป็นไปได้
ชุมชนยอมรับว่าความต้องการเฉพาะเจาะจงเช่นนี้สามารถให้เหตุผลสำหรับการสร้างแบบกำหนดเอง โดยเฉพาะเมื่อไลบรารีที่มีอยู่ไม่รองรับ tree-shaking หรือเมื่อกรณีการใช้งานแคบมาก อย่างไรก็ตาม พวกเขาเน้นย้ำว่านี่ควรเป็นข้อยกเว้นมากกว่ากฎ และควรทำหลังจากประเมินทางเลือกที่มีอยู่อย่างละเอียดแล้วเท่านั้น