Большой продукт сложен в поддержке и сколько разработчиков не бери, всё равно качество кода будет страдать.

Причины:

• сроки
• отсутствие тестов
• поверхностное код-ревью
• отсутствие контроля техдолга

Технический долг - это как невыплаченный кредит: когда разработчики берут "заем" времени, выбирая быстрые и простые решения для достижения цели, но забывают вернуть его обратно, оставляя за собой задолженность в виде неоптимизированного кода.

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

Поговорим о том как контроллировать техдолг.

Основная информация

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

Краткие возможности:

• Выявление потенциальных ошибок, такие как неправильное использование переменных, типов или функций.
• Поддержание стандартов кодирования.
• Анализ производительности, обнаружение участков кода, которые могут вызвать утечки памяти или замедлить производительность приложения.
• Управление техническим долгом, контроль метрик. Также с помощью плагинов, можно например ставить задачи в Jira на исправление участка кода.
• Сохраняет историю метрик качества кода
• Интеграция с IDE, Jira

Отличие от линтеров

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

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

Почему не хватит ESLint, TSLint, Stylelint?

Например для ESLint можно подключить плагин eslint-plugin-sonarjs, который также сможет обнаруживать баги, code smells и т.д.

Но теряется главное преимущество SonarQube – отслеживание эволюции кода в дашбордах с настройкой quality gate и подсвечиванием проблем в динамике.

Также, ESLint, TSLint, Stylelint заточены на определенные языковые эвристики, а SonarQube оценивает картину целиком, например, может найти утекший секрет в CI-конфигурации. Покрыть такой кейс линтером довольно сложно.

Линтеры являются хорошим инструментом, но они должны использоваться в сочетании с другими практиками и инструментами, такими как код-ревью, тестирование (e2e, sl, unit), анализ безопасности и регулярную работу над техдолгом, чтобы обеспечить достойное качество кода на протяжении всего жизненного цикла продукта.

Аналоги и альтернативы

Среди похожих решение есть CodeScene, CodeCov. Также есть статические анализаторы вроде PVS Studio, но он не работает с экосистемой JS/TS.

CodeScene выделяется своей способностью анализа эволюции кода и предсказания будущих изменений. Но к сожалению, у него нет Community Edition (бесплатен для open source) и для получения ключа нужен VPN (не работает в РФ).

CodeCov больше про покрытие кода тестами.

Поэтому SonarQube является более выигрышным из-за Community Edition, а также обширного набор инструментов для оценки качества кода, покрытия и т.д.

Плюсы и минусы

Плюсы

• Статический анализ кода – выявляет ошибки, code smells и потенциальные уязвимости.
• Множество поддерживаемых языков (зависит от версии - community, developer, enterprise, data)
• Интеграция с CI системами
• Дашборды и отчеты
• Интеграция сторонних линтеров

Минусы

• Ресурсозатратность – запуск полного анализа проекта может занимать длительное время
• Сложность настройки – перед внедрением нужно тщательно обдумать какие папки анализировать, какие исключить из анализы, подкрутить правила. Также присутствует некоторая специфичность к версии Java.
• Не всегда точные результаты – результаты анализы могут давать ложные срабатывания или пропуски, и иногда требуется ручная проверка.
• Слабая ролевая модель – довольно неудобно настраивать права доступа, назначать фикс багов на определенных людей

Экосистема

У SonarQube отличная экосистема плагинов как платных, так и бесплатных.

Например, интеграция с Jira, PDF-отчеты. Есть на что посмотреть.

sonarqube-community-branch-plugin

В Community Edition нет анализа веток. Но можно использовать плагин sonarqube-community-branch-plugin.

sonar-gitlab-plugin

С помощью плагина sonar-gitlab-plugin можно оставлять комментарии к МР.

Интеграция с IDE

Плагин SonarLint доступен во всех популярных редакторах кода.

На примере VS Code, в данном случае редактор подсветит ошибку с подробным описанием, так же можно перейти прямо в анализатор в браузере и проверить историю.

Отличия версий

