วิศวกรซอฟต์แวร์กำลังหารือเกี่ยวกับตัวอย่างที่น่าสนใจของการที่ภาษาโปรแกรมมิ่งต่อสู้กับกฎของ Hyrum อย่างแข็งขัน ซึ่งเป็นหลักการที่ว่าผู้ใช้จะพึ่งพาพฤติกรรมที่สังเกตได้ในระบบอย่างหลีกเลี่ยงไม่ได้ ไม่ว่าสิ่งที่สัญญาไว้อย่างเป็นทางการจะเป็นอย่างไร การหารือในชุมชนล่าสุดเผยให้เห็นว่านักออกแบบภาษาใช้เทคนิคอันชาญฉลาดเพื่อป้องกันไม่ให้นักพัฒนาพึ่งพารายละเอียดการดำเนินงานโดยบังเอิญ
วิธีแก้ปัญหาสร้างสรรค์ของ Go ในการป้องกันการพึ่งพาโดยบังเอิญ
Go ใช้แนวทางที่ไม่ธรรมดาเพื่อป้องกันไม่ให้นักพัฒนาพึ่งพาลำดับการวนซ้ำของ map ภาษานี้จงใจสุ่มลำดับทุกครั้งที่คุณวนซ้ำผ่าน map หมายความว่า map เดียวกันจะคืนค่า key ในลำดับที่แตกต่างกันในการวนซ้ำหลายครั้ง ซึ่งบังคับให้นักพัฒนาเขียนโค้ดที่ไม่พึ่งพาลำดับใดลำดับหนึ่งโดยเฉพาะ
การดำเนินงานนี้มีประสิทธิภาพอย่างน่าประหลาดใจ แทนที่จะสร้างสำเนาหน่วยความจำที่มีราคาแพง Go เลือก bucket เริ่มต้นแบบสุ่ม วนซ้ำผ่าน bucket ตามลำดับปกติในขณะที่วนกลับ และสร้างการจัดเรียงแบบสุ่มของรายการภายใน bucket ที่มี 8 รายการ แนวทางนี้ป้องกันข้อผิดพลาดทั่วไปที่โค้ดทำงานได้ระหว่างการทดสอบแต่ล้มเหลวในการผลิตเนื่องจากรูปแบบการวนซ้ำที่แตกต่างกัน
หมายเหตุทางเทคนิค: bucket ในการดำเนินงาน map ของ Go คือคอนเทนเนอร์ขนาดเล็กที่เก็บคู่ key-value หลายคู่เป็นส่วนหนึ่งของโครงสร้าง hash table
รายละเอียดการใช้งาน Go Map
วิธีการสุ่ม:
- เลือก bucket เริ่มต้นแบบสุ่ม
- วนซ้ำผ่าน buckets ตามลำดับ (กลับไปที่จุดเริ่มต้นเมื่อถึงจุดสิ้นสุด)
- สร้างการเรียงสับเปลี่ยนแบบสุ่มของ 0-7 สำหรับรายการภายในแต่ละ bucket
- ไม่ต้องการ memory overhead แบบ O(n)
ลักษณะประสิทธิภาพ:
- ความซับซ้อนของพื้นที่แบบ O(1) สำหรับการสุ่ม
- ค่าใช้จ่ายด้านเวลาน้อยที่สุดในระหว่างการวนซ้ำ
- ป้องกันการพึ่งพาลำดับโดยไม่ตั้งใจ
การเดินทางในทิศทางตรงข้ามของ Python กับการเรียงลำดับ Dictionary
Python เลือกเส้นทางที่แตกต่างอย่างสิ้นเชิงกับ dictionary ของมัน ในตอนแรก CPython รักษาลำดับการแทรกไว้เป็นผลข้างเคียงที่ไม่ได้ตั้งใจของการดำเนินงานใหม่ในเวอร์ชัน 3.6 นักพัฒนาจำนวนมากเริ่มพึ่งพาพฤติกรรมนี้จนทีม Python ทำให้มันเป็นส่วนหนึ่งของข้อกำหนดภาษาอย่างเป็นทางการในเวอร์ชัน 3.7
สิ่งนี้แสดงถึงกรณีคลาสสิกของกฎของ Hyrum ในการปฏิบัติ สิ่งที่เริ่มต้นเป็นรายละเอียดการดำเนินงานกลายเป็นฟีเจอร์ที่โปรแกรมนับล้านพึ่งพาในปัจจุบัน ทีม Python ตระหนักว่าการทำลายพฤติกรรมนี้จะก่อให้เกิดปัญหาอย่างกว้างขวาง จึงเลือกที่จะยอมรับมันแทน
ไทม์ไลน์วิวัฒนาการของ Python Dictionary
Python 3.6: CPython dictionaries เริ่มรักษาลำดับการแทรกข้อมูลเป็นรายละเอียดของการใช้งานจริง Python 3.7: การรักษาลำดับการแทรกข้อมูลกลายเป็นส่วนหนึ่งของข้อกำหนดภาษาอย่างเป็นทางการ เหตุผล: ผู้ใช้จำนวนมากเกินไปเริ่มพึ่งพาพฤติกรรมการจัดลำดับนี้ ผลกระทบ: สิ่งที่เริ่มต้นเป็นรายละเอียดของการใช้งานจริงกลายเป็นคุณสมบัติที่รับประกันของภาษา
แนวทางของอุตสาหกรรมธนาคารต่อความน่าเชื่อถือ
ระบบการเงินให้มุมมองที่น่าสนใจอีกแบบหนึ่งในการจัดการความคาดหวังของผู้ใช้ เครือข่ายธนาคารจัดการกับความท้าทายในการส่งข้อความมาเป็นทศวรรษโดยใช้กระบวนการกระทบยอด เมื่อการสื่อสารระหว่างธนาคารขัดข้อง พวกเขาไม่เพียงแค่ลองส่งข้อความใหม่ แต่มีระบบที่ซับซ้อนเพื่อให้แน่ใจว่าทั้งสองฝ่ายเห็นพ้องกันว่าธุรกรรมใดเกิดขึ้นจริง
แนวทางนี้ยอมรับว่าการส่งมอบแบบครั้งเดียวที่สมบูรณ์แบบเป็นไปไม่ได้ในระบบกระจาย แต่สร้างวิธีแก้ปัญหาที่บรรลุผลลัพธ์ในทางปฏิบัติเดียวกันผ่านการประสานงานที่ระมัดระวังและตัวระบุธุรกรรมที่ไม่ซ้ำกัน
การรับประกันการส่งมอบข้อความในระบบธนาคาร
ตัวเลือกมาตรฐาน:
- "ส่งได้มากที่สุดหนึ่งครั้ง" - อาจเกิดการสูญหายของข้อความได้
- "ส่งได้อย่างน้อยหนึ่งครั้ง" - อาจเกิดการส่งข้อความซ้ำได้
- "ส่งได้เพียงหนึ่งครั้ง" - เป็นไปไม่ได้ที่จะรับประกันในระบบแบบกระจาย
วิธีแก้ไขของระบบธนาคาร:
- ใช้มาตรฐานการกระทบยอดของ ISO 20022
- ใช้รหัสประจำตัวธุรกรรมที่ไม่ซ้ำกันเพื่อความ idempotency
- ดำเนินการส่งข้อความไปมาจนกว่าทั้งสองฝ่ายจะตกลงกัน
- ใช้โดย SWIFT , FedNow , FedWire และระบบในประมาณ 70 ประเทศ
ผลกระทบด้านความปลอดภัยและการทดสอบ
การหารือในชุมชนเผยให้เห็นว่าหลักการเหล่านี้ขยายไปเกินกว่าการออกแบบ API อย่างง่าย ระบบรักษาความปลอดภัยสนามบินฉีดภัยคุกคามปลอมเข้าไปในเครื่องสแกน X-ray เพื่อให้ผู้ปฏิบัติงานตื่นตัว เนื่องจากภัยคุกคามจริงหายากมากจนคนงานอาจประมาทได้ ในทำนองเดียวกัน บางคนแนะนำว่ารถยนต์ขับเคลื่อนอัตโนมัติที่ต้องมีการตรวจสอบจากมนุษย์อาจต้องขอให้คนขับเข้าควบคุมโดยไม่จำเป็นเป็นครั้งคราว เพื่อให้แน่ใจว่าคนขับยังคงมีส่วนร่วม
สำหรับรถยนต์ขับเคลื่อนอัตโนมัติ หากต้องมีการตรวจสอบ คุณอาจต้องให้รถขอให้คนขับเข้าควบคุมแบบสุ่ม แม้ว่าจะไม่จำเป็นก็ตาม หรือแสดงให้เห็นว่ากำลังทำผิดพลาดแบบสุ่ม เพื่อดูว่าผู้ใช้ตอบสนองหรือไม่
ความท้าทายสำหรับนักออกแบบ API
ตัวอย่างเหล่านี้เน้นย้ำความตึงเครียดอย่างต่อเนื่องระหว่างความคาดหวังของผู้ใช้และความเป็นจริงทางเทคนิค ในขณะที่บางคนโต้แย้งว่าการพึ่งพาพฤติกรรมที่ไม่มีเอกสารถือเป็นแนวทางปฏิบัติทางวิศวกรรมที่ไม่ดี ความเป็นจริงคือการพึ่งพาดังกล่าวมักเกิดขึ้นโดยบังเอิญ นักพัฒนาเขียนโค้ดที่ทำงานได้ ส่งมอบมัน และต่อมาจึงค้นพบว่ามันพึ่งพาเวลาหรือลำดับเฉพาะที่ไม่ได้รับการรับประกัน
แนวทางปฏิบัติการพัฒนาสมัยใหม่ยิ่งตระหนักถึงความท้าทายนี้มากขึ้น ทีมงานบางทีมตอนนี้นำความโกลาหลที่ควบคุมได้เข้าสู่ระบบของพวกเขา โดยจงใจเปลี่ยนพฤติกรรมที่ไม่ได้รับการรับประกันระหว่างการเผยแพร่เพื่อป้องกันไม่ให้ผู้ใช้คุ้นเคยกับรายละเอียดการดำเนินงานมากเกินไป
การหารือแสดงให้เห็นว่ากฎของ Hyrum ไม่ใช่เพียงการสังเกตทางวิชาการ แต่เป็นความท้าทายในทางปฏิบัติที่กำหนดรูปแบบการออกแบบภาษาโปรแกรมมิ่ง API และระบบที่ซับซ้อน ไม่ว่าจะผ่านการสุ่มของ Go การเปลี่ยนแปลงข้อกำหนดของ Python หรือกระบวนการกระทบยอดของธนาคาร ระบบที่ประสบความสำเร็จต้องคำนึงถึงช่องว่างระหว่างสิ่งที่พวกเขาสัญญาและสิ่งที่ผู้ใช้พึ่งพาจริง ๆ
อ้างอิง: Hyrum's Law