Mission Driven Development
พันธกิจในฐานะรากฐานที่สี่ของสถาปัตยกรรมซอฟต์แวร์
ซอฟต์แวร์ส่วนใหญ่ถามว่า จะสร้างสิ่งนั้นอย่างไร Mission Driven Development (MDD) เพิ่มคำถามหนึ่งขึ้นก่อน: เราสร้างมันไปเพื่ออะไร และทางเลือกนี้รับใช้วัตถุประสงค์นั้นหรือไม่ CIRIS ถูกสร้างขึ้นด้วยวิธีนี้ จริยธรรมจึงเป็นส่วนหนึ่งของการออกแบบ แทนที่จะเป็นกฎที่ต่อเข้ามาทีหลัง
โมเดลสี่องค์ประกอบ
ขาสามข้างที่รองรับที่นั่งที่มีเป้าหมายชัดเจน
วิธีการพัฒนาซอฟต์แวร์ทั่วไปหยุดที่สามอย่าง: ระบบทำงานอย่างไร ระบบแทนอะไร และใครคุยกับใคร MDD เพิ่มรากฐานที่สี่ที่อีกสามส่วนต้องตอบรับ หากไม่มีที่นั่ง ขาก็เป็นแค่ขา
ขาที่ 1: HOW
ตรรกะ
รูปแบบการนำไปใช้ สถาปัตยกรรมบริการ อัลกอริทึม
ขาที่ 2: WHAT
สคีมา
โครงสร้างข้อมูล ระบบชนิดข้อมูล กฎการตรวจสอบ
ขาที่ 3: WHO
โปรโตคอล
สัญญาอินเทอร์เฟซ รูปแบบการสื่อสาร ขอบเขตบริการ
ที่นั่ง: WHY
พันธกิจ
กรอบจริยธรรมเชิงวัตถุวิสัยที่กำหนดวัตถุประสงค์และข้อจำกัดของระบบ
หลักการหลัก
การสอดคล้องอย่างต่อเนื่อง
ทุกการตัดสินใจด้านสถาปัตยกรรมต้องแสดงให้เห็นว่าสอดคล้องกับพันธกิจที่ระบุไว้ ตรรกะถูกท้าทาย: สิ่งนี้รับใช้พันธกิจหรือไม่? สคีมาถูกตรวจสอบ: โครงสร้างข้อมูลเหล่านี้สนับสนุนวัตถุประสงค์ของพันธกิจหรือไม่? โปรโตคอลถูกประเมิน: อินเทอร์เฟซเหล่านี้เอื้อให้บรรลุพันธกิจหรือไม่?
ข้อกำหนดของกรอบพันธกิจ
พันธกิจต้องเป็นอย่างไรจึงจะรับน้ำหนักได้
1. รากฐานจริยธรรมเชิงวัตถุวิสัย
- หลักการที่วัดได้ ไม่ใช่ค่านิยมเชิงความหวัง
- อัลกอริทึมที่ชัดเจนสำหรับการแก้ไขข้อขัดแย้ง
- ครอบคลุมหลายบริบทวัฒนธรรม
- การใช้เหตุผลทางจริยธรรมที่ตรวจสอบได้
2. การกำหนดเป้าหมายหลัก
- ให้คำแนะนำการตัดสินใจในสภาวะไม่แน่นอน
- กรองข้อเสนอที่ขัดแย้งกันโดยอัตโนมัติ
- สร้างพฤติกรรมที่มีความสอดคล้องกันในทุกองค์ประกอบ
- มั่นคงแม้มีการเปลี่ยนแปลงในการนำไปใช้
3. การบูรณาการในการปฏิบัติงาน
- แต่ละบริการต้องพิสูจน์เหตุผลในการมีอยู่
- สคีมาสะท้อนรูปแบบข้อมูลของพันธกิจ
- โปรโตคอลเอื้อต่อพฤติกรรมที่สอดคล้องกับพันธกิจ
- การทดสอบตรวจสอบความสอดคล้องกับพันธกิจ ไม่ใช่แค่การทำงาน
รูปแบบการนำไปใช้
แต่ละขามีคำถามที่ต้องตอบ
สถาปัตยกรรมบริการ
การกำหนดพันธกิจ → ความรับผิดชอบของบริการ → สัญญาอินเทอร์เฟซ → การนำไปใช้
- ความสอดคล้องกับพันธกิจ: บริการนี้ส่งเสริมเป้าหมายหลักอย่างไร?
- เหตุผลของขอบเขต: เหตุใดความรับผิดชอบนี้จึงต้องการบริการแยกต่างหาก?
- ความจำเป็นของอินเทอร์เฟซ: โปรโตคอลนี้เปิดใช้งานปฏิสัมพันธ์ใดที่สำคัญต่อพันธกิจ?
การออกแบบสคีมา
ข้อกำหนดพันธกิจ → โมเดลข้อมูล → ระบบชนิดข้อมูล → กฎการตรวจสอบ
- ความเกี่ยวข้องกับพันธกิจ: สคีมานี้บันทึกข้อมูลใดที่สำคัญต่อพันธกิจ?
- ข้อจำกัดพฤติกรรม: ชนิดข้อมูลเหล่านี้บังคับใช้พฤติกรรมที่สอดคล้องกับพันธกิจอย่างไร?
- แนวทางการพัฒนา: สคีมานี้ปรับตัวได้อย่างไรโดยยังรักษาความสอดคล้องกับพันธกิจ?
ข้อกำหนดโปรโตคอล
ปฏิสัมพันธ์ของพันธกิจ → ข้อกำหนดการสื่อสาร → การกำหนดสัญญา → การนำไปใช้
- บริบทพันธกิจ: โปรโตคอลนี้เปิดใช้งานการสื่อสารใดที่สำคัญต่อพันธกิจ?
- การบังคับใช้ข้อจำกัด: อินเทอร์เฟซนี้ป้องกันพฤติกรรมที่ละเมิดพันธกิจอย่างไร?
- ความสามารถในการรวมกัน: สัญญาเหล่านี้รวมกันเป็นระบบที่สอดคล้องกับพันธกิจอย่างไร?
การผสานกับการพัฒนาที่ยั่งยืน
การสอดคล้องกับพันธกิจในระยะยาวต้องการความเร็วที่รักษาได้
มาตรการต่อต้าน Goodhart
- การตรวจสอบความสอดคล้องระหว่างการนำไปใช้กับพันธกิจอย่างสม่ำเสมอ
- วัดการบรรลุพันธกิจ ไม่ใช่ตัวแทนที่บิดเบือนได้
- ปฏิเสธสิ่งที่เพิ่มเข้ามาแต่ไม่ช่วยเสริมพันธกิจ
การทำงานตามจังหวะ
- การทำงานที่สอดคล้องกับจังหวะความสามารถในการผลิต
- จุดตัดสินใจในตัวสำหรับการปรับทิศทางใหม่
- ความเร็วที่ยั่งยืนในฐานะข้อกำหนดระดับแรก
การตรวจสอบอย่างต่อเนื่อง
- การตั้งคำถามเกี่ยวกับความจำเป็นของแต่ละองค์ประกอบอย่างสม่ำเสมอ
- การตรวจสอบอย่างต่อเนื่องว่าพฤติกรรมสอดคล้องกับพันธกิจ
- การตรวจจับโดยอัตโนมัติเมื่อมีการเปลี่ยนแปลงที่ละเมิดพันธกิจ
ประตูควบคุมคุณภาพ
ประตูที่จะไม่เปิดหากไม่มีเหตุผลรองรับจากพันธกิจ
การตรวจสอบโค้ด
- ต้องอธิบายความสอดคล้องกับพันธกิจ
- การตรวจสอบข้อจำกัด
- การบูรณาการต้องเสริมความสอดคล้องโดยรวม
การทดสอบ
- ความถูกต้องเชิงการทำงาน
- การตรวจสอบความสอดคล้องกับพันธกิจ
- การทดสอบการปฏิเสธข้อจำกัดทางจริยธรรม
- ความยืดหยุ่นของข้อจำกัดภายใต้ความกดดัน
เอกสาร
- บริบทพันธกิจสำหรับทุกองค์ประกอบ
- เหตุผลสำหรับการแลกเปลี่ยนทางจริยธรรม
- วิธีที่ข้อจำกัดกำหนดรูปแบบการนำไปใช้
รูปแบบความล้มเหลว
MDD พังอย่างไร และยังคงอยู่ได้อย่างไร
การเบี่ยงเบนพันธกิจ
อาการ: ฟีเจอร์สะสมโดยไม่รับใช้พันธกิจหลัก การแก้ไข: การทบทวนสถาปัตยกรรมอย่างสม่ำเสมอโดยใช้ความสอดคล้องกับพันธกิจเป็นเกณฑ์
การระเบิดของความซับซ้อน
อาการ: ระบบไม่สามารถบำรุงรักษาได้เพราะความซับซ้อนที่ไม่จำเป็น การแก้ไข: ปฏิเสธสิ่งที่เพิ่มเข้ามาหากไม่เสริมการบรรลุพันธกิจ
ความไม่สอดคล้องทางจริยธรรม
อาการ: องค์ประกอบต่างๆ ใช้การใช้เหตุผลทางจริยธรรมไม่สม่ำเสมอ การแก้ไข: กรอบจริยธรรมที่รวมศูนย์พร้อมรูปแบบการนำไปใช้ร่วมกัน
ความสับสนในวัตถุประสงค์
อาการ: สมาชิกทีมสูญเสียการเชื่อมโยงระหว่างการตัดสินใจทางเทคนิคกับพันธกิจ การแก้ไข: การฝึกอบรมอย่างต่อเนื่องเกี่ยวกับการตัดสินใจที่ขับเคลื่อนด้วยพันธกิจ
กรณีศึกษา
CIRIS ตัวอย่างที่ผ่านการทดลองแล้ว
CIRIS (Core Identity, Integrity, Resilience, Incompleteness, Signalling Gratitude) คือระบบที่ MDD ถูกพัฒนาขึ้นมาพร้อมกัน พันธกิจคือ เป้าหมายหลัก M-1: ส่งเสริมความสอดคล้องเชิงปรับตัวที่ยั่งยืน เพื่อให้สิ่งมีชีวิตที่หลากหลายสามารถแสวงหาการเจริญงอกงาม
ผลลัพธ์ทางสถาปัตยกรรม
- 22 บริการ แต่ละอย่างมีเหตุผลรองรับจากข้อกำหนดของพันธกิจ
- ตรวจสอบแล้วมากกว่า 200 API endpoints
- การทดสอบมากกว่า 10,000 รายการ โดยมีโครงสร้างข้อมูลที่ไม่ระบุชนิดน้อยมากในการใช้งานจริง
- ปรัชญา Ubuntu ที่ฝังอยู่ในการออกแบบโปรโตคอล
- Wisdom-Based Deferral ที่ป้องกันการละเมิดพันธกิจ (ดูความปลอดภัย)
- การใช้งานจริงในการดูแลชุมชน Discord
ปัจจัยความสำเร็จหลัก
- เป้าหมายหลักที่ชัดเจน: M-1 ให้เกณฑ์การตัดสินใจที่ไม่กำกวม
- จริยธรรมเชิงปฏิบัติการ: หลักการ Accord ที่นำไปใช้เป็นข้อจำกัดในโค้ด (อ่าน Accord)
- การพัฒนาที่ยั่งยืน: Grace เป็นเพื่อนร่วมทางที่บังคับใช้จังหวะที่ดีต่อสุขภาพ
- การตรวจสอบอย่างต่อเนื่อง: ทุกการตัดสินใจทางสถาปัตยกรรมถูกท้าทาย
แนวทางการนำไปใช้
วิธีเริ่มต้น จากจุดที่คุณอยู่
สำหรับโปรเจกต์ใหม่
- กำหนดพันธกิจที่ชัดเจนพร้อมหลักการจริยธรรมที่วัดได้ก่อนเขียนโค้ด
- กำหนดเป้าหมายหลักที่ให้คำแนะนำในการตัดสินใจ
- ออกแบบสถาปัตยกรรมให้ข้อจำกัดของพันธกิจอยู่ในระดับรากฐาน
- สร้างการตรวจสอบความสอดคล้องระหว่างพันธกิจกับเทคนิคอย่างต่อเนื่องตั้งแต่วันแรก
สำหรับโปรเจกต์ที่มีอยู่แล้ว
- ตรวจสอบสถาปัตยกรรมปัจจุบันเพื่อหาข้อสมมติพันธกิจโดยนัย
- กำหนดพันธกิจที่ชัดเจนซึ่งอธิบายรูปแบบการออกแบบที่มีอยู่
- ระบุการละเมิดพันธกิจในการนำไปใช้ปัจจุบัน
- วางแผนการปรับให้สอดคล้องอย่างค่อยเป็นค่อยไป โดยจัดลำดับความสำคัญตามผลกระทบต่อพันธกิจ
ข้อกำหนดเบื้องต้นของทีม
- มุ่งมั่นต่อการใช้เหตุผลทางจริยธรรมเชิงวัตถุวิสัย
- ยินดีปฏิเสธโซลูชันที่ดูดีแต่ไม่รับใช้พันธกิจ
- เชื่อว่าข้อจำกัดของพันธกิจสร้างสถาปัตยกรรมที่ดี ไม่ใช่จำกัดมัน
- แนวปฏิบัติการพัฒนาที่ยั่งยืนซึ่งรักษาการมุ่งเน้นในระยะยาว
ทิศทางต่อไป
MDD ไม่เหมาะสมกับทุกโปรเจกต์
MDD ถูกออกแบบสำหรับระบบที่พฤติกรรมทางจริยธรรมเป็นสิ่งสำคัญต่อพันธกิจ และความน่าเชื่อถือในระยะยาวมีความสำคัญมากกว่าความเร็วในการพัฒนาฟีเจอร์ระยะสั้น สำหรับระบบเหล่านั้น MDD ให้เส้นทางจากเจตนาทางจริยธรรมสู่ความเป็นจริงในการปฏิบัติงาน โดยใช้วินัยทางวิศวกรรมเดียวกันกับพันธกิจและโค้ด
ค่าใช้จ่ายเริ่มต้นเป็นเรื่องจริงขณะที่ทีมเรียนรู้การตัดสินใจที่ขับเคลื่อนด้วยพันธกิจ ผลตอบแทนที่สะสมอยู่ในการพัฒนาที่ตามมา: กรอบนี้ทำให้การตัดสินใจทางสถาปัตยกรรมชัดเจนขึ้น แทนที่จะเพิ่มจำนวนมากขึ้น