У SonarQube есть несколько версий. Подробнее о разнице версий тут.

• Community Edition
• Статический анализ кода для 19 языков
• Обнаружение ошибок и базовых уязвимостей
• Ревью security hotspots
• Отслеживание code smells и техдолга
• Метрики code quality и истории
• Интеграция CI/CD
• Плагины от сообщества
• Developer Edition
• Поддержка C, C++, Swift, Objective C, T-SQL, PL/SQL.
• Обнаружение сложных ошибок и уязвимостей
• Обнаружение ошибок крашей Python/Java
• Анализ Merge Requests
• Enterprise Edition
• PDF-отчеты
• Отчеты безопасности
• Нормативные отчеты
• Параллельная обработка репортов
• Data Center Edition
• Горизонтальное масштабирование
• Улучшенный перфоманс и high load

Типовые проблемы кодовой базы

Команда Sonarqube выделяет несколько "грехов" разработчиков:

• Баги и потенциальные баги
• Нарушение стандартов кодирования
• Дублирование кода
• Недостаточное покрытие модульными тестами
• Плохое распределение сложности
• Спагетти-дизайн
• Недостаточно или слишком много комментариев

Посмотрим, как SonarQube отслеживает эти проблемы.

Метрики SonarQube

В каждом анализе SonarQube есть несколько метрик.

Метрики оцениваются по шкале A до E, где E - наихудший рейтинг, говорящий о том, что был найден минимум один блокирующий баг.

Рассмотрим основные метрики.

Issues (Найденные проблемы)

Показывает найденные проблемы в коде

• 🐞 Bug — приоритетные ошибки, которые нужно исправить как можно скорее
• 💩 Code smell — незначительные огрехи, которые больше относятся к культуре кода и его оформлению
• 🔒 Vulnerability – уязвимости, связанные с безопасностью.
• 🛡️ Security HotSpot - потенциальные точки уязвимости

У каждой ошибки есть состояния:

• Открытые
• Переоткрытые
• Подтвержденные
• Ложные
• Won't fix

Security (Безопасность)

Это отдельная вкладка где собрана информация о количестве уязвимостей и их рейтинге безопасности (от A до E). Подробнее тут.

• A = 0 проблем
• B = как минимум 1 Minor проблема
• C = как минимум 1 Major проблема
• D = как минимум 1 Critical проблема
• E = как минимум 1 Blocker проблема

Reliability (Надежность)

SonarQube анализирует код на предмет надежности, выявляя проблемы, которые могут привести к сбоям, ошибкам выполнения, или другим нежелательным результатам при работе программы.

Maintainability (Поддерживаемость)

Во вкладке Measures в разделе Maintainability содержится информация о техническом долге в проекте.

• Duplications
• Technical debt
• Code complexity

Coverage (Покрытие тестами)

Во вкладке Measures в разделе Coverage собрана информация о покрытии кода тестами.

Может быть полезно для:

• Оценки качества тестирования
• Выявление неиспользуемого кода
• Стимулирование написания новых тестов

Duplications (Дублирование)

Во вкладке Measures в разделе Duplications можно найти информацию о наличии дублирующегося кода.

Настройка исключений для дублей

При настройке проекта нужно подумать над тем какие кейсы могут быть ложно-положительными и настройте исключения для них.

К таким же исключениям потенциально можно отнести любой автоген который хранится в репозитории, например, GQL-схемы.

Настройка проекта

Quality Profile (Профиль качества):

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

Quality Gate (Контроль качества):

• Это набор условий, которые определяют уровень качества кода, который необходим для успешного прохождения анализа.
• Включает в себя метрики, такие как покрытие кода тестами, процент дублирования кода, количество критических ошибок и т. д.
• Если код не соответствует установленным критериям качества, Quality Gate не проходит, и разработчики получают уведомления о необходимости исправлений.

Список правил

У SonarQube есть готовые правила валидации для разных языков. Основные правила работают из коробки.

Правила – это набор валидаций которые помогают найти баги, "code smells" и проблемы безопасности в ходе статистического анализа.

Список правил:

• JavaScript
• TypeScript
• CSS

