Как мы мигратор из Asana в Битрикс24 дорабатывали или почему очень важна обратная связь?

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

Разработка приложений для миграции данных из сторонней системы на портал Битрикс24 всегда была достаточно сложным процессом. В первую очередь это связано с тем, что хороший разработчик обязан хорошо разбираться в коде, но не очень обязан разбираться в особенностях применения конкретного приложения пользователями на практике. Да что там говорить, хороший разработчик в рабочее время вообще ни в чём кроме кода не разбирается и даже с семьёй своей по будням общается исключительно на ява-скриптах.

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

Написание самого кода и его поэтапная отладка - процесс уже рутинный, в котором всё сводится к проектированию, моделированию ситуаций, отлавливанию ошибок и прочей оптимизации. В итоге через один-два месяца на рынке появляется готовый продукт, который позволяет переносить данные из бухгалтерии или какого-нибудь агрегатора задач на портал Битрикс24 и живые люди начинают более или менее активно использовать его на бою.

Если у разработчика была достаточно богатая фантазия, и он смог на чистой интуиции смоделировать хотя бы 80% реальных кейсов за те две недели, которые ему были даны на демо-режим использования сторонней системы, клиенты остаются более или менее довольны и особенно не терзают техподдержку своими обращениями. Отчасти это так же связано ещё и с тем, что те пользователи, которые не нашли необходимых для них 20% функционала, просто машут на приложение рукой со словами: "Ну, раз этого нет, то, значит, и не будет", после чего удаляют бесполезное приложение и более уже не возвращаются к этому вопросу. Другое дело, что это всё - в идеальном мире, а в реальном функционалу может не хватать и половины того, что можно было бы реализовать, будь у разработчика изначально хорошая обратная связь с теми, кто будет использовать его детище. Впрочем, особенно сильно это ничего не меняет - пользователи всё равно не склонны жаловаться на инструмент, которым не пользовались раньше и без которого, очевидно, прекрасно обойдутся и в будущем.

В случае с мигратором Асана нам повезло. Однажды, не найдя в приложении того, что ему необходимо, заказчик напрямую обратился к нашей компании с просьбой доработать функционал под его непосредственные нужды. Просили не многого - всего-то навсего реализовать перенос комментариев к задачам, которого не было в изначальной версии. Надо - сделаем. Работы не много -  реализовать новую таблицу и два дополнительных класса. Правда, уже через пару дней оказалось, что было бы неплохо так же переносить ещё и задачи, являющиеся дочерними задачами по отношению к текущей. А у этих дочерних задач тоже могут быть дочерние задачи. А ещё - приложение никогда не переносило на портал Битрикс24 привязанные к задачам файлы. Можно заодно ещё и это реализовать? Отчего же нельзя, можно. Тем более, что все пожелания были высказаны в самом начале работ, а не после их завершения, перед сдачей проекта.

Работа началась. Был заведён аккаунт для разработки, с полноценным триалом на целый месяц - Асана в этом отношении щедра не в пример остальным платформам. На скорую руку были созданы задачи с различными уровнями вложенности, комментарии и прикреплённые файлы с весёлыми картинками из интернета. Завершилась разработка, началось внутреннее тестирование, которое тоже прошло достаточно гладко. Можно сдавать заказчику? Можно, но... Сначала заказчик хотел бы провести тестовую миграцию. И вот тут началось основное веселье.

Во-первых, обнаружилось, что полноценный триал Асаны обладает куда большим функционалом, чем оплаченный коммерческий аккаунт. Права триала сравнимы с правами полноценного аккаунта уровня Enterprise, тогда как базовый платный функционал намного сильнее ограничен в правах пользовательского api-ключа, с помощью которого происходят запросы к системе на получение информации о сущностях. Оказалось, что из четырёх сотен проектов приложение видит чуть больше одной трети. Начался длительный процесс добавления специального технического пользователя в систему и наделение его необходимыми правами. Нужно было вручную добавлять его во все возможные проекты, так как без этого api-ключ просто не мог увидеть ни сами проекты, ни привязанные к ним задачи. Разве можно было предусмотреть такую ситуацию на тестовом аккаунте разработчика, когда всё делалось от имени одного единственного пользователя, наделённого самыми широкими полномочиями?

