วิศวกรรมซอฟต์แวร์
ค้นหา dependency และ abstraction ที่นำออกได้
ตรวจสอบการนำออกโดยอาศัยหลักฐาน เพื่อหา dependency หรือ abstraction ที่ต้นทุนสูงกว่าคุณค่า และเสนอการทำให้เล็กลงที่ผ่านการทดสอบโดยไม่เปลี่ยนพฤติกรรมที่จำเป็น
กระบวนการ
ทำตามลำดับนี้
- กำหนดพฤติกรรมที่ต้องคงไว้ การแก้ไขของคลังโค้ด สภาพแวดล้อมที่รองรับ และสัญญาณต้นทุนที่ทำให้การพึ่งพาหรือ abstraction ควรได้รับการตรวจ
- ทำบัญชีแพ็กเกจโดยตรงและโดยอ้อม wrapper อินเทอร์เฟซ อะแดปเตอร์ โค้ดที่สร้างขึ้น และการตั้งค่า แล้วตามรอยผู้เรียกและจุดเข้าระหว่างรัน
- สร้างสถานะฐานจากการทดสอบเดิม บิลด์ การตรวจชนิด ตัวชี้วัดประสิทธิภาพหรือการดำเนินงาน หลักฐานความปลอดภัย และข้อจำกัดการสนับสนุนที่รู้แล้ว
- จัดหมวดผู้สมัครเป็นลบได้ แทนที่ได้ คงไว้ หรือไม่ทราบ หลังตรวจการใช้งานแบบไดนามิก ผลกระทบทางอ้อม ความเข้ากันได้ และต้นทุนการย้าย
- ทำต้นแบบการลบที่เล็กและปลอดภัยที่สุดในสาขาหรือ worktree แยก รันการตรวจเฉพาะจุดและรอบข้างเคียง แล้วเปรียบเทียบพฤติกรรมและการใช้ทรัพยากรกับสถานะฐาน
- เลือกลบ แทนที่ เลื่อน หรือคงไว้ พร้อมบันทึกหมายเหตุการย้าย การย้อนกลับ การอัปเดตการพึ่งพา และความสามารถที่ตั้งใจสูญเสีย
- เผยแพร่บัญชีการลบพร้อมหลักฐานผู้สมัคร ผลทดสอบ เจ้าของการตัดสินใจ งานติดตาม และความเสี่ยงที่ยังไม่ได้แก้ไข แทนการประกาศว่าโค้ดตายจากผลค้นหาเพียงอย่างเดียว
เตรียมสิ่งนี้
ข้อมูลที่แมวจะขอ
- คลังโค้ดและสภาพแวดล้อมที่รองรับ
- ข้อกำหนดด้านพฤติกรรมและความเข้ากันได้
- บัญชีการพึ่งพาและ abstraction
- สถานะฐานของการทดสอบ บิลด์ และประสิทธิภาพ
เราเตอร์ + playbook เดียว
จัดเส้นทางก่อน เลือกอันเดียว
Cat Paw โหลด playbook เดียวต่องาน ไม่ผสมหลายอัน เริ่มที่เราเตอร์นี้ เส้นทางที่เหลือเป็นตัวเลือกเฉพาะ workflow
- เราเตอร์:
minimal-code-pack skills/minimal-code-pack/dependency-abstraction-removal-audit/SKILL.md
เส้นเขต
ขอบเขตเดินทางไปกับพรอมต์
- ก่อนเริ่ม ให้ตรวจสอบเครื่องมือ บัญชี สิทธิ์ และพื้นที่ทำงานจริง ห้ามอ้างว่ามีเครื่องมือ บัญชี แหล่งข้อมูล หรือความสามารถที่ไม่พร้อมใช้งาน
- ใช้ Latch/target-workspace สำหรับโค้ดส่วนตัว ผลงาน การตรวจสอบสด หรือข้อมูลที่ไม่เป็นสาธารณะ หากไม่มีสิทธิ์เข้าถึง ให้หยุดที่ขอบเขตและรายงานสิ่งกีดขัด แทนการเดา
- หยุดเพื่อขออนุมัติอย่างชัดเจนก่อนการดำเนินการภายนอกที่มีผลกระทบ แล้วส่งกลับหลักฐาน ความเสี่ยงที่ยังไม่ได้แก้ไข สมมติฐาน และการดำเนินการใดที่ยังรอการอนุมัติ
เสร็จหมายถึง
จุดจบที่ตรวจได้
การตรวจสอบการลบที่ผ่านการทดสอบระบุการลดความซับซ้อนอย่างปลอดภัย รักษาพฤติกรรมที่จำเป็น บันทึกสถานะฐานและการตัดสินใจของผู้สมัครแต่ละรายการ และเปิดเผยความเสี่ยงที่ยังไม่ได้แก้ไข
แหล่งที่มา
กระบวนการนี้มาจากไหน
- github.com/DietrichGebert/ponytail/tree/e3ba2aa6f1e6f0bc4d69eb09c9f0d0a93af56156/
- docs.github.com/en/code-security/supply-chain-security/understanding-your-software-supply-chain/about-dependency-review
- docs.npmjs.com/cli/v11/commands/npm-uninstall
แหล่งที่มาตั้งรูปแบบของ workflow โพสต์ Reddit และชุมชน ถ้ามี ให้ถือเป็นเรื่องเล่าจากผู้ปฏิบัติ ไม่ใช่ข้อเท็จจริงสากล