tgoop.com/emacsway_log/1461
Last Update:
Обратил внимание на то, что в лучших проектах моей практики всегда было хорошо организовано нагрузочное тестирование.
Представьте ситуацию, что некому человеку ехать в дальнюю поездку, он заехал на СТО подготовить машину, а ему говорят, что нужно заменить коробку-автомат, потому что она может не выдержать поездки. И больше никакой информации нет.
Что будет делать человек? Наверное, попытается обратиться к еще одному мастеру, чтобы удостовериться. Но городок маленький, он обращается к умельцу из гаражей, и тот ему отвечает - езжай, чего ты паришься. Проблемы нужно решать по мере их поступления.
И он поехал. И не выдержала коробка. И сломалась. И сорвал он важную бизнес-встречу, и купил коробку втридорого.
Почему так произошло? Потому что разные модели в голове у специалиста и клиента.
Как мог поступить специалист? Представить конструкторские расчеты предельно-допустимых износов и сопоставить их с реальными замерами. До тех пор, пока замеров нет, проблема не очевидна.
В голове роится: а вдруг разводят, а вдруг не справятся, ну ведь работает же...? Эти мысли не покидают его, даже если он согласился: а вдруг обманул, а может заменить его...?
Нагрузочное тестирование делает проблемы видимыми.
К сожалению, мне не удалось найти коробочные решения для генерации объемов данных перед нагрузкой, и все архитекторы из числа моих друзей создают фейкеры сами. Хороший фейкер, создающий зависимости объектов, в своем внутреннем устройстве использует принципы, похожие на принципы устройства ORM. И тем ребятам, которые знакомы с PoEAA и потрохами ORM, решение этого вопроса дается легче.
[UPDATE]: Говорят, что начинать проект с нагрузочного тестирования хорошо еще и тем, что можно хорошо погрузиться в структуру БД и публичных API сервисов.
BY emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
Share with your friend now:
tgoop.com/emacsway_log/1461