Несколько месяцев назад мы запустили серию интервью Oh, My Code на образовательном канале Технострим. И сегодня хотим поделиться интервью с одним из наших гостей. Как из космоса попасть в мобильную разработку, кто есть кто в команде разработки и стоит ли программисту работать на аутсорсе — рассказывает руководитель мобильной разработки новой торговой платформы Pandao Александр Черный.

Ведущий программы — технический директор медиапроектов Павел Щербинин, гость — руководитель мобильной разработки Александр Чёрный. Ниже вы найдете ответы на ключевые вопросы, которые мы разобрали в видео-выпуске Oh, My Code:

• Чем отличается работа в гос.структуре, на аутсорсе, в большой и в маленькой компании?
• За что отвечают junior, middle и senior разработчик?
• Как установить баланс между требованиями заказчика и разработкой?
• Как написать резюме на вакансию мобильного разработчика?

Расскажи немного о себе.

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

Кто тебе начал первым платить за это?

Это была организация при Санкт-Петербургском университете, в котором я учился. Мы занимались созданием бортовых спутниковых систем.

Ты начал свой путь с космоса?

Можно сказать и так. Причем мы проектировали полный цикл создания «железок»: схемы отправлялись в Зеленоград, изготавливались, возвращались нам, мы ругались на зеленоградских рабочих, допаивали, что нужно, писали внутреннее и внешнее ПО.

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

Как тебя после этого занесло в мобильную разработку?

Это был сложный переход. В то время мобильная разработка существовала только в формате J2ME. iOS и Android тогда еще не были распространены. Я выбирал между мобильной разработкой и финансовым сектором с Java Enterprise. Мой сосед тогда эмигрировал в Австралию, и он сказал: «Саша, трогай под мобильники».

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

Дальше получилось случайно. У меня сломался ноутбук Toshiba. Мне скинули ссылку на объявление, что продавался ноутбук Mac.

И ты стал программировать под iOS.

Я просто стал смотреть, что там есть. JCC есть. Офигенно. Уже полдела. Так, можно поставить Qt Creator, есть С++, прямо IDE, красиво. Класс! Потом смотришь, есть какой-то Xcode. Можно что-то писать. Тогда я разослал по своему списку просьбу взять меня стажером без зарплаты, кем-то вроде super junior.

К сожалению, вакансий не было. Я даже сходил на собеседование. Меня там честно попросили запрограммировать табло для расписания рейсов самолетов, но работать не взяли. В конце концов мне помогли попасть в классическую питерскую веб-студию. Я был там единственным iOS-разработчиком. Ребята, помогшие устроиться, консультировали меня целых два раза. Первая версия операционки, под которую я писал, была 3.1, сейчас — 11. Если вдруг кто не в курсе, новые версии выходят раз в год.

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

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

Когда-то мы с тобой обсуждали различные роли в команде, различные уровни взросления программиста, начиная с junior, потом middle, senior. К каким выводам ты, в итоге, пришел?

Одним из неплохих критериев я считаю то, как тебя называют коллеги. Если они считают тебя senior-разработчиком, поздравляю — значит, ты этого достиг.

Я думал, ты скажешь, если они тебя называют в стиле «эй, ты», или если они уже начали называть тебя по имени.

Если по имени и отчеству, то это высшая ступень.

Это уже senior. По имени — middle, а если «эй, ты, сделай таск», то это junior.

Любопытная классификация, но у меня немного другая.

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

Область видимость и область ответственности.

У junior область ответственности — это конкретная задача. Если она хорошо поставлена, то он должен её решить. Но вход и выход детерминированы. Соответственно, если где-то что-то пошло не так, junior, скорее всего, не справится.

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

Расскажи о какой-нибудь своей большой проблеме, аврале, факапе, который произошел у тебя в работе, и как ты справлялся?

Проблемы, как правило, связаны с людьми. Например, у меня была такая ситуация. Разработчик решил жениться. Благое дело. Совет да любовь. Он взял отпуск, из которого к нам не вернулся. А план разработки был построен определенным образом, этот парень был нужен. Было очень печально, потому что у тебя есть срок, обязательства, заказчики. В аутсорсе уход людей — это проблема, потому что там сразу теряешь деньги. И решается всё, как обычно, за счет усилия воли. Эта история меня многому научила, с тех пор я предусматриваю даже такой сценарий.

Еще одна разновидность проблем — когда у тебя нет способов воздействия. Классический пример: Apple Review Team. Там сидят какие-то непонятные люди, действующие по абсолютно недетерминированным алгоритмам, с ними отсутствует прямой диалог, и при этом они тебе что-то запрещают. Ты можешь спрашивать, говорить, прикладывать доказательства, и не получать никакой обратной связи.

Как установить баланс между бизнесом и разработкой? Бизнес говорит: давайте завтра всё, что мы сегодня захотели. А разработчик хочет построить правильную инфраструктуру, хорошую архитектурную систему, на которую у него, может быть, не хватает времени.

Единственным приличным критерием в этом диалоге является взаимное уважение. Обе стороны должны понимать интересы друг друга. А поскольку сложно, находясь в одном погружении, понимать потребности другого погружения, возникают всякие связующие роли. Три самые популярные: тим-лид, head of function и технический директор. В моей классификации эти люди отвечают за разные уровни связей между разработкой и бизнесом, которые должны донести до бизнеса информацию о рисках. Например, «мы сделаем это быстро, потому что это имеет некую коммерческую ценность, но потом придет час расплаты». Как они это донесут, уже им решать. Бизнесу тоже неплохо бы понимать, что у обеих сторон свои зоны компетенции. Если бизнес не хочет признавать компетентность разработчиков и желает работать с ними в приказном порядке, это возможно, но тогда это должно дорого стоить.

