Исследователи MIT предлагают новую модель для создания читаемого модульного ПО

Исследователи из Лаборатории компьютерных наук и искусственного интеллекта MIT (CSAIL) представили новый подход к разработке программного обеспечения, который обещает сделать код более модульным, прозрачным и понятным. Их метод разбивает системы на «концепции» — отдельные компоненты системы, каждый из которых выполняет одну задачу хорошо, и «синхронизации» — явные правила, которые описывают, как именно эти компоненты взаимодействуют друг с другом.

Проблема фрагментации функциональности

Основная проблема современного программного обеспечения, которую выявляют исследователи, — это «фрагментация функциональности». В большинстве современных систем одна функция никогда не является полностью самостоятельной. Например, добавление кнопки «поделиться» в социальной платформе вроде Instagram затрагивает не один сервис. Её функциональность распределена между кодом, который обрабатывает публикации, уведомления, аутентификацию пользователей и многое другое. Все эти части, несмотря на то что они разбросаны по коду, должны быть тщательно согласованы, и любое изменение рискует вызвать непреднамеренные побочные эффекты в других местах.

Профессор Дэниел Джексон называет это «фрагментацией функциональности» — центральным препятствием для надёжности программного обеспечения. «Способ, которым мы создаём программное обеспечение сегодня, не локализует функциональность. Вы хотите понять, как работает «обмен», но вам приходится искать это в трёх или четырёх разных местах, и когда вы находите это, связи похоронены в низкоуровневом коде», — говорит Джексон.

Концепции и синхронизации

Концепции и синхронизации призваны решить эту проблему. Концепция объединяет одну связную часть функциональности, такую как обмен, лайки или подписки, вместе с её состоянием и действиями, которые она может выполнять. Синхронизации, с другой стороны, описывают на более высоком уровне, как эти концепции взаимодействуют. Вместо написания грязного низкоуровневого кода интеграции разработчики могут использовать небольшой предметно-ориентированный язык, чтобы прямо прописывать эти связи. В этом DSL правила просты и понятны: действие одной концепции может запускать другую, так что изменение в одном состоянии может быть синхронизировано с другим.

«Думайте о концепциях как о модулях, которые полностью чисты и независимы. Синхронизации затем действуют как контракты — они говорят точно, как концепции должны взаимодействовать. Это мощно, потому что это делает систему одновременно проще для понимания людьми и проще для инструментов вроде LLM для правильной генерации», — говорит Джексон.

Этот подход напоминает мне старую добрую модульность, но доведённую до логического завершения. Интересно, что именно сейчас, в эпоху AI-кодинга, мы возвращаемся к фундаментальным принципам читаемости кода. Похоже, что LLM оказались тем самым катализатором, который заставил нас переосмыслить, как мы вообще должны писать код, чтобы его могли понимать не только люди, но и машины.

Преимущества и применения

Преимущества выходят за рамки ясности. Поскольку синхронизации являются явными и декларативными, их можно анализировать, проверять и, конечно, генерировать с помощью LLM. Это открывает дверь к более безопасной, автоматизированной разработке программного обеспечения, где AI-ассистенты могут предлагать новые функции без внесения скрытых побочных эффектов.

В своём исследовании команда назначила такие функции, как лайки, комментарии и обмен, каждой своей концепции — похоже на микросервисную архитектуру, но более модульную. Без этого паттерна эти функции были разбросаны по многим сервисам, что затрудняло их обнаружение и тестирование. Используя подход концепций и синхронизаций, каждая функция стала централизованной и читаемой, в то время как синхронизации точно описывали, как концепции взаимодействуют.

Исследование также показало, как синхронизации могут выносить общие проблемы, такие как обработка ошибок, форматирование ответов или постоянное хранение. Вместо встраивания этих деталей в каждый сервис, синхронизация может обрабатывать их один раз, обеспечивая согласованность по всей системе.

Будущие направления

Возможны и более продвинутые направления. Синхронизации могли бы координировать распределённые системы, поддерживая реплики на разных серверах в шаге, или позволять общим базам данных чисто взаимодействовать. Ослабление семантики синхронизации могло бы обеспечить eventual consistency, сохраняя при этом ясность на архитектурном уровне.

Джексон видит потенциал для более широкого культурного сдвига в разработке программного обеспечения. Одна из идей — создание «каталогов концепций», общих библиотек хорошо протестированных, предметно-ориентированных концепций. Разработка приложений могла бы тогда стать меньше связанной со сшиванием кода с нуля и больше с выбором правильных концепций и написанием синхронизаций между ними. «Концепции могли бы стать новым видом высокоуровневого языка программирования, с синхронизациями как программами, написанными на этом языке».

«Это способ сделать связи в программном обеспечении видимыми, — говорит Джексон. — Сегодня мы скрываем эти связи в коде. Но если вы можете видеть их явно, вы можете рассуждать о программном обеспечении на гораздо более высоком уровне. Вам всё ещё приходится иметь дело с присущей сложностью взаимодействия функций. Но теперь это на виду, не разбросано и не скрыто».