Также можно добавлять свои правила (подробнее тут).

Интеграция сторонних линтеров

Для улучшения качества репортов SonarQube можно дать ему больше информации, например отчеты Stylelint, ESLint, TSLint через параметры.

• sonar.css.stylelint.reportPaths
• sonar.eslint.reportPaths
• sonar.typescript.tslint.reportPaths

Подробнее в документации.

Создание проекта в SonarQube

В UI SonarQube в разделе создания проекта, укажите ключ и название проекта.

Рекомендация: ключ должен совпадать с путем в Gitlab/Github. Например, путь в Gitlab gitlab.com/frontend/awesome-project, значит ключ awesome-project.

Создание токена

Рекомендация: используйте формат sonar-token-{PROJECT_KEY}. Например, sonar-token-awesome-project.

Настройка репозитория

Добавьте в .gitignore игнор файлов результатов анализа SonarQube.

# SonarQube
.sonar/
.scannerwork/ 

В корне репозитория нужно создать файл sonar-project.properties. В нем указываются основные проекты, такие как хост SonarQube, название и ключ проекта, папки для сканирования.

Описание всех параметров можно найти тут.

# Хост SonarQube
sonar.host.url=https://sonarqube.company.domain

# Ключ и название проекта
sonar.projectKey=awesome-project
sonar.projectName=awesome-project

# Список относительных путей, где хранится исходный код
sonar.sources=src

# Кодировка для проекта, обычно UTF-8
sonar.sourceEncoding=UTF-8

# Список относительных путей, которые необходимо исключить для анализа
sonar.exclusions=

# Список относительных путей, где хранятся тесты
sonar.tests=

# Ожидание завершения анализа на сервере (пригодится для вебхуков)
sonar.qualitygate.wait=true

Настройка в Gitlab CI

Это пример настройки в Gitlab CI.

Переменные sonar.login, sonar.projectVersion, sonar.projectDate передаются через аргументы CLI.

• sonar.login – токен, полученный при создании проекта в SonarQube.
• sonar.projectVersion – тег релиза, например CI_COMMIT_TAG
• sonar.projectDate – уникальная дата релиза. SonarQube выдаст ошибку если дата актуальной статы старше последней существующей статы. Например релизы 36.0.0 и 36.0.1 сделаны 01.10.2024, в таком случае SonarQube выдаст ошибкуValidation of project failed: Date of analysis cannot be older than the date of the last known analysis on this project. Value: "2023-10-01T07:02:00+0000". Latest analysis: "2024-10-01T07:01:57+0000". It's only possible to rebuild the past in a chronological order.

Пример джобы в Gitlab CI.

sonarqube-check:
  stage: check
  tags:
    - prod
  image:
    name: sonarsource/sonar-scanner-cli:4.8.1
    entrypoint: ['']
  cache: 
    key: '${CI_JOB_NAME}'
    paths:
      - .sonar/cache
  variables:
    SONAR_USER_HOME: '${CI_PROJECT_DIR}/.sonar'
    GIT_DEPTH: '0'
  script:
    - current_tag=${CI_COMMIT_TAG}
    - echo $current_tag
    - current_date=$(date -u +"%Y-%m-%dT%H:%M:%S%z")
    - echo $current_date
    - sonar-scanner -Dsonar.login=${SONAR_LOGIN} -Dsonar.projectVersion=$current_tag -Dsonar.projectDate=$current_date
  allow_failure: true
  rules:
    - if: $CI_COMMIT_BRANCH == "master"

Генерация истории статов

Для того чтобы сразу начать работу с техдолгом, нужно сгенерировать историю отчетов.

Для этого написан скрипт, который переходит в указанный репозиторий, перемещается по тегам релизов и сканирует релизы через sonar-scanner.

Сохраните скрипт index.js в любую папку на компьютере и выполните:

npm init
npm i simple-git

В переменной repositoryPath указывается путь до репозитория проекта.

В переменной sonarScannerCliPath указывается путь до sonar-scanner-cli. Скачать можно тут.

В объекте config указывается основная информация

