пятница, 26 февраля 2010 г.

[work; prog] Нравоучение: делайте свои имитаторы чужих компонентов

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

Например, вам нужно обращаться к чужому Web-сервису – напишите его имитатор. Вам нужно обслуживать запросы чужих клиентов – напишите их имитаторы. Вам нужно запрашивать данные у чужой системы – напишите ее имитатор. Просто возьмите и напишите. Хотя бы самый простой и ограниченный в функциональности. Но чтобы вы могли докручивать его в любую нужную вам сторону. В любой момент. Никого не упрашивая и даже не ставя в известность.

Зачем это нужно делать? Затем, что если вы этого не сделаете, то рано или поздно вам придется обратиться к вашему партнеру с просьбой сымитировать ту или иную ситуацию. Мол, нужно проверить, что будет, если мы от вас получим три положительных ответа, затем через 0.25 секунды один ответ с кодом 0x543f, а еще через 0.155 секунды – еще 150 положительных ответов.

Так вот, когда у вас возникнет такая необходимость и вы обратитесь с подобной просьбой к своему партнеру, знаете что произойдет? Ваша просьба будет передана разработчику вроде меня (и это еще не самый плохой случай, я уверяю) и первая мысль у этого разработчика будет: “А нахер мне это надо?!!!”

И в лучшем случае, если вам повезет и у партнера будет серьезный стимул помогать вам, то со временем вашу просьбу удовлетворят, частично. Но ведь могут и вежливо послать, мол, “имитация не является штатным режимом работы нашего ПО и повторить предложенный сценарий не представляется возможным”.

А теперь представьте, что написанная вами система запущена в коммерческую эксплуатацию, работает под нагрузкой и вдруг случается большой трындец и наступает полный обертюр. Все на ушах, в чем дело не понятно, а разбираться нужно. Причем параллельно с вами разбираться в проблеме будут и партнеры. И не исключено, что они докопаются до причин раньше вас. Вот раскопают они, что если события происходят в последовательности X, Y, Z за временной интервал t, то вашей системе наступает кабздец. И на каком-нибудь совместном совещании в присутствии большого начальства поделятся своими подозрениями. И что вам останется? Вы-то сами не сможете работу своей системы проверить – нужно идти на поклон к партнеру, т.е. публично расписываться в собственной беспомощности. Даже если вы сами первыми вычислите эту злосчастную последовательность X, Y, Z – это все равно будут лишь ваши предположения. Проверить их самостоятельно вы будете не в состоянии.

А будь у вас имитатор компонента партнера вы бы оказались в более выигрышном положении. Вы смогли бы сами воспроизвести условия возникновения проблемы и проверить работу своей системы. И сделать это все оперативно, без публичного шума. Нашли бы проблему, залатали ее и при разборе полетов бы доложили: “Да, был у нас злобный баг. Он проявлялся при таких-то условиях. Мы его уже исправили. Сейчас все работает.” И пусть партнер проверяет сколько хочет (если сможет, ведь имитация не является штатным режимом работы его ПО).

Если при чтении последних двух абзацев у вас возникла мысль о том, что с вашей-то системой такая жопа не случится, то выбросьте ее из головы – баги есть всегда и везде. Так что лучше напишите пару-тройку имитаторов, это окупится.

4 комментария:

Quaker комментирует...

Евгений, а Вы лично применяете имитаторы? Всегда ли нужно писать их самому? Я где-то слышал о готовых решениях для имитирования нагрузки на web-сервер (конкретных ссылок и названий продуктов не помню, буду благодарен, если кто поделится).

Евгений Охотников комментирует...

Да, применяю. Но у меня и задачи специфические.

Всегда ли нужно писать самому? Тут все зависит от прикладной области. Если для Web-приложений есть много готовых инструментов, то можно ими и обойтись. Скажем, нет смысла писать свое что-то для имитации большой корректной нагрузки. Но вот если вам нужно проимитировать специфические некорректные обращения, а готовые инструменты не позволяют это сделать, то лучше написать самому.

Мне в свое время пришлось делать SMPP-клиента и из доступных SMPP-серверов, которые можно было использовать для тестирования, ничего хорошего не нашлось. Я сделал свой тестовый SMPP-серверный вход. И получил возможность имитировать на нем самые разные ситуации.

Или недавно пришлось делать несколько интерфейсов к импортным мобильным операторам, которые очень любят HTTP+XML. Я поставил себе простенький Web-сервер и написал несколько Ruby-новых CGI. Что позволило мне отладить свои интерфейсы с разными типами ответов сервера. Причем временами я это делал во время, когда у самих SMS-центров были проблемы с предоставлением нам тестовых подключений.

Так что использую и активно.

jazzer комментирует...

Не нужно ограничиваться компонентами.
Этот принцип применим ко всему, с чем имеет дело программист.
Например, язык, на котором он пишет - очень неплохо попытаться написать парсер, сразу узнаешь о языке много нового :)

Евгений Охотников комментирует...

>Например, язык, на котором он пишет - очень неплохо попытаться написать парсер, сразу узнаешь о языке много нового :)

Как это раньше говорили: настоящий программист должен написать три вещи: собственный текстовый редактор, собственный компилятор и собственную ОС :)

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