Как разрабатывают Facebook

На сегодняшний день проект Facebook представлен на клиентской стороне мобильными сайтами m.facebook.com, 0.facebook.com, мобильными приложениями Facebook для iPhone и Android, а также сайтом www.facebook.com, который в узких кругах (примерно 750 млн жителей этой планеты) пользуется наибольшей известностью.

Размер проекта накладывает определенные ограничения на структуру команды разработчиков. Если пробежаться по вакансиям компании, то можно составить следующую грубую категоризацию:

  • Разработчики продукта. Они чаще всего заняты разработкой функционала, который наблюдают посетители сайта, однако продуктом вполне может быть и какая-то внутренняя система, у которой тоже может быть приятный дизайн и юзабельные инструменты. Основные инструменты — PHP, CSS, JavaScript.
  • Инфраструктурные программисты. Сюда можно отнести как людей, занимающихся непосредственно инфраструктурой сайта (репликация данных между дата-центрами, поддержка поиска и рекламной системы), так и разработчиков, занимающихся разработкой и доработкой Hadoop, тренировкой и тестированием моделей искусственного интеллекта, обработкой и сжатием фото и т.д. Инструменты работы — C++, Java, Erlang, Python, PHP.

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

  • Дизайнеры. В основном занимаются созданием поведенческой модели пользователя и написанием интерфейса, обслуживающего эту модель. Также следят за унификацией элементов дизайна. Для искоренения последней проблемы чаще всего пишут всякие таги в XHP, дабы отбить у разработчиков охоту писать CSS и JavaScript для элементов, которые уже созданы.
  • Аналитики данных. Обладают пониманием Hive, Hadoop (в качестве пользователей) и чаще всего дипломом по специальности «Статистика». На ранних порах разработки продукта могут дать ответы на вопросы о нынешних тенденциях поведения пользователей. Позднее могут интерпретировать результаты A/Б-тестирования, рассмотреть результаты запуска в зависимости от страны либо языка пользователя.
  • Менеджер продукта. Иногда является и менеджером проекта, однако ввиду предпочтения небольшим командам чаще всего занимается сугубо продуктом. После устаканивания общего видения продукта вместе с дизайнером разрабатывает макеты, описывающее конечную цель разработки. Если продукт оперирует с продуктами других команд (а внутри тесно-интегрированного проекта это более правило, чем исключение), извещает о планах своей команды других. Занимается демонстрацией первых бета-версий заинтересованным лицам и командам. Стоит сделать отступление и отметить, что несмотря на вроде как управленческую должность, менеджер продукта не управляет собственно разработчиками — структурно разработчик по карьерной лестнице рано или поздно подчинится вице-президенту по разработке, а вот менеджер продукта в итоге подчиняется вице-президенту по продуктовой стратегии.

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

  • Группы на Facebook — закрытые группы используются для обсуждения макетов, распространения информации о чрезвычайных ситуациях и планов на будущее. Демократическая суть групп разрешает также кому угодно — от разработчика и до гендиректора — внести идею и посмотреть, как к этому относятся остальные участники команды.
  • Phabricator — интегрированный пакет для написания, тестирования, рецензий и релиза кода.
  • Весьма похожий на Асану инструмент для управления задачами. Тесно интегрирован с Phabricator. В большинстве случаев заменяет электронную почту.
  • Популярное

21 комментарий

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

Весьма познавательно. Спасибо.

Весьма познавательно. Спасибо.

Благодарю, Алекс, за очень полезную статью!

Судя по всему, ты отличный разработчик.

И еще один вопрос по поводу документации (просто мне как разрабочику под платформу FB наболело). Почему все так плохо? Т.е. если «very engineering driven culture», то о причинах я могу догадаться. Но как я понимаю разрабочики не занимаются тем, чтобы документировать свои изменения?

Чаще всего новые фичи выкатываюся как блог пост с примерами PHP-кода. Свежий пример из головы — на сайте нигде нельзя найти до каких ресурсы можно достучаться через FB read-only сервер. Для этого приходится заглядывать в PHP SDK. Особенно это очень приятно делать для людей, который пишут не на PHP. Еще пример — bugs.developers.facebook.net/...g.cgi?id=13377 Особенно мне нравится ответ " We’ll track this as a wishlist item for now.«. Т.е. судя по «Engineers generally want to work on infrastructure, scalability and „hard problems“» вероятность того, что этот баг пофиксят равна нулю.

Раздражает, насколько я понимаю, не столько наличие нового функционала, сколько стабильность старого. Я к этой команде имею только косвенное отношение, но шаги в этом плане делаются developers.facebook.com/blog/post/550

Также интересно было бы узнать про “very engineering driven culture” (как описано тут — framethink.wordpress.com/...k-ships-code/) Некоторые вещи меня из этой статьи не перестают удивлять. Например:
— Engineers can modify specs mid-process, re-order work projects, and inject new feature ideas anytime
— Engineer talks to their manager, says “I’d like to work on these 5 things this week”
— Engineers handle entire feature themselves — front end javascript, backend database code, and everything in between. If they want help from a Designer (there are a limited staff of dedicated designers available), they need to get a Designer interested enough in their project to take it on.

— Engineers generally want to work on infrastructure, scalability and “hard problems” — that’s where all the prestige is. can be hard to get engineers excited about working on front-end projects and user interfaces.

Действительно ли все так работает? Т.е. каждый инженер — это сам себе хозяин и делает все что захочет и когда захочет? Звучит как фантастика.

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

Это мечта вообще : ) Есть к чему стремиться))

Скажу по секрету: такая практика применяется во всех вменяемых стартапах.

Тоже по секрету, Фейсбук — не стартап.

Фейсбук не вышел еще на ипо, значит фактически это еще стартап.

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

А что по поводу тестирования?

пользователи тестируют :)

(примерно 750 млн жителей этой планеты) пользуется наибольшей известностью.

Видимо так...

Tue Jun 29 2010 — Не самая «свежая» инфа...

это инсайдерская информация? или перевод какой-то статьи?

Судя по всему инсайдерская: www.linkedin.com/in/prostoalex

Правда никакого эксклюзива особого

5 лет работы в фейсбуке — вызывает уважение

Подписаться на комментарии