• sonar.host.url - хост SonarQube
• sonar.login - токен проекта SonarQube
• sonar.projectKey - ключ проекта
• sonar.projectName - название проекта (рекомендую чтобы совпадал с ключом)
• sonar.sources - папки для сканирования

Далее для начала генерации отчетов запустите скрипт.

node index.js

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

Интеграция через вебхуки

А с помощью вебхуков можно настраивать различные автоматизации. Например, отчет о проверке релиза в чат команды.

На этом всё, надеюсь статья была полезной.

Если вам было интересно, подписывайтесь на телеграм-канал @trash_js – там я пишу более короткие заметки об экосистеме фронтенда и frontops. 🎩

Можно

• записать сообщение в топик
• прочитать записи из топика
• закоммитить место до которого дочитали

Ограничения

• нельзя удалить сообщение
• нельзя изменить сообщение
• поиск работает только по идентификатору

Компоненты

• Topic: категория сообщений по какому-то типу.
• Broker: кластер (нода).
• Producer: производители публикуют данные в топиках.
• Consumer: потребители это сервисы, которые подписываются на топики.
• Zookeeper: интерфейс координации между брокерами и потребителями Кафки.

Подробнее

Топик

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

Топик это по сути файл, лог. Топик разбит на партиции, нумеруются с нуля. А уже внутри партиции есть сообщения, в пределах одной партиции сообщения приходят по принципу FIFO, FIRST IN, FIRST OUT.

Кафка гарантирует что то что попало в Кафку, из нее не пропадет.

Брокер

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

Zookeeper

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

Отказоустойчивость

Такая устойчивость возникает за счёт репликаций партиций.

Каждый  брокер может быть для партиции лидирующим. И кроме того эти партиции реплицируются на соседние брокеры (по мере возможности). Таким образом запись идет на несколько нод в кластере.

Допустим один из брокеров упал. Что произойдет?

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

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

Сообщение

• Номер партиции - потому что сообщение отправляется не прямо в топик, а в конкретную партицию.
• Ключ - обычно байтовые значения или гуид. Так то неважно.
• Значение - полезная инфа.
• Заголовки - мета-данные.

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

Пропускная способность и время ожидания

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

Кафка-продюсер умеет группировать  сообщения. Мы можем настроить размер группы и время ожидания. По сути это как маршрутка :-)

Запись

Как убедиться что записи отправленные в Кафку вообще там сохранены?

Есть несколько режимов (acks)

• Простой режим, кафка просто подтверждает что сообщение дошло. Если упал брокер до записи сообщения, то сообщение потеряется.
• При записи. Подтверждаем запись только в момент записи на диск. На случай если хард отлетит.
• Бронебойный. Подтверждаем только когда сообщение реплицировались на все брокеры. Медленно, но гарантия ~100%.

Чем более параноидальный режим тем больше задержка и проблем. Можно отлететь по таймауту. И что выбирать зависит от задачи.

Чтение

Как устроено чтение? Каждый консьюмер входит в какую-то группу.

Если консьюмер один, он читает данные из всех партиций. Но что если данных слишком много?

Мы можем сделать больше консьюмеров. И кафка сама ребалансирует те партиции которые назначены на определенный консьюмер.

Но количество консьюмеров не должно быть больше чем количество партиций. Т.е. число партиций определяет максимальный параллелизм с которым мы можем обрабатывать данные.

Конечно мы можем сделать лишний, но он ничего не будет делать.

Про offset commit

Для надежного чтения предусмотрена такая вещь как офсет коммит.

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

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

Таким образом мы избавляемся от необходимости повторного чтения записей с самого начала, но мы не полностью гарантированы конечно от повторного чтения.

В кафке чтения это запись в служебный топик.

Retention policy

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

Как только заполняется сегмент, он удаляется.

Как это может выглядеть всё вмесчте

Полезности

Полезная книжка

Мотивация

