Будучи разработчиком множества различных проектов, начиная от простых веб-сайтов, которые я разрабатывал самостоятельно, и заканчивая мультисервисными гигантами, у которых было несколько команд в разных часовых поясах, я столкнулся со многими проблемами, пытаясь оставаться гибким и не блокировать другие команды. пока делаю свою работу.
Моки, фейки и заглушки
Большинство читателей, вероятно, знакомы с тем, что это такое, но для тех, кто не знаком, они представляют различные уровни абстракции, которые моделируют или клонируют поведение реальных «вещей», таких как объекты или функции. В чем-то они разные; подделки, например, могут быть минимальными реализациями реальных объектов, но, тем не менее, реальной реализацией. Моки и заглушки обычно не имеют никакой базовой реализации. Они обычно используются при написании тестов, и одной из самых больших проблем с ними являются внешние вызовы API, межсервисные вызовы или вызов внешних сервисов. И, вероятно, самая большая из них — это внешние сервисы. Есть решения, которые вы можете кодировать, но когда вы действительно хотите смоделировать что-то вне тестовой среды или во время разработки, это становится очень сложно.
Пример из реальной жизни
Представьте себе работу над фрагментом кода, который взаимодействует с другой службой или устройством, выполняющим действие, на которое устройство может реагировать несколькими способами в зависимости от определенных параметров. Команда, работающая над прошивкой для устройства, знает, что должно отвечать устройство, а вы знаете, что отправит ваш сервис. В большинстве случаев вы можете просто закодировать отсутствие реальной связи и просто переписать метод, как только их реализация будет завершена. Но зачем это делать, зачем мучиться с созданием кода, который будет изменен, если можно смоделировать конечную точку устройства и облегчить себе работу.
Преимущества использования насмешек для этого сценария
Используя насмешки, вы получаете возможность заключить контракт, которому можете следовать как вы, так и команда прошивки. Вы можете сделать это с помощью простого текстового файла, но делиться им и управлять обновлениями становится обременительно, и вам все равно нужно кодировать отсутствие реального сервера. Вы можете сделать это с загружаемыми мок-серверами, но тогда вам придется управлять ими, и вы все еще не решили проблему отсутствия обновлений между командами.
Вот тут-то и приходят на помощь мокающие сервисы, такие как Mockadillo. Думая заранее и имея единое место, где вы можете увидеть, что ожидается от обеих команд для обеспечения успешного взаимодействия между сервисами, вы улучшаете качество рабочего процесса, как это может быть очевидно. каков объем и масштаб вашей работы.
Еще одним преимуществом является то, что вы отделены от другой команды. Пока они заняты разработкой своего функционала, вы можете разрабатывать свою часть приложения, не беспокоясь об их доступности, их изменениях и возможных ошибках. Такие сервисы, как Mockadillo, отличаются высокой доступностью, вы можете просматривать контракт на связь в любое время, вы получаете уведомления об обновлениях и можете моделировать различные сценарии в зависимости от того, что вам нужно, будь то имитация ошибки, создание задержки, тайм-аут или просто вызывая различные ответы в зависимости от запроса.
Лучший процесс разработки
Вероятно, первое, что я и мои коллеги абстрагируемся, — это общение с другими службами или взаимодействие API веб-приложений и мобильных приложений. Вероятно, вам может сойти с рук простая функция/класс, который содержит хост и имеет разные методы для разных вызовов, которые вы хотите сделать. Что ж, представьте, что вы принимаете параметр, представляющий значение host, которое во время разработки может иметь значение, являющееся фиктивным сервером, а затем просто заменяете его, когда Функция target готова. Таким образом, вам никогда не придется изменять свой код, и вы всегда сможете работать так, как если бы функциональность target всегда была на месте.
И это работает в обе стороны: когда вы начинаете работать над чем-то, от чего сильно зависит другая команда, вы можете потерять давление коллег или надоедливого PM, который мешает вам поторопиться.
Так что для вашего следующего проекта подумайте о том, чтобы смоделировать ваш API с помощью нас, это может просто избавить вас от головной боли в процессе.
