Отчёт: факторы поддерживаемости backend-проектов

October 19, 2025

Введение

В этом отчёте приведены результаты анализа данных исследования «Характеристики поддерживаемых кодовых баз backend-приложений».

Warning:

Задача анализа полученных данных оказалась неподъёмной для нашей команды энтузиастов. Поэтому этот отчёт практически полностью составлен GPT-5 на основе анализа, выполненного им же.

Если у вас есть квалификация, возможность и желание выполнить профессиональный анализ наших данных - напишите мне пожалуйста в Telegram.

TL;DR — ключевые инсайты отчёта

  • Статистически достоверные факторы поддерживаемости: отсутствие циклов в зависимостях, соблюдение ISP, OSP, LSP, разумное применение шаблонов проектирования;
  • Погранично значимые факторы: применение ER-диаграмм; соблюдение CQS, SRP и принципов дизайна компонентов (ADP, SDP и др.); использование (микро)сервисной архитектуры и минимизация синхронных вызовов между сервисами; высокий процент покрытия тестами и раннее тестирование; наличие гайдлайна разработки;
  • Статистически слабые, но показательные тренды: применение ограниченных контекстов; применение DDD-агрегатов и чистого SQL или легковесных ORM-ов; применение DIP;
  • Ложные ожидания: закрытые слои (запрет обращений к репозиториям из контроллеров), модульные монолиты, парадигма (ООП/ФП/ПП) и школа тестирования не оказывают достоверного влияния на поддерживаемость;
  • Общие выводы: поддерживаемость определяется архитектурной дисциплиной, ранним тестированием и простотой модели данных.

Характеристика исследованных проектов

Общее количество наблюдений: 59

Индустрии проектов (топ-5 по частоте)

  • Финтех (банки, инвестиции, страхование) — 23 (35.9%)
  • другое — 9 (14.1%)
  • Промышленность / IoT / автоматизация — 5 (7.8%)
  • Телекоммуникации — 4 (6.2%)
  • Здравоохранение / Медтех — 4 (6.2%)

Стек технологий (топ-5)

  • JVM/Java — 33 (51.6%)
  • JVM/Kotlin — 7 (10.9%)
  • .NET/C= — 5 (7.8%)
  • Go — 5 (7.8%)
  • Python — 5 (7.8%)

Возраст проектов на момент начала работы респондента: медиана — 20 мес.

Размер кодовой базы (включая тесты): медиана — 100 тыс. строк

Количество таблиц/коллекций во всех хранилищах данных: медиана — 50

Среднее количество разработчиков в команде: медиана — 5 человек

Типичный проект из выборки

Финтех-проект (35.9%) на Java или Kotlin (51.6 + 10.9%) со Spring Boot (37%) и PostgreSQL (30.4%), в промышленной эксплуатации (79.2%) и разработке около двух лет. Объём кода порядка ста тысяч строк, микросервисная архитектура системы и слоёная архитектура приложений. Количество таблиц — порядка нескольких десятков. Команда из 5 человек.

Такой портрет описывает наиболее частый случай в выборке и вы можете ориентироваться на него, оценивая применимость рекомендаций отчёта к вашим проектам.

Допущение о поддерживаемости

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

Статистический ликбез

Для оценки статистической достоверности связи между переменными в исследовании применяются классические методы анализа категориальных данных. Они позволяют определить, насколько наблюдаемые различия между группами (например, поддерживаемые и неподдерживаемые проекты) можно считать случайными или отражающими реальную зависимость. В отчёте используются три ключевых показателя — χ² (хи-квадрат), p-value и Cramer’s V — которые в совокупности показывают наличие, значимость и силу связи между изучаемыми факторами.

χ² (хи-квадрат) — статистический критерий, показывающий, насколько наблюдаемое распределение ответов отличается от того, которое ожидалось бы при отсутствии связи между переменными. Чем выше χ², тем сильнее различие между группами.

