Mission Driven Development
Місія як четверта основа архітектури програмного забезпечення.
Більшість програм запитують, як щось побудувати. Mission Driven Development (MDD) додає одне питання спочатку: навіщо ми це будуємо і чи відповідає цей вибір даній меті? CIRIS був побудований саме так, тому етика є частиною дизайну, а не правилом, доданим після.
Чотирикомпонентна модель
Три структурні ніжки, що підтримують одне цілеспрямоване сидіння.
Традиційні методології програмного забезпечення зупиняються на трьох: як система працює, що вона представляє і хто з ким спілкується. MDD додає четверту основу, якій підпорядковані інші три. Без сидіння ніжки — просто ніжки.
Ніжка 1: ЯК
Логіка
Шаблони реалізації, сервісні архітектури, алгоритми.
Ніжка 2: ЩО
Схеми
Структури даних, системи типів, правила валідації.
Ніжка 3: ХТО
Протоколи
Контракти інтерфейсів, шаблони комунікації, межі сервісів.
Сидіння: НАВІЩО
Місія
Об'єктивна етична система, яка визначає мету та обмеження системи.
Основний принцип
Постійна узгодженість.
Кожне архітектурне рішення повинно демонструвати узгодженість із заявленою місією. Логіка перевіряється: чи це служить місії? Схеми валідуються: чи підтримують ці структури даних цілі місії? Протоколи оцінюються: чи дозволяють ці інтерфейси виконати місію?
Вимоги до системи місії
Що потрібно місії, щоб бути несучою.
1. Об'єктивна етична основа
- Вимірювані принципи, а не декларативні цінності
- Чіткі алгоритми вирішення компромісів
- Плюралістичний підхід у різних культурних контекстах
- Аудитоване етичне обґрунтування
2. Визначення мета-цілі
- Надає рекомендації для прийняття рішень в умовах невизначеності
- Автоматично відфільтровує суперечливі пропозиції
- Забезпечує Узгодженість поведінки між компонентами
- Стабільна попри зміни в реалізації
3. Операційна інтеграція
- Кожен сервіс обґрунтовує своє існування
- Схеми відображають інформаційні форми місії
- Протоколи забезпечують поведінку, узгоджену з місією
- Тести перевіряють узгодженість з місією, а не лише функціональність
Шаблони реалізації
Кожна ніжка має питання, на яке мусить відповісти.
Архітектура сервісів
визначення місії → відповідальності сервісів → контракти інтерфейсів → реалізація
- Узгодженість з місією: як цей сервіс просуває мета-ціль?
- Обґрунтування меж: чому ця відповідальність потребує окремого сервісу?
- Необхідність інтерфейсу: які критично важливі для місії взаємодії уможливлює цей протокол?
Проектування схем
вимоги місії → інформаційна модель → система типів → правила валідації
- Відповідність місії: яку критично важливу для місії інформацію це фіксує?
- Поведінкові обмеження: як ці типи забезпечують поведінку, узгоджену з місією?
- Шлях розвитку: як ця схема може адаптуватися, зберігаючи узгодженість з місією?
Специфікація протоколів
взаємодії місії → вимоги до комунікації → визначення контракту → реалізація
- Контекст місії: яку критично важливу для місії комунікацію це забезпечує?
- Застосування обмежень: як цей інтерфейс запобігає поведінці, що порушує місію?
- Компонованість: як ці контракти поєднуються в системи, узгоджені з місією?
Інтеграція сталого розвитку
Довгострокова узгодженість з місією вимагає підтримуваного темпу.
Заходи проти ефекту Гудгарта
- Регулярні аудити узгодженості реалізації з місією
- Вимірювання виконання місії, а не маніпульованих замінників
- Відхилення доповнень, що не зміцнюють місію
Робота в ритмі
- Сесії, узгоджені з ритмами продуктивності
- Вбудовані точки вибору для переузгодження
- Сталий темп як вимога першого класу
Безперервна валідація
- Регулярне осмислення необхідності компонентів
- Постійна перевірка того, що поведінка відповідає місії
- Автоматичне виявлення змін, що порушують місію
Ворота якості
Ворота, що не відкриються без обґрунтування місії.
Рецензування коду
- Потрібне пояснення узгодженості з місією
- Перевірка обмежень
- Інтеграція повинна зміцнювати загальну Узгодженість
Тестування
- Функціональна коректність
- Перевірка узгодженості з місією
- Тести на відмову від порушень етичних меж
- Стійкість обмежень під навантаженням
Документація
- Контекст місії для кожного компонента
- Обґрунтування етичних компромісів
- Як обмеження формують реалізацію
Режими відмови
Як MDD ламається і як залишається цілим.
Дрейф місії
Симптом: накопичуються функції, що не служать основній місії. Зменшення: регулярні архітектурні огляди з узгодженістю місії як воротами.
Вибух складності
Симптом: система стає непридатною до обслуговування через зайву складність. Зменшення: відхилення доповнень, якщо вони не зміцнюють виконання місії.
Етична непослідовність
Симптом: компоненти застосовують етичне обґрунтування непослідовно. Зменшення: централізована етична система зі спільними шаблонами реалізації.
Плутанина в цілях
Симптом: члени команди втрачають зв'язок між технічними рішеннями і місією. Зменшення: постійне навчання прийняттю рішень, орієнтованих на місію.
Практичний приклад
CIRIS як опрацьований зразок.
CIRIS (Core Identity, Integrity, Resilience, Incompleteness, Signalling Gratitude) — система, яка розвивалась разом з MDD. Місія — Мета-ціль M-1: сприяти сталій адаптивній Узгодженості, що дає різноманітним розумним істотам можливість прагнути до процвітання.
Результати архітектури
- 22 сервіси, кожен обґрунтований вимогами місії
- Перевірено 200+ API-ендпоінтів
- 10 000+ тестів з мінімальною кількістю нетипізованих структур даних у виробничому середовищі
- Філософія Ubuntu, вбудована в проектування протоколів
- Мудре відкладення (Wisdom-Based Deferral), що запобігає порушенням місії (про безпеку)
- Виробниче розгортання для модерації спільнот у Discord
Ключові фактори успіху
- Чітка мета-ціль: M-1 надає однозначні критерії для прийняття рішень
- Операційна етика: принципи УГОДИ (Accord) реалізовані як обмеження коду (читати УГОДУ)
- Сталий розвиток: супутник Grace забезпечує здорові ритми
- Постійна валідація: кожне архітектурне рішення перевіряється
Рекомендації щодо впровадження
Як почати з того місця, де ви є.
Для нових проектів
- Визначте чітку місію з вимірюваними етичними принципами до написання коду
- Встановіть мета-ціль, яка надає рекомендації для прийняття рішень
- Проектуйте архітектуру так, щоб обмеження місії знаходилися на фундаментальному рівні
- Налагодьте безперервну валідацію узгодженості між місією та технічними рішеннями з першого дня
Для існуючих проектів
- Проведіть аудит поточної архітектури на наявність неявних припущень щодо місії
- Сформулюйте явну місію, яка пояснює наявні шаблони проектування
- Визначте порушення місії в поточній реалізації
- Заплануйте поступове узгодження з пріоритетом за впливом на місію
Передумови для команди
- Відданість об'єктивному етичному обґрунтуванню
- Готовність відхиляти елегантні рішення, які не служать місії
- Переконаність, що обмеження місії створюють, а не обмежують хорошу архітектуру
- Практики сталого розвитку, що зберігають довгострокову спрямованість
Куди це веде
MDD підходить не для кожного проекту.
MDD призначений для систем, де етична поведінка є критично важливою для місії і де довгострокова надійність важливіша за короткострокову швидкість розробки функцій. Для таких систем MDD забезпечує шлях від етичних намірів до операційної реальності із застосуванням такої ж інженерної дисципліни до місії, як і до коду.
Початкові витрати реальні, поки команда опановує прийняття рішень, орієнтованих на місію. Накопичувальна віддача — в розробці, що настає далі: система координат прояснює архітектурні вибори замість того, щоб примножувати їх.