Комментарии 6
Не сложно заметить, что в текущей схеме есть сразу несколько возможностей для создания инцидента «на ровном месте»:
Отсутствует механизм «устаревания» спецификации. Нет гарантий, что разработчик поделился корректной и актуальной спецификацией.
Написание кода руками по спецификации мало того, что затратно, так еще и чревато появлением багов. Человеческий фактор никто не отменял.
Нет шага валидации контрактов при деплое приложения в стейджеое и продовое окружение.
но ведь и в вашем варианте нет гарантий
никто руками их и не пишет, просто генерируют командами из "коробки"
логичнее их валидировать при генерации тогда?
Честно говоря, я надеялся, что в ИТ сбера люди слышали, что такое процессы разработки софта. Управление требованиями, изменениями, конфигурациями уж десятки лет используются, всякие стандарты на эту тему написаны. А тут опять про софт-скиллс история, команды не договорились, не сообщили и т.п. Очередное "открытие" контрактного программирования, TDD, валидации, QA и т.п.
Очередная статья про sbm-cli, когда уже open source сделаете?
Сервисы дружитес. Как платформа упрощает создание интеграций без ошибок