p-value (уровень значимости) — вероятность получить такое (или более экстремальное) значение χ², если связи между переменными на самом деле нет. Чем меньше p-value, тем меньше вероятность, что наблюдаемые различия случайны. Здесь мы связь считаем статистически значимой при p < 0.05.

Cramer’s V — мера силы связи между категориальными переменными. Ориентировочные границы значений:

  • 0.1–0.2 — слабая связь;
  • 0.2–0.4 — умеренная;
  • 0.4–0.6 — сильная;
  • > 0.6 — очень сильная.

Таким образом, сочетание трёх показателей даёт полную картину: χ² указывает, что различия есть, p-value — насколько они случайны, а Cramer’s V — насколько сильна связь.

Погранично значимая связь — это ситуация, когда p-value немного выше стандартного порога 0.05 (диапазоне 0.05–0.15). Такие результаты нельзя считать статистически достоверными, но они указывают на возможную тенденцию или тренд, заслуживающий внимания и дополнительной проверки.

Показательные (качественные) тренды — это наблюдаемые закономерности, не подтверждённые статистически, но устойчиво проявляющиеся в данных. Они отражают вероятные тенденции, которые требуют дополнительной проверки, но уже дают основание для практических выводов. Такие тренды часто сопровождаются высоким значением Cramer’s V > 0.2 при p-value 0.15-0.45 или заметным различием в процентах между группами.

Как писать поддерживаемые кодовые базы backend-приложений

Рекомендации, основанные на статистически достоверных факторах

Соблюдать Interface Segregation Principle, Liskov Substitution Principle и Open/Closed Principle.

  • Interface Segregation Principle (ISP)
    • Очень сильная и статистически значимая связь с поддерживаемостью (χ² ≈ 23.51, p ≈ 0.00027, Cramer’s V ≈ 0.63).
    • В поддерживаемых проектах принцип соблюдался почти всегда: при ответах «часто», «иногда» и «всегда» подавляющее большинство систем оценивались как поддерживаемые. Напротив, ответы «редко» и «никогда» почти полностью соответствовали неподдерживаемым проектам.
  • Open/Closed Principle (OCP)
    • Сильная, статистически значимая связь (χ² ≈ 13.6, p ≈ 0.018, Cramer’s V ≈ 0.48).
    • Поддерживаемые проекты чаще следовали принципу открытости/закрытости — особенно при ответах «часто» и «всегда»; при ответах «никогда» и «редко» доля поддерживаемых резко снижалась.
  • Liskov Substitution Principle (LSP)
    • Сильная, статистически значимая связь (χ² ≈ 12.26, p ≈ 0.031, Cramer’s V ≈ 0.46).
    • В поддерживаемых проектах LSP соблюдался заметно чаще (особенно при ответах «часто» и «иногда»), тогда как нарушения принципа были характерны для неподдерживаемых систем.

Избегать циклов в зависимостях.

  • Один из самых сильных факторов.
  • Отсутствие циклов в зависимостях — как между классами, пакетами и модулями, так и в модели данных — достоверно связано с более высокой поддерживаемостью (χ² ≈ 11.64, p ≈ 0.04, Cramer’s V ≈ 0.45; χ² ≈ 11.18, p ≈ 0.048, Cramer’s V ≈ 0.44 соответственно).

Применять шаблоны проектирования осознанно.

  • Сильная, статистически значимая зависимость (χ² ≈ 10.25, p ≈ 0.034, Cramer’s V ≈ 0.48).
  • Чем чаще применялись шаблоны проектирования, тем выше вероятность, что проект воспринимался как поддерживаемый.
  • Наиболее устойчивый эффект наблюдается при ответе «часто»: доля поддерживаемых проектов максимальна.
  • Крайние варианты («всегда» и «никогда») дают нестабильные результаты из-за малого числа наблюдений.
  • Интерпретация: шаблоны полезны, пока не становятся самоцелью; важен баланс между структурой и ясностью кода.