• Единый стиль и понятность: Используя одинаковый формат коммитов, мы сделаем историю изменений более понятной. Каждый коммит будет иметь ясное обозначение типа изменения, области и краткое описание, что сразу даст представление о его смысле.
• Легкость поиска и навигации: Стандартизированные коммиты помогут быстрее находить связанные изменения и легче перемещаться по истории разработки. Проще отслеживать, что и когда менялось.
• Поддержка сотрудничества: Благодаря четким коммитам команда будет лучше понимать, что делает каждый разработчик. Это улучшает коммуникацию и управление проектом.
• Упрощение автоматизации: Стандартизированные коммиты помогут автоматизировать процессы сборки, тестирования и развертывания. Меньше возможности для ошибок и быстрее выпускать новые версии.
• Автоматическая документация: Коммиты могут быть использованы для создания автоматической документации. Так пользователи и разработчики быстро узнают, что нового в каждой версии проекта. Можно использовать standard-changelog.

Даже при условии сквоша коммитов в МР это полезно, потому что в истории МР будет структурированная история изменений, что упрощает код-ревью и отслеживание разработки фич. Также в Gitlab можно настроить шаблон для тела коммита.

Примеры стандартов

• Стандартная нотация
• Angular нотация

Предлагаемый формат коммитов

• type(scope): subject

Где:

• type — тип изменения, fix/feat/build/etc.
• scope — область, которую затронуло изменения, либо номер заявки. Если несколько, писать через запятую. Если вне заявок, пропустить.
• subject — краткое описание проделанной работы. С заглавной буквы. Описание коммитов должно отвечать на вопрос: «Что делает коммит?».

Тип изменения:

• feat - используется при добавлении новой функциональности приложения
• fix - если исправили какую-то багу
• refactor - рефакторинг кода приложения
• style - исправляем опечатки, исправляем форматирования
• chore - обычное обслуживание кода
• revert - отмена изменений
• perf - оптимизация кода, улучшение производительности
• docs - всё, что касается документации
• test - всё, что связано с тестированием
• build - всё, что связано с билдом
• ci - всё, что связано с процессом деплоя
• any - не входящее ни в одну из категорий

Пример коммитов, которые пройдут проверку

• feat(front): Внедрение проверки коммитов TASK-####
• fix(back): Исправил дедлок в репозитории TASK-####

Примеры коммитов, которые не пройдут проверку:

• Зарефакторил компонент к заявке 35487
• Удаление изменений по модальному окну

Пример настройки

Создать файл package.json в корне проекта (рядом с папкой .git), установить менеджер гит-хуков (husky, simple-git-hooks или git-hooks).

git init
npm i @commitlint/cli @commitlint/config-conventional husky --save-dev

Добавить в секцию с хуками хук "commit-msg": "commitlint -E HUSKY_GIT_PARAMS"

Пример package.json

{
  "name": "project-name",
  "version": "1.0.0",
  "description": "",
  "husky": {
    "hooks": {
      "commit-msg": "commitlint -E HUSKY_GIT_PARAMS"
    }
  },
  "devDependencies": {
    "@commitlint/cli": "^17.0.0",
    "@commitlint/config-conventional": "^17.0.0",
    "husky": "^8.0.0"
  }
}

Настроить формат коммитов в commitlint.config.js или оставить по умолчанию.

module.exports = {
	extends: ['@commitlint/config-conventional'],
	rules: {
		'body-leading-blank': [1, 'never'],

		'type-case': [2, 'always', 'lower-case'],
		'type-empty': [2, 'never'],
		'type-enum': [
			2,
			'always',
			[
				'build',
				'chore',
				'ci',
        			'devops',
				'docs',
				'feat',
				'fix',
				'perf',
				'refactor',
				'revert',
				'style',
				'test',
				'any'
			]
		],

		'scope-case': [2, 'always', 'lower-case'],

		'subject-case': [
			2,
			'always',
			['sentence-case']
		],
		'subject-empty': [2, 'never']
	}
};

Шаблоны Merge Requests

Также можно добавить шаблоны к Merge Requests. Это упростит процесс ревью и убедит всех участников, что необходимые проверки и тесты были выполнены перед слиянием

Мотивация

