АссистентНовый вопросИсторияОбласти знаний
Партнёрские проектыСпецпроектыСтать автором
Сменить язык
О РУВИКИ

Программирование в большом и программирование в малом

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

Термины были введены Фрэнком ДеРемером и Хансом Кроном в их статье 1975 года «Programming-in-the-large versus programming-in-the-small»[1], где авторы утверждали, что это по сути разные виды деятельности: обычные языки программирования и практика структурного программирования хорошо подходят для «программирования в малом», но не решают задачи «программирования в большом». Для программирования в большом, по мнению авторов, требуется специальный «язык межмодульных связей» (MIL), обеспечивающий надёжное объединение модулей, сокрытие информации и проверку согласованности[2].

Эти понятия соотносятся с более поздней дихотомией Остерхаута, которая различает языки системного программирования (для компонентов) и языки сценариев (для связующего кода).

Теоретические основы

Фред Брукс отметил, что процесс создания индивидуальной программы существенно отличается от создания «программного системного продукта»[3]. Первая обычно выполняет одну относительно простую задачу, разрабатывается одним инженером, является законченной и готова к запуску в среде разработки; на неё затрачено немного времени. Такую деятельность ДеРемер и Крон определяют как программирование в малом.

Иначе обстоит дело с проектами создания программных систем (по определению Брукса): в них участвуют средние или большие промышленные команды, работают над проектом от нескольких месяцев до лет. Проект зачастую состоит из множества (иногда сотен) отдельных модулей, по сложности сравнимых с индивидуальными программами, описанными выше, но каждый модуль определяет интерфейс взаимодействия с другими модулями.

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

В рамках этой концепции Брукс (в книге «Мифический человеко-месяц») приводит матрицу эволюции, описывающую переход от простой программы к программному системному продукту с соответствующим ростом трудоёмкости. Если базовая стоимость разработки простой программы принимается за единицу (1x), то создание программного продукта (протестированного и задокументированного) увеличивает затраты в 3 раза. Разработка конечного программного системного продукта, объединяющего характеристики программного продукта и программной системы, требует в 9 раз больше трудозатрат по сравнению с базовой программой[4].

Программирование в большом

В разработке программного обеспечения программирование в большом может означать разработку программ большими коллективами либо небольшими группами на протяжении долгого времени[3]. Любое из этих условий приводит к созданию больших и сложных программ, сложно понимаемых сопровождающими.

При программировании в большом руководители разработки делают акцент на разбиении работы на модули с чётко определёнными взаимодействиями[5], что требует тщательного планирования и документирования.

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

Программирование в большом требует управленческих навыков: построение абстракций здесь направлено не только на описание работоспособного решения, но и на управление деятельностью всей команды[5].

Термин был введён Фрэнком ДеРемером и Хансом Кроном в их статье «Programming-in-the-Large Versus Programming-in-the-Small», IEEE Trans. on Soft. Eng. 2(2), 1975[5][6].

Согласно их работе, ключевое различие между этими подходами заключается в том, что программирование в большом представляет собой создание крупных систем из множества независимых модулей, тогда как программирование в малом — это написание самих этих модулей. Для объединения модулей в единое целое, формальной фиксации архитектуры и проверки её согласованности в рамках программирования в большом необходим специальный «язык межмодульных связей» (Module Interconnection Language, MIL), в то время как для программирования в малом используются обычные языки программирования. Кроме того, крупные системы создаются усилиями множества людей, а отдельные модули разрабатываются так, чтобы их логика была полностью понятна одному человеку[5][6].

Инструменты и технологии

В терминах информатики программирование в большом часто связано с созданием кода, реализующего логику переходов между состояниями системы (например, когда нужно ждать сообщений, посылать сообщения, компенсировать неудавшиеся не-ACID транзакции и т. д.). Для управления длительными бизнес-транзакциями применяется паттерн Saga, который разделяет операцию на последовательность локальных транзакций и использует компенсирующие транзакции при сбоях[7].[8].

На смену языкам, созданным с расчётом на программирование в большом (таким как BPEL), пришли современные платформы оркестрации — Temporal, AWS Step Functions и Camunda[9].

