Анализ и проектирование систем *

Когда-то давно, авто тесты, разного рода сканеры и и такие процедуры как pull request review придумали для того чтобы ускорить процесс разработки в целом и особенно усколрить и упростить процесс выкатывания новых релизов.

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

Где мы свернули не туда?

Смог сформулировать достаточно давнее наблюдение. Рисование диаграм не всем дается. На самом деле нарисовать четкую и понятную диаграмму не так просто даже для простых случаев "Вот эти два сервиса обмениваются данными через RabbitMQ".

Наиболее распространенные ошибки

1. Раскрашиваем в цвета и добавляем финтифлюшки там где это не требуется. Да цвет может помочь в понимании, но лишняя раскраска и иконки может сбивать с толку.

2. Рисуем много лишних деталей. Два сервиса обмениваются сообщениями через RabbitMQ, давайте нарисуем еще VPC, availability zone вокруг этого и еще кучу разных шутк, которые там конечно присутствуют, но к делу не имеют отношения. Каждая диаграмма должна иллюстрировать строго тот аспект для которого она предназначена, что плавно подводит нас к третьему пункту.

3. Диаграмма это история которую один инженер рассказывает другим инженерам. История рассказывается с определенной целью, она должна донести message. Если это про то как данные идут от пользователя к сервисам через RabbitMQ, то эта история должна четко читаться с диаграммы.

NB: Не спрашивайте почему RabbitMQ а не SQS - так история сложилась.

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

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

Обычно сценарий выглядит так. Давайте мы вместо того чтобы тестировать end-2-end сделаем мок сервиса и относительно него будем разрабатывать и тестировать. Причин делать так может быть много и часто без моков вооще никуда. Например у сервиса относительно которого мы работает в принципе нет тестовой среды и доступен только прод. Или есть, но все работает очень медленно и нестабильно и только под ВПН заказчика и только с фиксированого IP

Беда в том, что у моков есть границы применимости. Инструмент это ограниченный. Скажем мы сохранили ответ от третьестороннего сервиса и сделали тестовый мок с которым мы все и девелопим. Потом идем в прод и обнаруживаем что от сервиса может приходить 5 разных вариантов компоновки стрктур данных ответа, а мы сохранили только одну и только с ней тестировали.

Еще раз это понятная проблема и в общем понятно как с ней бороться. Беда начинается когда команды принимают один замоканный ответ за эталон поведения сервиса.

Короче когда слышу на звонках слово мок у меня глаз начинает дергаться.