Рекомендации, основанные на погранично значимых факторах

Применять ER-диаграммы при проектировании доменной модели.

  • Сильная, погранично значимая связь (χ² ≈ 10.7, p ≈ 0.06, Cramer’s V ≈ 0.45).
  • В поддерживаемых проектах ER-диаграммы применялись заметно чаще: особенно при ответах «часто» и «иногда».
  • В неподдерживаемых проектах преобладали ответы «никогда» и «редко».
  • Интерпретация: визуальное моделирование помогает удерживать целостность домена и коммуникацию между разработчиками, что повышает восприятие поддерживаемости.

Использовать микросервисную или гибридную (цитадельную) архитектуру.

  • Умеренная, погранично значимая связь (χ² ≈ 3.6, p ≈ 0.06, Cramer’s V ≈ 0.25).
  • В выборке микросервисная архитектура умеренно положительно коррелирует с восприятием проекта как поддерживаемого.

Ограничивать синхронные связи между сервисами.

  • Умеренная, статистически незначимая связь (χ² ≈ 6.68, p ≈ 0.25, Cramer’s V ≈ 0.35).
  • Чем выше доля асинхронного взаимодействия, тем выше поддерживаемость.

Следовать принципам дизайна компонентов (REP, CCP, CRP, ADP, SDP, SAP).

  • Сильная, погранично значимая связь (χ² ≈ 9.95, p ≈ 0.08, Cramer’s V ≈ 0.41).
  • В поддерживаемых проектах принципы дизайна компонентов применялись заметно чаще.
  • Интерпретация: применение принципов REP, CCP, CRP, ADP, SDP и SAP способствует структурированности и снижению связности, что положительно влияет на поддерживаемость.

Следовать принципу Command Query Separation (CQS).

  • Сильная, погранично значимая связь (χ² ≈ 12.7, p ≈ 0.09, Cramer’s V ≈ 0.45).
  • Соблюдение CQS чаще наблюдается в поддерживаемых проектах.
  • При ответах «часто» и «иногда» проекты почти всегда воспринимались как поддерживаемые.
  • При «никогда» — преимущественно как неподдерживаемые.
  • Интерпретация: принцип CQS снижает сложность и повышает предсказуемость кода.

Взвешенно подходить к выделению интерфейсов классов.

  • Сильная, погранично значимая связь (χ² ≈ 9.55, p ≈ 0.09, Cramer’s V ≈ 0.41).
  • В поддерживаемых проектах интерфейсы часто, но не всегда имели единственную реализацию, тогда как в неподдерживаемых — либо «всегда» (избыточные абстракции), либо «редко» (анемичные интерфейсы).
  • Интерпретация: уместное применение интерфейсов способствует поддерживаемости.

Обеспечивать высокое покрытие тестами.

  • Очень сильная связь (практически значимая, хотя формально чуть выше порога 0.05, χ² ≈ 26.3, p ≈ 0.11, Cramer’s V ≈ 0.70).
  • Чем выше процент покрытия тестами, тем чаще проект воспринимался как поддерживаемый.
  • Проекты с покрытием более 60–70% почти всегда оценивались как поддерживаемые.
  • Интерпретация: тесты — один из сильнейших факторов восприятия поддерживаемости, особенно когда они создают уверенность в изменениях.

Писать тесты до или одновременно с реализацией.

  • На каком этапе (проектирование, разработка, QA и т. п.) писалась бо́льшая часть тестов
    • Умеренная, погранично значимая связь (χ² ≈ 7.42, p ≈ 0.12, Cramer’s V ≈ 0.38).
    • В поддерживаемых проектах тесты чаще писались на этапе разработки, а в неподдерживаемых — после релиза или не писались вовсе.
  • В какой момент писались тесты во время этапа разработки
    • Сильная, но статистически незначимая связь (χ² ≈ 4.91, p ≈ 0.43, Cramer’s V ≈ 0.43).
    • Поддерживаемые проекты чаще создавали тесты до или вместе с кодом, а неподдерживаемые — после.
  • Итог: чем раньше пишутся тесты, тем выше поддерживаемость проекта.