• Стандартизация и единообразие: Шаблоны для МР позволяют установить общие стандарты и правила для всех МР в проекте. Это способствует единообразию в оформлении, структуре и требованиях к каждому МР, что облегчает их понимание и улучшает качество кода.
• Улучшение коммуникации: Хорошо структурированные шаблоны помогают разработчикам четко описывать суть изменений в МР. Это улучшает коммуникацию в команде и снижает возможность недопонимания.
• Облегчение код-ревью: Шаблоны позволяют уточнить, какой код и какой функционал должны быть протестированы перед отправкой МР на ревью. Это сокращает время, которое уходит на ревью кода, и помогает избежать пропуска критических проверок.
• Повышение качества кода: Использование шаблонов позволяет включить в чеклист необходимые требования к коду, такие как правила форматирования, проверка наличия тестов и документации. Это способствует повышению качества кодовой базы.
• Улучшение прозрачности процесса: Шаблоны дают возможность ясно определить, какие шаги и требования должны быть выполнены перед слиянием МР. Это упрощает процесс слияния и делает его более прозрачным для всех участников.

Для Gitlab можно использовать шаблоны МР. Пример файла .gitlab/merge_request_templates/Default.md. Также в шаблоне настроен автоматический выбор Assignee и создание МР в Draft.

## Описание изменений

Опишите, что было сделано в этом МР.

## Чеклист

Пожалуйста, убедитесь, что все пункты ниже выполнены перед отправкой МР:
- [ ] Проставлены контексты ревью
- [ ] Добавлен Assignee
- [ ] На момент создания в МР подлит свежий develop или feature-ветка
- [ ] Все комментарии и документация актуальны и информативны
- [ ] Изменения протестированы на локальной среде разработки

Если какой-то пункт из чеклиста не выполняется, пожалуйста, исправьте это перед слиянием МР.

/assign me /draft

Мой рассказ не такой красочный, но в нем тоже есть боль, страдания, принятие и отторжение. Выводом может быть фраза "делай проще!".

В компании в которой я работал, решили переложить часть разработки бизнес-логики с программистов на аналитиков.

Сначала это были безобидные правки тарифов по ставкам. Потом решили сделать аля-BPMN, когда в визуальной среде стрелочками рисуется бизнес-логика, а потом из этого генерируется код на C# использующий под капотом процессную модель Windows Workflow Foundation.

И началось.

• Постоянные конфликты JSON-конфигураций на базе которых генерировались визуальные схемы.
• Усложнение обратной совместимости на бекенде, потому что в кэше хранились процессы предыдущих версий. Формат контрактов так же ограничен особенностями схемы.
• Вместо понятного SQL или C# мы писали JSON-метаданые в кастомном формате, из которых потом генерировались Entity, DTO, ViewModel, DDL-скрипты. О релевантности такого опыта на рынке даже говорить не хочется.
• Каждая новая фича давалась кровью и потом, а сроки исполнения задач росли в геометрической прогрессии. Чем естественно расстраивали менеджеров, ориентирующихся на потрясающие метрики вроде time to market, cycle time, etc.
• И еще миллион проблем!

Всё получилось как в классическом примере из книги "Чистый код", о том почему переусложненый продукт будет очень сложен в поддержке и сколько разработчиков не бери, всё равно всё будет плохо.

Также из-за того что весь проект был завязан на WWF была невозможна миграция на .NET Core (смотрели форки типа CoreWF, но не взлетело).

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

К примеру, я работал над одним багом три месяца и на каждом дейли говорил "я в процессе, распутываю клубок". Баг был в том что при нажатии на ссылку после покупки инвалидировались данные в корзине и пользователь видел ошибку. Звучит просто? Три месяца, сынок.

P.S. Некоторые проекты в компании отказались от использования "ядра" и начали делать простые круды с формочками на фронте. Стоит ли говорить что за несколько месяцев разработки их time-to-market уменьшился в несколько раз по сравнению с предыдущими годами?

P.P.S. Мой друг из крупного китайского ритейлера написал что они отказываются от метаданных. Победа здравого смысла!