เมนู

ดินแดนเล็กกับรหัสพิเศษ: ไม่ใช่ทุกแห่งที่มีรหัสสองตัวอักษร

ดินแดนเล็กและเขตปกครองพิเศษเป็นกรณีขอบที่ทำให้ข้อมูลประเทศพังบ่อย บทความนี้อธิบายวิธีจัดการรหัสที่ไม่ครบ ฉายาเก่า และความต่างระหว่างไม่รองรับกับรูปแบบผิด

เผยแพร่เมื่อ

  • กรณีขอบ
  • รหัสพิเศษ

ดินแดนเล็กกับรหัสพิเศษเป็นกลุ่มที่ทีมมักมองข้ามเพราะมีผู้ใช้น้อย แต่กลับเป็นกลุ่มที่ให้ผลตอบแทนสูงที่สุดในการทดสอบ เพราะดินแดนเหล่านี้มีลักษณะที่ต่างจากประเทศขนาดใหญ่ในหลายมิติพร้อมกัน และมักมีโครงสร้างข้อมูลของตัวเอง

ดินแดนใดที่ทำให้ข้อมูลผิดบ่อยที่สุด?

กลุ่มแรกคือดินแดนที่มีสถานะกึ่งอิสระ ซึ่งไม่ใช่ประเทศเต็มรูปแบบแต่ก็ไม่ได้เป็นส่วนหนึ่งของประเทศอื่นในทุกด้าน กลุ่มนี้ทำให้เกิดคำถามว่าควรรวมไว้กับประเทศแม่หรือแยกเป็นรายการต่างหาก

กลุ่มที่สองคือดินแดนที่มีระบบของตัวเอง เช่นมีหน่วยเงิน ระบบรหัสไปรษณีย์ หรือระบบหมายเลขโทรศัพท์เป็นของตัวเอง การมีระบบของตัวเองทำให้การรักษาข้อมูลเป็นรายการแยกมีเหตุผลมากกว่าการรวม

กลุ่มที่สามคือดินแดนที่ถูกอ้างถึงด้วยชื่อที่เคยเป็นทางการในอดีต ซึ่งยังคงอยู่ในข้อมูลเก่าและในความเข้าใจของผู้ใช้บางกลุ่ม

กลุ่มที่สี่คือดินแดนที่ระบบส่วนกลางยังไม่รู้จัก แต่ผู้ใช้พยายามกรอกเข้ามา ซึ่งเป็นกรณีที่ทดสอบเส้นทางที่ระบบต้องตอบอย่างสุภาพ การมีดินแดนเหล่านี้ในชุดทดสอบยังบังคับให้ทีมทบทวนหลักเกณฑ์การเลือกพื้นที่ตั้งแต่ต้น ซึ่งมีอธิบายไว้ในบทความวิธีเลือกประเทศ สำหรับข้อมูลทดสอบ

สิ่งที่ทั้งสี่กลุ่มมีร่วมกันคือไม่มีคำตอบสำเร็จรูป และต้องอาศัยการตัดสินใจที่บันทึกไว้เป็นลายลักษณ์อักษร

ทำไมบางแห่งจึงไม่มีรหัสสองตัวอักษรของตัวเอง?

เพราะระบบรหัสถูกออกแบบให้ครอบคลุมหน่วยทางภูมิศาสตร์และการปกครองในระดับหนึ่ง ไม่ได้ออกแบบให้ทุกพื้นที่ย่อยมีรหัสของตัวเอง พื้นที่บางแห่งจึงปรากฏอยู่ในระบบเฉพาะในฐานะส่วนหนึ่งของหน่วยที่ใหญ่กว่า

ความหมายในทางปฏิบัติคือการตรวจว่าเป็นรหัสสองตัวอักษรที่ถูกต้องไม่เพียงพอที่จะบอกว่าข้อมูลนั้นถูก เพราะการไม่มีรหัสไม่ใช่ความผิดพลาดของผู้ใช้

อีกกรณีที่ต้องระวังคือรหัสที่เคยถูกใช้และถูกยกเลิกไปแล้ว ซึ่งยังคงอยู่ในข้อมูลเก่า การปฏิเสธรหัสเหล่านี้ทันทีจะทำให้ข้อมูลที่เคยถูกต้องอ่านไม่ได้

ระบบรหัสยังมีรหัสที่สงวนไว้สำหรับการใช้งานภายในและการอ้างอิงที่ไม่ใช่หน่วยภูมิศาสตร์จริง การนำรหัสเหล่านี้ไปใช้แทนรหัสของพื้นที่จริงเป็นความผิดพลาดที่ทำให้ข้อมูลสับสน

