วิธีรีแฟคเตอร์ Legacy Webhook Mappers ด้วย 9 เพย์โหลด
แนวทางปฏิบัติตามขั้นตอนในการรีแฟคเตอร์ฟังก์ชัน map_payload สำหรับเวอร์ชัน v1 ถึง v3 โดยล็อกเพย์โหลดทดสอบ 9 แถวเป็นเกณฑ์มาตรฐาน
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
- ล็อกเพย์โหลดทดสอบ 9 แถวให้ตรงก่อนเริ่มแก้ไขโค้ดใดๆ
- ห้ามรวมการดึงฟังก์ชันช่วย (helper) และการเปลี่ยนชื่อฟิลด์ไว้ในคอมมิตเดียวกัน
- ผลลัพธ์ผ่านเกณฑ์มาตรฐานต้องแสดงข้อความ rows=9 failed=0 อย่างแม่นยำ
- แยกการปรับแต่งโค้ดแต่ละเวอร์ชันออกจากกันเพื่อป้องกันข้อผิดพลาด
การปรับปรุงโค้ดส่วน map หรือที่เรียกว่า mapper refactor จะมีความปลอดภัยก็ต่อเมื่อเอาต์พุตถูกตรึงเอาไว้เรียบร้อยแล้ว โดยผู้พัฒนาควรย้ายกิ่ง (branch) ของเวอร์ชันเดียวกว่าหลังจากที่แถวข้อมูลทั้งหมดตรงกันแล้ว สิ่งสำคัญคือห้ามทำการดึงฟังก์ชันช่วยออกพร้อมกับการเปลี่ยนชื่อฟิลด์ในคราวเดียวกัน เนื่องจากจะทำให้ตรวจสอบได้ยากว่าการเปลี่ยนแปลงส่วนใดส่งผลกระทบต่อระบบเรียกเก็บเงิน
สำหรับระบบ webhook mappers แบบดั้งเดิมมักจะมีกิ่งเติบโตขึ้นตามเวอร์ชันของพาร์ทเนอร์แต่ละราย การทำความสะอาดโค้ดมักจะไปเปลี่ยนพฤติกรรมสองอย่างในดิฟฟ์เดียว ส่งผลให้ผู้ตรวจสอบโค้ดไม่สามารถระบุได้ว่าการแก้ไขส่วนใดกันแน่ที่ทำให้ระบบเรียกเก็บเงินพัง ทางออกคือการตรึงแถวเพย์โหลดไว้ 9 แถวเป็นตัวอย่างก่อนเริ่มแก้ไขใดๆ ทั้งสิ้น โดยแถวเหล่านี้เป็นข้อมูลตัวอย่างไม่ใช่ทราฟฟิกจริง และไม่มีการอ้างอิงเมตริกการผลิตใดๆ ทั้งสิ้นสำหรับชุดตัวอย่างนี้
ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง
ฟังก์ชันหลักยังคงชื่อว่า map_payload เช่นเดิม โดยผลลัพธ์การแมปจะคืนค่าคีย์สตริงเพียง 3 คีย์ ได้แก่ event_id, amount_cents และ status เท่านั้น ส่วนเวอร์ชันที่รองรับยังคงเป็น v1, v2 และ v3 เท่านั้นเช่นเดิม หากเป็นเวอร์ชันที่ไม่รู้จัก ฟังก์ชันนี้จะยังคงคืนค่า None เช่นเดียวกับอินพุตที่ไม่ใช่ dict
ข้อความเกี่ยวกับจำนวนเงินจะถูกแปลงเป็นหน่วยเซนต์แบบจำนวนเต็ม และสถานะข้อความจะถูกปรับเป็นตัวพิมพ์เล็กสำหรับแถว v2 ทุกแถว หากฟิลด์บังคับเกิดสูญหาย ฟังก์ชันจะคืนค่า None กลับไปยังผู้เรียกใช้งานทันที การเขียนโค้ดตัวอย่างเหล่านี้ขึ้นมาเพื่อใช้เป็นแบบฝึกหัดเท่านั้น ไม่ได้ดึงมาจากบริการส่วนตัวแต่อย่างใด
"Run the stdlib checker against mapper_before.py before editing. Treat every failure here as a fixture problem."
MonkeyCode Product Outreach
การทำความเข้าใจบริบทของการรีแฟคเตอร์โค้ดระบบหลังบ้าน (Legacy Code) ที่มีความซับซ้อนสูง การแยกส่วนการเปลี่ยนแปลงออกเป็นชิ้นเล็กๆ (Atomic Commits) ช่วยลดความเสี่ยงในการเกิด Bug ได้อย่างมีประสิทธิภาพ การล็อกชุดข้อมูลทดสอบไว้ล่วงหน้าทำหน้าที่เสมือนตาข่ายนิรภัย (Safety Net) ก่อนการปรับปรุงโครงสร้างโค้ดภายใน
ก่อนที่จะเริ่มเปิดดูการเปลี่ยนแปลงของโค้ด ควรใช้ตารางตัดสินใจ (decision table) เพื่อเลือกกิ่งเดียวและปฏิเสธการทำความสะอาดแบบปะปนกัน การตรวจสอบความถูกต้องด้วยเช็คเกอร์ของไลบรารีมาตรฐาน (stdlib checker) ก่อนทำการแก้ไขจึงเป็นสิ่งจำเป็น หากพบความล้มเหลวให้ถือว่าเป็นปัญหาที่ชุดทดสอบ (fixture problem) และห้ามเริ่มกระบวนการแยกฟังก์ชันบนฐานข้อมูลที่เป็นสีแดงอย่างเด็ดขาด
คำสั่งคาดหวังมาตรฐานคือ rows=9 failed=0 หากได้จำนวนที่ต่างออกไปหมายความว่าการตรึงข้อมูลล้มเหลว ต้องหยุดกระบวนการทันทีแล้วทำการซ่อมแซมที่แถวข้อมูลไม่ใช่ที่ตัวดีไซน์โค้ด การตรวจสอบนี้ต้องรันด้วย Python 3 เท่านั้น เนื่องจากระบบเปรียบเทียบพจนานุกรมของ Python 3 จะไม่สนใจลำดับของคีย์ ทำให้การแมปที่ตรงกันยังคงผ่านแม้ลำดับคีย์จะสลับกันก็ตาม
ที่มา: Dev.to
พบข้อมูลผิดพลาดในบทความนี้? แจ้งปัญหาบทความนี้
ความคิดเห็น
แสดงความคิดเห็น