Pull to refresh

Comments 6

Не сложно заметить, что в текущей схеме есть сразу несколько возможностей для создания инцидента «на ровном месте»:

  • Отсутствует механизм «устаревания» спецификации. Нет гарантий, что разработчик поделился корректной и актуальной спецификацией.

  • Написание кода руками по спецификации мало того, что затратно, так еще и чревато появлением багов. Человеческий фактор никто не отменял.

  • Нет шага валидации контрактов при деплое приложения в стейджеое и продовое окружение.

  1. но ведь и в вашем варианте нет гарантий

  2. никто руками их и не пишет, просто генерируют командами из "коробки"

  3. логичнее их валидировать при генерации тогда?

Добрый вечер! В обновленном воркфлоу на каждый коммит запускается валидация в CI/CD. Поэтому контракты всегда в актуальном состоянии. Иначе разработчик просто не может смержить изменения в мастер ветку. И тем более задеплоиться в прод.

Честно говоря, я надеялся, что в ИТ сбера люди слышали, что такое процессы разработки софта. Управление требованиями, изменениями, конфигурациями уж десятки лет используются, всякие стандарты на эту тему написаны. А тут опять про софт-скиллс история, команды не договорились, не сообщили и т.п. Очередное "открытие" контрактного программирования, TDD, валидации, QA и т.п.

Здравствуйте! You live — you learn, как говорится ;)

Очередная статья про sbm-cli, когда уже open source сделаете?

cli - это лишь интерфейс. Цимес всего этого в платформе, на которой реализованы и валидация контрактов, и всё остальное. Открыть такую систему наружу очень сложно, потому что чаще всего всё прибито гвоздями и куча специфики/легаси и т.п. Потому подозреваю, что примерно "никогда" :(

Sign up to leave a comment.