แนวทางที่ปลอดภัยคือแยกความหมายของการไม่มีรหัสออกจากความหมายของรหัสที่ผิด และเก็บข้อมูลเดิมไว้ให้อ่านได้แม้รหัสจะถูกยกเลิกแล้ว

ควรจัดการชื่อเดิมและชื่อที่ผู้ใช้เรียกเองอย่างไร?

ชื่อเดิมและชื่อที่ผู้ใช้เรียกเองเป็นข้อมูลที่ต้องถูกจัดการ ไม่ใช่ถูกปฏิเสธ เพราะผู้ใช้ที่กรอกชื่อเดิมมักไม่ได้กรอกผิด แต่ใช้ชื่อที่ตัวเองรู้จัก

แนวทางที่ได้ผลคือการมีรายการเทียบที่เก็บชื่อเรียกหลายแบบไว้คู่กับรหัสของพื้นที่ แล้วใช้รายการนี้ในการค้นหาและการตีความข้อมูลที่นำเข้า

สิ่งที่ต้องระวังคือการรวมชื่อที่คล้ายกันโดยอัตโนมัติ ซึ่งอาจรวมพื้นที่ที่ต่างกันจริงเป็นรายการเดียว การให้ระบบเสนอตัวเลือกให้ผู้ใช้ยืนยันปลอดภัยกว่าการตัดสินใจแทน

เมื่อไม่สามารถระบุได้อย่างมั่นใจ การตอบอย่างสุภาพพร้อมขอให้ผู้ใช้ยืนยันจะดีกว่าการเดา เพราะการเดาผิดจะสร้างข้อมูลที่ดูถูกต้องแต่ผิด

ประเด็นเรื่องการจับคู่ชื่อและการจัดการชื่อเรียกหลายแบบมีรายละเอียดในบทความการจับคู่ชื่อประเทศกับชื่อเรียกอื่น

ทำไมต้องแยกสถานะไม่เกี่ยวข้องกับยังไม่ทราบ?

เพราะสองสถานะนี้ตอบคำถามต่างกัน สถานะไม่เกี่ยวข้องบอกว่าไม่มีสิ่งที่ต้องหา ส่วนสถานะยังไม่ทราบบอกว่าเรายังไม่ได้หา

เมื่อสองสถานะนี้ถูกเก็บเป็นค่าเดียวกัน รายงานจะแสดงงานค้างที่ไม่มีอยู่จริง และจะไม่มีใครเห็นความบกพร่องจริงที่ซ่อนอยู่

ในทางกลับกัน ถ้าเก็บสถานะไม่เกี่ยวข้องเป็นค่าว่างธรรมดา ระบบจะไม่สามารถแยกได้ว่าผู้ใช้ข้ามช่องนี้ไปหรือพื้นที่นี้ไม่มีช่องนี้ตั้งแต่ต้น ซึ่งทำให้การตรวจความจำเป็นของช่องทำไม่ได้

การแยกสองสถานะนี้ยังมีผลกับการส่งออกข้อมูลด้วย เพราะผู้รับข้อมูลปลายทางต้องรู้ว่าค่าที่หายไปหมายถึงอะไร จึงจะตัดสินใจได้อย่างถูกต้อง

ในทางปฏิบัติ สถานะทั้งสองควรเป็นค่าที่ระบุได้ชัดเจน ไม่ใช่ค่าที่เกิดจากการไม่มีข้อมูล และควรมีชื่อที่ผู้ใช้เข้าใจได้ ไม่ใช่รหัสภายใน

การไม่รองรับต่างจากรูปแบบผิดอย่างไร?

ทั้งสองกรณีทำให้การบันทึกไม่สำเร็จเหมือนกัน แต่สาเหตุและทางแก้ต่างกันคนละทาง

การไม่รองรับเป็นเรื่องของความสามารถของธุรกิจ ซึ่งไม่เกี่ยวกับข้อมูลที่ผู้ใช้กรอก และไม่มีอะไรให้ผู้ใช้แก้

รูปแบบผิดเป็นเรื่องของข้อมูลที่ผู้ใช้กรอก ซึ่งผู้ใช้แก้ได้ และไม่เกี่ยวกับความสามารถของธุรกิจ

เมื่อรวมสองกรณีเป็นข้อความเดียว ผู้ใช้จะพยายามแก้ข้อมูลซ้ำแล้วซ้ำอีกโดยไม่รู้ว่าปัญหาอยู่ที่อื่น และทีมสนับสนุนจะไม่สามารถแยกได้ว่าควรตอบอย่างไร

สิ่งที่ต้องมีคือสถานะที่แยกประเภทในระบบ ข้อความที่แยกกันบนหน้าจอ และการบันทึกเหตุผลของการปฏิเสธไว้เพื่อตรวจสอบย้อนหลัง