Ты не упомянул по каким-то причинам о гибких методологиях. Среди вышеупомянутых ролей у тебя не появился scrum master, которого я ожидал.

Фокус в том, что люди часто склонны не соблюдать методологии в силу фантастического разнообразия причин. И я не упомянул о методологиях, потому что ни они, ни какие-то другие инструменты не решают проблем. Проблемы и создают, и решают люди.

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

Давайте посмотрим.

«Общаюсь в Telegram-чатах» — это совершенно не важно.

«Вечерняя физмат школа» — я учился в Петербурге и не знаю хорошие школы в Москве.

«Абсолютный победитель всероссийской олимпиады районного уровня по информатике» — Всероссийская олимпиада районного уровня? Мне придется какое-то время подумать, чтобы осознать эту фразу. Победил — молодец. Хвалю.

«Хакатон, Бауманка. Приложение» — я не могу посмотреть на результат. Ни статьи, ни фоток, ни ссылки, ничего нет.

«Технопарк» — значит, я могу сходить к коллегам и что-то узнать про этого человека.

Дальше идут ссылки на open-source проекты. Это очень хорошо. Количество скачиваний меня здесь не особо волнует. Это означает, что коллеги, которые скоро будут работать у меня в команде, могут посмотреть его код. Мы считаем, что если нанимаем программистов, то разговариваем про код. Иное просто странно. Поэтому когда у человека есть ссылка на какой-либо публичный код, неважно, законченный или нет, мне нужно просто посмотреть, что он умеет, как он пишет, как он видит.

«Клиентское приложение, распознавание, openCV» — приятно. Видимо, не зря человек в Бауманке учится.

«Тестовое задание» — очень хорошо. Здесь с точки зрения кода всё очень здорово, есть простор, можно проанализировать.

Есть много правильных терминов. Clean Architecture — не указано, какая, Google I/O 2017 или дядюшки Боба в оригинале. Dagger — почему-то не второй, а первый. Kotlin — допустим. RxAndroid, Retrofit — здорово. Это очень хороший набор технологий.

Я бы с парнем обязательно поговорил.

Чтобы жизнь медом не казалась, я еще в резюме периодически тыкаю во все упомянутые слова в блиц-режиме. То есть, например, человек написал SQL. Спрашиваю, как выбрать все записи из таблицы. Вы не поверите, но 9 из 10 не могут этого сделать. Просто выбрать все записи из таблицы. Режим напряжения на лице, а ответа нет. Поэтому если здесь написано много всяких слов, то кандидата я спрошу по ним по всем, но очень быстро.

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

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

А давай мы проведём небольшое собеседование с тобой? Возьмем задачу и попробуем ее решить на доске?

Давай.

Представь, что у тебя есть виджет из трех элементов: 1, 2, 3. Они автоматически подгружаются при загрузке. На экране отображается только второй, но запрос на показ ушел всем трем. Это сломало нам персонифицированную статистику. Как бы сделать так, чтобы нивелировать эту проблему или убрать ее совсем?

Здесь есть несколько путей решения. Изначально проблема в том, что единственный отображённый элемент по умолчанию грузит не только активную владку, но и соседние. Персонификация ломается, поскольку мы отправляем на сервер информацию о том, что пользователь видел элементы, которые ему на самом деле не были показаны.

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

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

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

Для неактивных вкладок формируем словарь, в котором id — это id категории, а значение — это массив запросов. Соответственно, есть request 1 и request 2.

Когда происходит смена вкладки, будет событие onChange. Мы смотрим в свой буфер, находим по id категорию, смотрим, какие статистические запросы для нее еще не ушли.
В принципе, эта модель могла бы сработать. Надо проверять.

И наш небольшой блиц-опрос. Последняя книга, которую ты прочитал?

Если не художественная, то «Русская модель управления».

Понравилась?

Да.

Согласен, что русские ленивые? Пока их не пнешь, ничего не начинают делать?

Мне не нравится обобщение.

А последняя прочитанная техническая книга?

Документация по Swift 4.

Что лучше, Swift или Objective C?

Они про разное. Я пока ближе к Objective C.

Kotlin или Java?

Kotlin мне нравится больше, чем Java. Но специалистом в этом вопросе я себя не считаю.

Как выбрать все записи из таблицы?

SELECT * FROM table;

Покупать или продавать биткоины?

Поздняк.

Значит, продавать?

Я прошляпил этот момент. Надо было заморачиваться в 2011 году.

Я знаю, что ты играешь в «Что? Где? Когда?». У тебя есть мечта — попасть в заветный домик?

Нет, совсем нет.

Какие у тебя еще есть хобби?

Их три. Кроме «Что? Где? Когда», которая помогает тренировать ум, есть горные походы, которые скорее про тренировку тела, и есть ювелирные работы, которые скорее про тренировку духа. Можно залипнуть над какой-нибудь деталькой и долго с ней разбираться.

Смотрите другие выпуски нашего ток-шоу:

• Машинное обучение и аналитика в Одноклассниках
• Вся правда о языке GO и работе в AM.RU
• "Как сделано Облако, почему Perl не умер и что такое хороший программист"
• Все выпуски OH, MY CODE