Вести документ с гайдлайном разработки проекта.

  • Умеренная, погранично значимая связь (χ² ≈ 10.7, p ≈ 0.14, Cramer’s V ≈ 0.31).
  • В поддерживаемых проектах чаще встречались минимальные или средней детализированности гайдлайны, а также иногда исчерпывающие.
  • В неподдерживаемых проектах чаще отсутствовал какой-либо документ или он был устаревшим.
  • Интерпретация: наличие хоть какого-то актуального документа с гайдлайнами связано с более высокой вероятностью восприятия проекта как поддерживаемого.

Соблюдать Single Responsibility Principle.

  • Умеренная, погранично значимая связь (χ² ≈ 7.98, p ≈ 0.157, Cramer’s V ≈ 0.37).
  • В поддерживаемых проектах SRP применялся заметно чаще, особенно при ответах «часто» и «всегда».
  • Интерпретация: принцип единственной ответственности способствует изоляции изменений и облегчает понимание кода.

Статистически недостоверные, но показательные тренды

Применение агрегатов, привлечение экспертов предметной области и разбиение проекта на ограниченные контексты повышает поддерживаемость

  • Ни одна из идей DDD не показала статистически значимой или сильной связи с поддерживаемостью (все p > 0.11, а Cramer’s V < 0.20).
  • Однако слабые положительные тренды наблюдаются:
    • для явных агрегатов (χ² ≈ 2.27, p ≈ 0.13, Cramer’s V ≈ 0.20);
    • для участия экспертов предметной области (χ² ≈ 1.43, p ≈ 0.23, Cramer’s V ≈ 0.16);
    • для ограниченных контекстов (χ² ≈ 0.86, p ≈ 0.35, Cramer’s V ≈ 0.12).
  • Интерпретация: поддерживаемые проекты чаще используют агрегаты и контекстное разделение, что соответствует более зрелому применению DDD.

Работа с БД через SQL/легковесные ORM-ы повышает поддерживаемость

  • Умеренно слабая связь (χ² = 3.98, p-value = 0.27, Cramer’s V = 0.26).
  • Доля поддерживаемых проектов:
    • «Сырые» SQL-запросы — ≈ 90%;
    • SQL-DSL / query builder-подход — *≈ 67%;
    • ORM с ленивой загрузкой и отслеживанием состояния — ≈ 58%.
  • Интерпретация: все технологии работы с БД обеспечивают долю поддерживаемых проектов выше 50%. Однако ORM-подходы демонстрируют наименьшую поддерживаемость — доля поддерживаемых проектов при их использовании ниже среднего уровня по выборке (64.1%). В то же время проекты, использующие прямой SQL или лёгкие DSL-обёртки, напротив, показывают долю поддерживаемых систем выше среднего по выборке, что указывает на положительное влияние простоты и прозрачности слоя доступа к данным.

Представление модели данных в приложении

  • Умеренная, статистически незначимая связь (χ² ≈ 2.5, p ≈ 0.47, Cramer’s V ≈ 0.22).
  • Доля поддерживаемых проектов по типам подходов:
    • Единый граф сущностей — ≈ 57%,
    • DDD-агрегаты (связь по ID) — ≈ 71%,
    • Плоская модель (таблица = структура) — ≈ 73%,
  • Интерпретация: простые и явно структурированные модели данных — агрегаты и плоские структуры — дают долю поддерживаемых проектов выше среднего по выборке (64,1%). Напротив, модель единого графа сущностей, характерная для проектов с ORM-ами, демонстрирует долю поддерживаемых проектов ниже среднего.