การปฏิเสธที่สุภาพและบอกสาเหตุได้ยังช่วยลดจำนวนครั้งที่ผู้ใช้ติดต่อฝ่ายสนับสนุนด้วย เพราะผู้ใช้รู้ว่าต้องทำอะไรต่อ

สถานะที่ระบบตอบ สาเหตุที่แท้จริง ผู้ใช้ต้องทำอะไร
ไม่รองรับพื้นที่นี้ ข้อจำกัดของธุรกิจ เปลี่ยนปลายทางหรือยกเลิก
รูปแบบข้อมูลไม่ถูกต้อง ข้อมูลที่กรอก แก้ข้อมูลแล้วส่งใหม่
ยังไม่ทราบผล ระบบยังยืนยันไม่ได้ รอหรือติดต่อฝ่ายสนับสนุน
ต้องยืนยันพื้นที่ ชื่อที่จับคู่ได้ไม่ชัดเจน เลือกพื้นที่ที่ถูกต้อง

และเมื่อจำนวนพื้นที่ลักษณะนี้เพิ่มขึ้นจนต้องดูแลพร้อมกัน วิธีจัดระเบียบข้อมูลจะต่างจากตอนที่มีเพียงไม่กี่แห่ง และต้องอาศัยค่าคงที่ที่ใช้ได้กับทุกพื้นที่

สำหรับนักพัฒนา: เตรียมชุดตัวอย่างคงที่สำหรับดินแดนเล็ก

ข้อแรกคือเลือกดินแดนตัวอย่างจำนวนน้อยที่ครอบคลุมลักษณะต่าง ๆ และใช้ชุดเดิมทุกครั้งในการทดสอบ เพราะการเปลี่ยนชุดไปเรื่อย ๆ ทำให้ผลการทดสอบเทียบกันไม่ได้

ข้อที่สองคือเขียนข้อกำหนดเฉพาะของแต่ละตัวอย่างไว้ เช่นช่องใดไม่เกี่ยวข้องกับดินแดนนั้นและช่องใดบังคับเพื่อให้เห็นชัดว่าอะไรคือพฤติกรรมที่คาดหวัง

ข้อที่สามคือทดสอบรหัสที่ถูกยกเลิกและรหัสที่ระบบไม่รู้จัก โดยคาดหวังว่าระบบจะตอบอย่างสุภาพและไม่ล้มทั้งกระบวนการ

ข้อที่สี่คือเก็บรหัสที่ผู้ใช้เลือกไว้พร้อมชื่อ ณ เวลาที่บันทึก เพื่อให้เอกสารเก่ายังอ่านได้ถูกต้องเมื่อข้อมูลหลักเปลี่ยนไป

ข้อที่ห้าคือหลีกเลี่ยงการใช้ข้อมูลของบุคคลหรือองค์กรจริงเป็นตัวอย่าง แม้ว่าดินแดนนั้นจะมีผู้ใช้จริงอยู่ก็ตาม

ก้าวต่อไป

เริ่มจากการเปิดรายการพื้นที่ทั้งหมดที่ระบบของทีมรองรับ แล้วทำเครื่องหมายว่าพื้นที่ใดมีระบบของตัวเองและพื้นที่ใดไม่มี ถ้าพบพื้นที่ที่สถานะยังไม่ชัด ให้ตัดสินใจและบันทึกเหตุผลไว้ทันที

ถ้าต้องการดูว่าพื้นที่และภูมิภาคถูกจัดเรียงไว้อย่างไร หน้าประเทศและภูมิภาคบนเว็บไซต์นี้จัดกลุ่มรายการตามภูมิภาคและแสดงข้อมูลของแต่ละแห่งในตารางเดียว และกรณีที่ต้องอ้างอิงหลายพื้นที่พร้อมกันในรายการเดียวมีอธิบายไว้ในบทความสถานการณ์ที่อยู่ข้ามพรมแดน

ตัวอย่างดินแดนในบทความนี้เป็นกรณีขอบที่ผู้เขียนประกอบขึ้นเพื่อสาธิตการจัดการข้อมูล ไม่ได้อ้างอิงการกำหนดรหัสหรือสังกัดของพื้นที่ใดที่มีอยู่จริง

อ่านต่อ

บทความเกี่ยวกับ รูปแบบที่อยู่และข้อมูลตัวตนตามประเทศ

บทความเกี่ยวกับ รูปแบบที่อยู่และข้อมูลตัวตนตามประเทศ

รายการนี้แสดงเฉพาะบทความในหัวข้อของหน้านี้