Разработка в Grab: чему я научился, работая в большой технологической компании?

Сейчас 2020 год. Я до сих пор не могу поверить, что время летит так быстро! Сейчас я работаю инженером-программистом (разработка в Grab, специализируюсь на iOS), уже более 2 лет с тех пор, как я окончил университет, и… я все еще жив! Звучит здорово!

Мне очень нравится это приключение… Есть куча вещей, которые я собирал изо дня в день, и они очень интересны … по крайней мере для меня.

Я работаю в Grab с прошлого года. Я очень горжусь тем, что работаю в этой компании и участвую в выполнении миссии «Везем Юго-Восточную Азию в будущее» (Driving Southeast Asia Forward). Итак, первым делом первое …

Что такое Grab

Да! Что такое Grab? Из LinkedIn:

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

В настоящее время Grab имеет научно-исследовательские центры в нескольких странах: Сингапур, Индия, США, Вьетнам, Индонезия, Корея, Китай, Малайзия, Румыния. Может быть я пропустил какие-либо офисы.

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

Давайте посмотрим, что я узнал в процессе.

Разработка в Grab: качество кода

Да, сэр! Качество. Здесь, в Grab, учитывается каждая строка кода. Убедиться в том, что поставляемый код является лучшего качества — одна из первых обязанностей инженера.

Модульные тесты — это первоклассный инструмент обеспечения качества, тесты покрытия кода и автоматизированные тесты также входят в наш инструментарий. Если ваш код недостаточно хорош, он никогда не будет смержен. Чтобы обеспечить высокое качество, у нас есть группа инженеров, которые всегда изучают ваш код при отправке Merge Request. И есть CI для проверки качества кода.

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

Разработка в Grab: документация

Вторая самая главная вещь — документация. Я научился терпеливо читать оооочень длинные документы, чего не делал раньше. Потому что, не читая документы, я даже ничего не смогу сделать. У меня должно быть достаточно знаний о проблеме, которую мы хотим решить, прежде чем начать ее решать. И хорошее понимание документации поможет вам легко и заранее разобраться с крайними, пограничными случаями. Так что понимание документов обязательно.

Но документация это не только чтение — я научился и правильно писать документы.

Честно говоря, Grab для меня в этом не первый. В моей предыдущей компании я написал кучу инженерных документов, предназначенных только для инженеров. В этом  главное отличие.

Теперь я пишу документы для более широкой аудитории. Документы предназначены не только для инженеров, но и для всех, кто работает над тем же проектом. От PM до QA, дизайнеров, всех заинтересованных сторон и… моего менеджера. Я должен убедиться, что все имеют одинаковые знания по этому вопросу.

Разработка в Grab: новая архитектура RIB

RIBs — кроссплатформенный архитектурный фреймворк от Uber.  RIB — это сокращение от Router, Interactor и Builder, которые являются основными компонентами этой архитектуры. Фреймворк был разработан для больших мобильных приложений с большим количеством разработчиков и вложенных состояний.

Я не буду подробно рассказывать о том, что такое RIB, как его использовать и каковы его преимущества. Есть тысячи статей, там уже об этом рассказали.

Я бы сказал, что мне он нравится. На самом деле, вначале архитектура показалась мне немного похожей на VIPER, с которым я уже сталкивался ранее, так что она совсем меня не смутила. В отличие от других архитектур, таких как MV* и VIPER, RIB не обязательно должен иметь представление, это может быть чисто бизнес-логика. Такие элементы, как Presenter и View, не являются обязательными для RIB. Исходя из собственного опыта, я редко создаю Presenter. Маршрутизация руководствуется бизнес-логикой, а не логикой просмотра. Похоже, что RIB выполнен по концепции business logic driven.

A/B-тестирование

Ура! Самая интересная часть. Я проводил не так много A/B-тестирований до Grab, но здесь каждый день мы проводим очень много тестов. Основная цель — понять потребности пользователей, предложить им лучший опыт, а также поэкспериментировать с нашими идеями.

Каждая функция работает с помощью флага. Флаг функции — это, по простому, переключатель командной строки, который построен на очень базовой концепции программирования, операторе условия (if-else, switch-case). Это способ отделения функциональных выпусков от деплоя кода. Это также помогает нам контролировать развертывание и возможность отката при возникновении инцидентов.

Число экспериментов, которое мы проводим эти дни, огромно. Была еще одна вещь, которую я понял, работая над этим. Чтобы прекратить over-engineering сначала мы предлагаем дешевые решения. Дешевое решение уменьшает количество усилий/времени, которое нам требуется на создание чего-либо.

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

Много для первого раза

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

Первый раз я был инженером по вызову…

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

…релиз-инженером

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

… услышал об RFC

Это правда, что я не слышал об этом до того, как присоединился к Grab, хотя сама концепция появилась в 1969.

RFC означает «Request For Comments». Эта практика используется в Grab всеми командами для обмена инженерными проектами с целью сбора отзывов для улучшения и предотвращения коллизий при разработке.

Это отличная возможность для обучения. Благодаря этому процессу я многому научился. А также изучил предстоящие проекты.

Вывод

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

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

Источник