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

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

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

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

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

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

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

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

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