วิศวกรรมซอฟต์แวร์
ทำแผนผังรัศมีผลกระทบของการเปลี่ยนโค้ด
แผนที่ผลกระทบติดตาม diff ที่เสนอผ่านผู้เรียก สิ่งที่ต้องใช้ ข้อมูล การประกาศ การทดสอบ และเส้นทางลูกค้า เพื่อเปิดเผยผลกระทบซ่อนก่อนลงมือ
กระบวนการ
ทำตามลำดับนี้
- กำหนดการเปลี่ยนแปลงที่เสนอ การแก้ไขฐานและปลาย ผลลัพธ์ที่ต้องการ ไฟล์ในขอบเขต สมมติฐาน และการตัดสินใจที่แผนที่ต้องให้ข้อมูล
- ตรวจสอบความต่างและรายการที่ขึ้นอยู่โดยตรง แล้วค้นหาผู้เรียก import อินเทอร์เฟซ โค้ดที่สร้างขึ้น การตั้งค่า และการทดสอบด้วยเครื่องมือที่มี
- สร้างแผนที่หลักฐานแบบคงที่ของผลกระทบผ่าน API การอ่านและเขียนข้อมูล คิว งาน สิทธิ์ สวิตช์คุณสมบัติ การตั้งค่าการประกาศ และเส้นทางที่ลูกค้าเห็น
- แผนที่เจ้าของ ความครอบคลุมของการทดสอบ การสังเกต การพึ่งพา และข้อจำกัดการย้าย โดยจัดแต่ละพื้นที่เป็นโดยตรง เป็นไปได้ เป็นไปได้น้อย หรือไม่ทราบ และแยกหลักฐานแบบคงที่ออกจากสมมติฐานขณะรัน
- ระบุช่องว่างของการตรวจสอบ การเข้าถึง ความเข้ากันได้ การย้อนกลับ และการสังเกต เสนอการตรวจที่เล็กและปลอดภัยที่สุด แต่ห้ามรันการทดสอบ คำสั่งแพ็กเกจ หรือเส้นทางขณะรันในขั้นตอนนี้
- สรุปผลกระทบและการย้อนกลับได้ ระบุข้อมูลอ่อนไหวและโค้ดที่ไม่น่าเชื่อถือ และขออนุมัติแยกสำหรับการทดสอบหรือคำสั่งแพ็กเกจที่จำเป็น
- บันทึกแผนที่และหลักฐานดิบที่ไม่เป็นความลับในพื้นที่ทำงานเป้าหมายของ Latch ระบุขอบเขตความครอบคลุมและความเสี่ยงที่ยังไม่ได้แก้ไข โดยไม่เปลี่ยนคลังโค้ดหรือสถานะระยะไกล
เตรียมสิ่งนี้
ข้อมูลที่แมวจะขอ
- การแก้ไขฐานและปลายหรือความต่าง
- การเปลี่ยนแปลงและขอบเขตที่ตั้งใจ
- บริบทขณะรันและการประกาศ
- การยอมรับความเสี่ยงและเจ้าของการทบทวน
เราเตอร์ + playbook เดียว
จัดเส้นทางก่อน เลือกอันเดียว
Cat Paw โหลด playbook เดียวต่องาน ไม่ผสมหลายอัน เริ่มที่เราเตอร์นี้ เส้นทางที่เหลือเป็นตัวเลือกเฉพาะ workflow
- เราเตอร์:
code-graph-pack skills/code-graph-pack/code-change-blast-radius-map/SKILL.md
เส้นเขต
ขอบเขตเดินทางไปกับพรอมต์
- ก่อนเริ่ม ให้ตรวจสอบเครื่องมือ บัญชี สิทธิ์ และพื้นที่ทำงานจริง ห้ามอ้างว่ามีเครื่องมือ บัญชี แหล่งข้อมูล หรือความสามารถที่ไม่พร้อมใช้งาน
- ใช้ Latch/target-workspace สำหรับโค้ดส่วนตัว ผลงาน การตรวจสอบสด หรือข้อมูลที่ไม่เป็นสาธารณะ หากไม่มีสิทธิ์เข้าถึง ให้หยุดที่ขอบเขตและรายงานสิ่งกีดขัด แทนการเดา
- หยุดเพื่อขออนุมัติอย่างชัดเจนก่อนการดำเนินการภายนอกที่มีผลกระทบ แล้วส่งกลับหลักฐาน ความเสี่ยงที่ยังไม่ได้แก้ไข สมมติฐาน และการดำเนินการใดที่ยังรอการอนุมัติ
เสร็จหมายถึง
จุดจบที่ตรวจได้
แผนที่หลักฐานแบบคงที่ติดตามความต่างที่ระบุผ่านโค้ด ข้อมูล สิ่งที่ต้องใช้ การประกาศ การทดสอบ และผู้ใช้ พร้อมความเสี่ยงที่จัดอันดับ การตรวจที่เสนอ ขอบเขตความครอบคลุม และความเสี่ยงที่ยังไม่ได้แก้ไข โดยไม่เปลี่ยนคลังโค้ดหรือสถานะระยะไกล
แหล่งที่มา
กระบวนการนี้มาจากไหน
- github.com/Graphify-Labs/graphify/tree/4c735618f3d56fd622c2049771584621c31ba9ff/
- docs.github.com/en/code-security/supply-chain-security/understanding-your-software-supply-chain/about-dependency-review
- c4model.com/
แหล่งที่มาตั้งรูปแบบของ workflow โพสต์ Reddit และชุมชน ถ้ามี ให้ถือเป็นเรื่องเล่าจากผู้ปฏิบัติ ไม่ใช่ข้อเท็จจริงสากล