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

October 19, 2025

Введение

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

Warning:

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

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

TL;DR — ключевые выводы

  • Статистически достоверные и практически значимые факторы поддерживаемости:
    • отсутствие циклов между модулями, пакетами и в модели данных;
    • соблюдение Interface Segregation Principle (ISP);

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

      Все три фактора показывают устойчивую положительную или отрицательную связь как по χ²-анализу, так и в ML-моделях (LogReg + RandomForest).

  • Погранично значимые факторы: применение ER-диаграмм; соблюдение CQS и принципов дизайна компонентов (ADP, SDP и др.); минимизация синхронных вызовов между сервисами; использование (микро)сервисной архитектуры; высокий процент покрытия тестами и раннее тестирование; наличие гайдлайна разработки.
  • Статистически слабые, но показательные тренды: проекты с простыми моделями данных и простыми способами доступа (агрегаты, SQL, лёгкие ORM) чаще воспринимаются как поддерживаемые; применение «детройтской школы тестирования» повышает уверенность в тестах.

  • Ложные ожидания: SRP, OCP, LSP, модульные монолиты, парадигма (ООП/ФП/ПП), школа тестирования и запрет прямых обращений из контроллеров к репозиториям не показали достоверного влияния на поддерживаемость.

    DIP оказывает статистически достоверный и практически значимый отрицательный эффект — проекты, где его декларировали, чаще оказывались проблемными.

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

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

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

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

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

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

  • JVM/Java — 33 (50.8%)
  • JVM/Kotlin — 7 (10.8%)
  • .NET/C= — 6 (9.2%)
  • Go — 5 (7.7%)
  • Python — 5 (7.7%)

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

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

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

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

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

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

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

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

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

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

Для оценки факторов поддерживаемости использовались два взаимодополняющих подхода:

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

Сила статистической связи

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

p-value — вероятность получить такое или более экстремальное значение χ² при отсутствии реальной связи. Связь считается статистически значимой при p < 0.05.

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

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

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

Погранично значимая связь — p в диапазоне 0.05–0.15 и Cramer’s V > 0.2. Это не достоверность, но указание на тренд, заслуживающий внимания.

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

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

Практическая значимость факторов

Чтобы проверить, насколько статистические факторы действительно влияют на воспринимаемую поддерживаемость, применены модели машинного обучения: логистическая регрессия и случайный лес (5×20-fold OOF, AUC, PR-AUC, Brier). По каждому фактору анализировались монотоничность (PDP), устойчивость результатов и калибровка вероятностей.

Практическая значимость трактуется так:

  • если фактор стабилен в повторных сплитах (AUC > 0.7 ± 0.05) и даёт монотоничный тренд в PDP → он считается практически значимым;
  • если AUC ≈ 0.6–0.7 или тренд слабый → пограничная значимость;
  • при AUC < 0.6 или хаотичных трендах → практической значимости нет.

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

Рекомендации, основанные на статистически достоверных факторах с подтверждённой практической значимостью

Соблюдать Interface Segregation Principle.

  • Очень сильная, статистически и практически значимая связь с поддерживаемостью (χ² ≈ 23.51, p ≈ 0.00027, Cramer’s V ≈ 0.63; AUC ≈ 0.73 ± 0.04).
  • Чем чаще команда следует ISP, тем выше вероятность, что проект воспринимается как поддерживаемый.
  • ML-анализ подтверждает монотоничный рост вероятности поддерживаемости при увеличении частоты следования принципу.
  • Интерпретация: ISP снижает связанность и когнитивную сложность — один из самых сильных предикторов поддерживаемости.

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

  • Циклы между классами, пакетами, модулями, сервисами
    • Сильная и статистически значимая связь (χ² ≈ 11.49, p ≈ 0.042, Cramer’s V ≈ 0.44; AUC ≈ 0.76 ± 0.04).
    • ML-модели показывают тот же устойчивый отрицательный тренд.
    • Интерпретация: циклы архитектурного уровня — достоверный анти-фактор; должны устраняться при ревью и рефакторинге.
  • Циклы (двунаправленные связи) в модели данных
    • Сильная, близкая к статистической значимости (χ² ≈ 11.01, p ≈ 0.051, Cramer’s V ≈ 0.44; AUC ≈ 0.74 ± 0.04).
    • ML-модели показывают тот же устойчивый отрицательный тренд.
    • Интерпретация: двунаправленные связи на уровне сущностей ухудшают локализацию изменений и читаемость модели.

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

  • Статистически и практически значимая положительная связь (χ² ≈ 10.25, p ≈ 0.034, Cramer’s V ≈ 0.48; AUC ≈ 0.72 ± 0.05).
  • Чем чаще применялись шаблоны, тем выше вероятность, что проект воспринимался как поддерживаемый.
  • ML-результаты подтверждают монотоничный рост вероятности с ростом частоты применения.
  • Интерпретация: шаблоны полезны, пока служат структурированию и изоляции ответственности, а не становятся самоцелью.

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