Во-вторых выяснилось, что изначально в приложении не было ни намёка на какую бы то ни было пагинацию (постраничный импорт сущностей). Из Асаны скачивалось, максимум, пятьдесят проектов, пятьдесят задач, пятьдесят пользователей... Поскольку за несколько лет никто не жаловался, можно было бы смело предположить, что все эти годы никто ни разу не использовал приложение всерьёз. Добавили клиент SDK, который умел делать постраничное скачивание автоматически - пришлось несколько дней модифицировать все классы, так или иначе связанные с использованием API. Бесплатным бонусом стало то, что клиент SDK по-умолчанию умеет делать задержку между запросами, если их количество превышает определённый лимит - об этой проблеме на тестовом аккаунте с двумя с половиной задачами тоже можно было только догадываться, да и то только при наличии либо очень богатого опыта, либо очень бурной фантазии.

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

Обнаружилось, что прикреплёнными к задачам файлами могут быть не только весёлые картинки с котиками, но и скучные тяжёлые архивы под сто мегабайт весом, а приложение вылетает с нехваткой памяти уже при тридцати. Опять потянулись длинные часы попыток оптимизировать программу с помощью различных нестандартных решений. Примерно в это же время выяснилось, что при генерации имён для хранилищ файлов на портале на основе названий родительских задач, их нельзя делать длиннее 255 знаков, а так же что в них не должно быть определённых символов, список которых пришлось составлять прямо в процессе миграции, по факту возникновения соответствующих ошибок. А как вы хотели? Это только в совершенной вселенной актуальная документация существует даже для hello world, а у нас пока - только для программы дистанционного управления трактором "Беларусь", да и та на китайском.

Мы узнали, что приложение относительно быстро справляется с переносом нескольких сотен тестовых задач, но при наличии нескольких десятков тысяч боевых процесс может затянуться почти на неделю. Ещё пол дня оптимизации - время сократилось примерно в шесть раз, в честь чего разработчик даже позволил себе после рабочего дня баночку холодного пива и как раз к следующему утру, когда стадия импорта задач успешно завершилась, уже снова был свеж, как огурчик. Когда в процессе миграции приложение стало периодически вылетать по неведомым причинам, выяснилось, что официальный клиент SDK не умеет обрабатывать свои же собственные внутренние исключения. Мириться с этим было нельзя и, естественно, клиент SDK был спешно доработан, в результате чего научился не только ругаться по-русски, но и выводить в файл необходимые логи об ошибках, после чего стало ясно, что даже у api-ключа с расширенными правами  этих прав иногда не хватает на то, чтобы получить информацию об особенно хитро защищённых задачах. Асана просто не хочет их отдавать и всё, что остаётся сделать пользователям базовых бизнес аккаунтов Асаны в этой ситуации - просто смириться. Если бы не санкции, эту доработку SDK-клиента можно было бы, наверное, впоследствии даже продать самой Асане. Или даже подарить, если бы международные отношения были совсем уже тёплыми.

Наверное, всего уже и не упомнишь, чему нас научила доработка мигратора при наличии обратной связи с реальным клиентом, а если и упомнишь (не зря же в комментариях к коду мы стараемся фиксировать по возможности все нюансы), то читать такую портянку текста (даже с картинками) навряд ли кому-то захочется. Важно сказать лишь одно: невозможно смоделировать все ситуации, которые могут возникнуть в приложении в процессе переноса сотни тысяч задач, четверти миллиона комментариев и нескольких десятков тысяч файлов из одной системы в другую, при условии, что изначально эти системы вообще не подозревали о существовании друг друга. Но когда у тебя на руках есть живой пример, когда ты в реальном времени можешь отслеживать все нештатные события и оперативно их исправлять, пока одна ошибка не успела повлечь за собой другую, а километры логов не похоронили под собой историю того, с чего же всё началось - разработка превращается в настоящее удовольствие. Это прекрасный опыт и гарантия того, что в дальнейшем приложение будет действительно приносить пользу нашим клиентам, а не просто пылиться на полке в маркете, как не очень качественная реклама наших не очень понятных с первого взгляда возможностей.