Контроль количества зависимостей между модулями бизнес-логики повышает поддерживаемость

  • Умеренная, но статистически незначимая связь (χ² ≈ 8.27, p ≈ 0.37, Cramer’s V ≈ 0.35)
  • Поддерживаемые проекты чаще имели 2–5 зависимостей на модуль.
  • Неподдерживаемые проекты чаще имели 8 и более зависимостей.
  • Интерпретация: чрезмерная связанность ухудшает поддерживаемость.

Использование статических анализаторов кода повышает поддерживаемость

  • Слабая и статистически незначимая связь (χ² ≈ 3.28, p ≈ 0.20, Cramer’s V ≈ 0.24).
  • Проекты с анализаторами чаще оценивались как поддерживаемые.
  • Интерпретация: вероятно, это отражение общей зрелости процессов, а не прямой фактор поддерживаемости.

Сетап фикстуры в интеграционных тестов на уровне слоя доступа к данным (Repository/DAO) повышает поддерживаемость

  • Ни один из способов не показал статистически значимой связи с поддерживаемостью (χ² ≈ 2.17, p ≈ 0.14, Cramer’s V ≈ 0.19).
  • Незначительный тренд: проекты, где фикстуры подготавливались через Repository/DAO, чаще воспринимались как поддерживаемые.
  • Подготовка фикстур через сервисы, контроллеры или внешние API не давала преимуществ.

Соблюдать Dependency Inversion Principle.

  • Умеренная, но статистически незначимая связь (χ² ≈ 5.99, p ≈ 0.307, Cramer’s V ≈ 0.32).
  • Влияние DIP на поддерживаемость не подтверждено статистически, хотя качественно наблюдается тренд: в поддерживаемых проектах DIP встречался чаще.
  • В выборке их соблюдение не оказывает значимого влияния на восприятие поддерживаемости.

Использовать Детройтскую школу повышает уверенность в тестах

  • Умеренная, статистически незначимая связь (χ² ≈ 7.84, p ≈ 0.25, Cramer’s V ≈ 0.28).
  • Уверенность в тестах несколько выше при Детройтском стиле (проверка состояния и выходных данных), чем при Лондонском (проверка взаимодействий).
  • Интерпретация: тесты, проверяющие состояние системы, дают чуть больше уверенности в надёжности.

Развенчанные мифы

Запрет вызовов через слои (обращение к репозиториям из контроллеров, например) повышает поддерживаемость

  • Связь между закрытой архитектурой (запрет обхода слоёв) и восприятием поддерживаемости статистически незначима (χ² ≈ 0.18, p ≈ 0.67, Cramer’s V ≈ 0.08).
  • Формально связь статистически незначима, однако открытая архитектура встречалась в поддерживаемых проектах чуть чаще (10 против 5 случаев).

ООП/ФП/нужное подчеркнуть даёт более поддерживаемый код

  • Не имеет достоверного эффекта (χ² ≈ 1.37, p ≈ 0.85, Cramer’s V ≈ 0.15).
  • Интерпретация: ключевое не в парадигме, а в архитектурной дисциплине.

Модульные монолиты повышают поддерживаемость

  • В среднем не улучшает поддерживаемость (χ² ≈ 1.02, p ≈ 0.31, Cramer’s V ≈ 0.13).
  • Интерпретация: часто модули не изолированы и нарушают свои границы, что сводит эффект к нулю.

Детройтская школа тестирования повышает поддерживаемость

  • Ни Лондонская (проверка взаимодействий), ни Детройтская (проверка состояния) школа не показали преимуществ в восприятии поддерживаемости (χ² ≈ 0.45, p ≈ 0.8, Cramer’s V ≈ 0.09).
  • Интерпретация: важнее наличие тестов и их достаточность, чем конкретный стиль.

Исходные данные

Файл с исходными данными, а также Python-скрипты анализа некоторых из характеристик доступны в репозитории исследования.