[Об авторе: Александр — разработчик prom.ua, с 2008 по 2010 работал на проектах Google как подрядчик-контрактор]
На предыдущей работе я ездил в продолжительные on-site командировки в Google. Работа была интересной и неплохо оплачиваемой. Ушел с нее, так как она стала мешать заниматься собственным проектом. К сожалению, за два года не хватило опыта и смелости вывести проект в прибыль. Когда накопленных на предыдущей работе сбережений осталось менее чем на полгода, приступил к поиску новой работы и устроился в Prom.ua.
Хочу поделиться своим опытом работы на проектах в Google и сравнить процессы разработки в «кремниевой» и украинской продуктовых компаниях.
Что нравилось в Google
В Google все сделано для того, чтобы разработчики дольше оставались на работе, и им было удобно в офисе. Просторные помещения, бесплатное трехразовое питание, mini-kitchen’ы, спортивные секции, бассейн, волейбол, тренажеры, массаж и т.д. непосредственно на территории кампусов.
На проекте, где я работал, была демократичная атмосфера. Разработчики, продакт-менеджеры и основатели проекта работали и общались на одном уровне.
Это не понравится продакт-менеджерам, но в Google их инициатива ограничена со всех сторон — разработчиками, тестировщиками и админами. Они вынуждены прислушиваться к мнениям всех этих «каст» перед отправкой в разработку новой «мегафичи». Как разработчику, не безразличному к судьбе проектов, на которых я работаю, мне нравится такое положение вещей. К сожалению, во всех без исключения «наших» компаниях, в которых я работал, большинство разработчиков почему-то считают мнение продакт-менеджеров законом, который обсуждению не подлежит. Это приводит к снижению инициативы, удовлетворенности и производительности со стороны разработчиков.
Удобно организована работа с любого компьютера в офисе или удаленно: введя свой логин/пароль, попадаешь в свое рабочее пространство. На ноутбуках запрещено хранить рабочий код — весь код должен лежать в «рабочем пространстве» — с ноутбука нужно логиниться в это «пространство» и только потом вести разработку. Можно спокойно терять рабочий ноут, не опасаясь утерять конфиденциальную информацию, а также не опасаться, что на рабочем компе «накроется» жесткий диск и вместе с ним — все твои наработки :)
Классная «облачная» инфраструктура для сборки, тестирования и деплоя в dev-окружение и продакшн. Сборка проходит не на твоем компе, а где-то в «облаке». Это ускоряет процесс сборки, так как независимые модули могут собираться параллельно, а уже собранные кем-то другим другим модули для заданной версии кода — могут использоваться без пересборки. То же самое касается тестирования.
Компания придерживается правила eat your own dog food, используя собственные разработки внутри компании. Это помогает быстро выявлять и исправлять баги и вносить полезные для пользователей изменения в разрабатываемые продукты.
Повсеместное используют protobuffersдля хранения и передачи данных и rpcна основе protobuffers для общения сервисов между собой. Это избавляет от изобретения «зоопарка» форматов хранения и передачи данных с последующим изобретением всевозможных конвертеров между этими форматами.
Код большинства проектов хранится в общем репозитории, который организован в виде библиотек функций. По этому репозиторию сделан удобный поиск. Это позволяет не изобретать велосипед каждому из проектов, а использовать уже существующие наработки других проектов. Также, улучшения в core-библиотеках сразу же становятся видны во всех проектах, использующих эти библиотеки. В отличие от Google, в Prom.uaсейчас идет тенденция к разделению кода на кучу независимых репозиториев для слабо связанных проектов. Это, с одной стороны, хорошо, т.к. разные команды не зависят друг от друга и работают каждый в своем ритме, но с другой стороны — не видны оперативные изменения в разных проектах, нужно выстраивать и поддерживать в актуальном состоянии API для взаимодействия между проектами, а также затруднено использование общего кода между проектами.
Что не нравилось в Google
Прежде всего, это большая иерархия менеджеров, из-за которой теряется связь между простыми работниками и топ-менеджерами. Наверное, это неизбежно для больших компаний. Но хотелось бы думать, что есть лучшее решение.
Процесс разработки в Google поставлен в жесткие рамки. Например, настоятельно рекомендуется использовать код и инфраструктуру, разработанную внутри компании. Очень трудно обосновать использование стороннего opensource решения, особенно, если что-то хоть чуточку похожее уже разработано внутри компании. Также поощряется «изобретение колеса» внутри компании вместо того, чтобы использовать уже готовое opensource решение. С одной стороны, такие ограничения направлены на минимизацию хаоса в уже устоявшихся проектах. С другой стороны, они угнетают инициативу по созданию чего-нибудь инновационного.
В отличие от небольших продуктовых компаний, разработчикам Google сейчас сложно начинать и развивать собственные инновации. Руководство Google признало эту проблему и сфокусировалось на прибыльных или потенциально прибыльных проектах. А другие постепенно сворачивает. Было решено, что их проще выращивать и покупать на стороне, чем пытаться вырастить у себя. Для «окучивания» сторонних инноваций организовали инвестиционный фонд.
В силу вышеназванных причин в Google не так много интересных задач, как обычно принято считать. В основном рутинные «улучшения» и багфиксинг в давно устоявшихся проектах.
Много нового кода в Google пишут на Java. Это хорошо с точки зрения hr’ов: программистов на Java сейчас очень много, и есть из кого выбирать. Но плохо с точки зрения качества кода. Из моей практики заметил, что программисты на Java зачастую любят злоупотреблять ненужными паттернами проектирования, нагромождать кучу бесполезных абстракций, интерфейсов, фреймворков и
Постепенное вытеснение кода на Python кодом на Java под флагом того, что «код на Java быстрее». Из моей практики, среднестатистический код на Python получается проще и понятнее аналогичного кода на Java. В результате разработка и расширение кода на Python занимает в несколько раз меньше времени и усилий по сравнению с аналогичным кодом на Java. Насчет утверждения «код на Java быстрее» — да, обычно первоначальный код на Python получается медленнее кода на Java. Но код на Python можно легко оптимизировать в случае необходимости до скорости, равной или превышающей скорость аналогичного кода на Java. Для этого нужно лишь грамотно использовать средства, предоставляемые Python, только в крайних случаях прибегая к переписыванию «узких мест» на C с использованием ctypesили Swig. Занимательные факты — автор Python, долгое время работавший в Google, перешел в Dropbox, а автор Java — перешел из Oracle в Google :)
Слабо обоснованное использование С++ вместо C. В Google много кода, критичного к производительности, написано на C++. Но на самом деле этот C++ представляет из себя «C с классами» в силу множества ограничений, которых должны придерживаться большинство проектов. В итоге большинство кода на С++ в Google можно автоматически заменить на аналогичный код на C, не ухудшив при этом читабельность, улучшив возможности по анализу и рефакторингу с помощью простейших инструментов вроде grepи улучшив возможности по интеграции
Нейтральная «фича» — обязательное ревью кода перед коммитом. В начале я думал, что это круто, т.к. позволяет фильтровать плохой код перед коммитом в репозиторий. Но затем осознал, что эта мера действует положительно только для «новичков», недавно пришедших на проект. Они еще не знают всех тонкостей проекта, поэтому могут создавать не очень «правильный» с точки зрения проекта код. В этом случае ревью помогает «подстроить» новичков под проект. Но затем ревью становится неэффективным и начинает тормозить разработку, потому что:
— часто приходится ждать до нескольких суток, пока кто-нибудь из разработчиков найдет время на ревью твоего кода.
— ревью кода от «старых» разработчиков обычно проходит «по диагонали» — ревьюверы на автомате жмут «LGTM» на коде от зарекомендовавших себя разработчиков, не вдаваясь в детали этого кода. В итоге основная цель ревью — выявление багов и «косяков» — не работает, т.к. многие баги остаются незамеченными.
Сравнение процессов в Google и Prom.ua
К сожалению, с увеличением размера продуктовых компаний в них теряется дух стартапа. Выстраивается иерархия из «эффективных» менеджеров, порождая бесполезную бюрократию, рвется свободное общение между директорами и обычными работниками, замедляется решение оперативных вопросов. Между написанием новых фич и их внедрением в продакшн проходит всё больше и больше времени, что не дает сразу увидеть отклик реальных пользователей на новые изменения в коде. Также с возрастом проекты начинают терять былое качество кода — он обрастает кучей малополезных bells&whistles (обычно оставляющих за собой устаревший код, костыли и баги), которые постоянно требуют отделы продакт-менеджмента и маркетинга.
В отличие от Google, в Prom.uaеще не потерян дух стартапа. Руководители с менеджерами не прячутся от сотрудников, поэтому быстрее решаются оперативные вопросы. Качество кода здесь пока еще лучше, чем на большинстве моих предыдущих проектов похожей сложности. Разработка и деплой идет быстрее — у нас код попадает в продакшн в течение нескольких дней (а иногда и часов), поэтому сразу виден отклик реальных пользователей на новые изменения в коде. Мы можем намного быстрее реализовывать необходимые функции и «оттачивать» их на основе обратной связи. Среди потока задач находится большой процент интересных (например, оптимизация по производительности и потреблению памяти, рефакторинг кода, улучшения UX). Более того, некоторые не совсем интересные задачи становятся интересными, т.к. тут сразу видна реакция посетителей на результаты твоей работы. У нас не приходится писать код «на склад», который в лучшем случае выйдет в продакшн через пару месяцев.
На данном этапе развития компании здесь я вижу для себя больше возможностей для самореализации и карьерного роста, по сравнению с Google. Что будет дальше, покажет время.