Привет!

Вы, возможно, уже забыли, что мы проводим исследование "Характеристики поддерживаемых кодовых баз backend-приложений", а я — нет:)

Во-первых, ещё раз призываю вас заполнить нашу анкету если ещё не заполнили или впервые о ней слышите — если будут ещё ответы, я повторю анализ и обновлю отчёт и его выводы будут ещё более достоверными. Нам особенно не хватает анкет о неподдерживаемых проектах и не из мира Java/Kotlin/ООП - если у вас есть такой проект, он будет вдвойне ценен.

Во-вторых, с радостью представляю вам первые результаты анализа данных!:)

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

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

Ну и сразу TL;DR, там есть очень неожиданные для меня пункты:

— Статистически достоверные и практически значимые факторы поддерживаемости:
— отсутствие циклов между модулями, пакетами и в модели данных;
— соблюдение Interface Segregation Principle (ISP);
— осознанное применение шаблонов проектирования.
Все три фактора показывают устойчивую положительную или отрицательную связь как по χ²-анализу, так и в ML-моделях (LogReg + RandomForest).

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

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

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

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