Применять 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).
  • Чем выше доля асинхронного взаимодействия, тем выше поддерживаемость.

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

  • Умеренная, погранично значимая связь (χ² ≈ 7.42, p ≈ 0.07, Cramer’s V ≈ 0.41).
  • В поддерживаемых проектах тесты чаще писались на этапе разработки, а в неподдерживаемых — после релиза или не писались вовсе.
  • Итог: чем раньше пишутся тесты, тем выше поддерживаемость проекта.

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

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

Оптимизировать среднее время прогона одного теста в цикле разработки.

  • Сильная, погранично значимая связь (χ² = 6.529, p = 0.0885, Cramer’s V = 0.533).
  • В поддерживаемых проектах чаще встречалось среднее время одного теста 2–10 с (10 из 3) и 10–60 с (2 из 2); в неподдерживаемых преобладали 0–1 с (5 неподдерживаемых из 7).
  • Интерпретация: «ультрабыстрые» тесты нередко оказываются излишне изолированными и малоинформативными; умеренно «тяжёлые» тесты (меньше моков, больше реального взаимодействия компонентов) повышают уверенность и коррелируют с поддерживаемостью.

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

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

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

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

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

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

Применять реактивное программирование прагматично и точечно.

  • Погранично значимая, умеренная связь (χ² = 7.4906, p = 0.1121, Cramer’s V = 0.3759).
  • Распределение: в поддерживаемых проектах встречались ответы «редко/иногда/часто» и «не знаю/не помню»; в неподдерживаемых преобладало «никогда».
  • Интерпретация: реактивный подход сам по себе не делает проект более/менее поддерживаемым; избирательное применение для IO‑bound задач, стриминга и backpressure не снижает поддерживаемость и иногда коррелирует с лучшим восприятием.

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

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

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

Детройтская школа тестирования повышает уверенность в тестах

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

Работа с БД через 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).
  • Доля поддерживаемых проектов по типам подходов:
    • Плоская модель (таблица = структура) — ≈ 73%,
    • DDD-агрегаты (связь по ID) — ≈ 71%,
    • Единый граф сущностей — ≈ 57%,
  • Интерпретация: простые и явно структурированные модели данных — агрегаты и плоские структуры — дают долю поддерживаемых проектов выше среднего по выборке (64,1%). Напротив, модель единого графа сущностей, характерная для проектов с ORM-ами, демонстрирует долю поддерживаемых проектов ниже среднего.

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

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

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

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

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

Все принципы SOLID одинаково и независимо повышают поддерживаемость

  • Мультифакторная логистическая регрессия по пяти признакам SOLID (N = 60) показала, что модель в целом значима (LLR p ≈ 0.0095; Pseudo R² ≈ 0.193).
  • Независимый положительный эффект показал только ISP: β ≈ 0.74, OR ≈ 2.09, 95% CI OR ≈ [1.01; 4.33], p ≈ 0.048.
  • DIP — отрицательный и статистически значимый предиктор: β ≈ −0.96, OR ≈ 0.38, 95% CI OR ≈ [0.18; 0.81], p ≈ 0.012.
  • OCP: β ≈ 0.49, OR ≈ 1.63, p ≈ 0.173; LSP: β ≈ 0.045, OR ≈ 1.05, p ≈ 0.884; SRP: β ≈ −0.37, OR ≈ 0.69, p ≈ 0.381 — самостоятельного статистически значимого эффекта не показали.
  • Интерпретация: в парных (χ²) анализах OCP/LSP выглядят значимыми, но в совместной модели их эффект частично объясняется ковариацией с ISP; утверждение «все принципы SOLID одинаково важны» не подтверждается. Наиболее устойчиво с поддерживаемостью связан ISP; чрезмерная и ранняя инверсия зависимостей (DIP) без архитектурной дисциплины может ухудшать воспринимаемую поддерживаемость — применять адресно и осознанно.

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

  • Связь между закрытой архитектурой (запрет обхода слоёв) и восприятием поддерживаемости статистически незначима (χ² ≈ 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).
  • Интерпретация: важнее наличие тестов и их достаточность, чем конкретный стиль.

Ограничения и угрозы валидности

  • Размер выборки: N ≈ 60 — пилотная, исследовательская выборка; результаты трактуем как ассоциации/сигналы, требующие репликации на большей выборке;
  • Субъективность переменных: зависимая переменная — восприятие поддерживаемости; независимые — самоотчёт о практиках (шкалы «никогда/редко/…»). Возможны различия трактовок и смещения памяти/соц. желательности;
  • Неоднородность проектов: индустрии, стеки, возраст и размеры различаются; это повышает дисперсию оценок;
  • Множественные проверки: множество гипотез повышает риск ложноположительных; p-values приводятся без корректировки, ключевые выводы подтверждаются несколькими метриками (χ², Cramer’s V, логистика с OR/CI);

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

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