Важную роль в контрактном программировании играют современные языки описания интерфейсов (IDL), такие как OpenAPI и gRPC. Они определяют строгие границы ответственности и форматы взаимодействия между компонентами распределённых систем[10][11].

Для описания и документирования программной архитектуры применяются специализированные инструменты моделирования на базе модели C4 (например, Structurizr), реализующие подход «архитектура как код»[12].

Программирование в малом

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

Программирование в малом чаще осуществляется индивидуально или малыми группами за короткий срок и зачастую сопряжено с менее формализованным процессом (например, меньшее внимание к документированию и тестированию), выбором инструментов и языков программирования (например, предпочтение слабо типизированного языка сценариев вместо строго типизированного языка). Такой подход характерен и для прототипирования программ или приоритетного быстрого развития приложения над стабильностью и корректностью.

В информатике программирование в малом связано с краткосрочным поведением программ, обычно выполняющихся в рамках одной ACID-транзакции и работающих с локальными ресурсами — файлами, базами данных и т.д.

Развитие генеративного искусственного интеллекта и инструментов автодополнения кода привело к росту автономности ИИ-агентов в задачах программирования в малом. Несмотря на расширение возможностей ИИ-ассистентов, полная автоматизация рутинных задач пока не достигнута. Искусственный интеллект способен генерировать код и исправлять баги, однако часто не понимает причин их возникновения и может создавать собственные ошибки. В результате человек по-прежнему остаётся необходимым звеном в цикле разработки: участие разработчика критически важно для управления контекстом, оценки рисков, контроля безопасности и поддержания качества кода[13]..

Примечания

  1. ↑ DeRemer, Frank. Programming-in-the large versus programming-in-the-small // Proceedings of the international conference on Reliable software : [англ.] / Frank DeRemer, Hans Kron. — Association for Computing Machinery, 1 апреля 1975. — Vol. 10. — P. 114–121. — doi:10.1145/800027.808431.
  2. ↑ Programming-in-the-Large versus Programming-in-the-Small. Springer Link. Дата обращения: 27 августа 2026.
  3. ↑ 1 2 3 Брукс Ф. П., младший. (1982). «The Tar Pit» в сборнике The Mythical Man-Month – Anniversary Edition. ISBN 0-201-83595-9
  4. ↑ The Mythical Man-Month: Matrix of Evolution. University of California, Irvine. Дата обращения: 27 августа 2026.
  5. ↑ 1 2 3 4 Programming-in-the-Large Versus Programming-in-the-Small. Springer (1975). Дата обращения: 27 августа 2026.
  6. ↑ 1 2 Programming-in-the-Large Versus Programming-in-the-Small. ACM Digital Library (1975). Дата обращения: 27 августа 2026.
  7. ↑ Паттерн Saga. Proselyte.net (15 мая 2023). Дата обращения: 27 августа 2026.
  8. ↑ Saga. Microservices.io. Chris Richardson (1 января 2018). Дата обращения: 27 августа 2026.
  9. ↑ Temporal Alternatives. Akka.io. Lightbend (20 марта 2024). Дата обращения: 27 августа 2026.
  10. ↑ Открытые и закрытые API: сравнительный анализ и области применения. APNI.ru. APNI (10 июня 2024). Дата обращения: 27 августа 2026.
  11. ↑ Проектирование API для микрослужб. Microsoft Learn. Microsoft (1 января 2024). Дата обращения: 27 августа 2026.
  12. ↑ Best C4 Model Tools in 2026. Archyl. Archyl (1 января 2026). Дата обращения: 27 августа 2026.
  13. ↑ Как искусственный интеллект помогает разрабатывать программное обеспечение. TAdviser. Дата обращения: 27 августа 2026.

Литература

  • DeRemer, Frank; Kron, Hans (1975). “Programming-in-the large versus programming-in-the-small”. Proceedings of the international conference on Reliable software [англ.]. Лос-Анджелес, Калифорния: Association for Computing Machinery: 114—121. DOI:10.1145/800027.808431. Дата обращения 2024-06-15. |access-date= требует |url= (справка)

Категории