Pull to refresh

Как Facebook разрабатывает код

Reading time 8 min
Views 2.5K
Перевод оригинальной статьи.

Как Facebook разрабатывает код


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

Прошло более шести месяцев с момента, как я собрал эти наблюдение, и я уверен, что даже сейчас Facebook постоянно совершенствует свои методики разработки ПО. Так что эти заметки, возможно, немного устарели. А также, похоже, что культура Facebook, управляемая разработчиками, получает всё большее внимание общественности. Так что я чувствую себя теперь более комфортно, выпуская эти заметки… ОГРОМНОЕ спасибо многим людям, которые помогли собрать воедино это представление о Facebook изнутри! Также выражаю благодарности людям epries и fryfrog, которые внесли исправления и отредактировали.

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


Заметки:
  • По состоянию на июнь 2010 компания состояла почти из 2000 сотрудников, имея 1100 сотрудников за 10 месяцев до этого. Практически удвоив штат менее чем за год!
  • Самые крупные команды — это специалисты и оперативный отдел, примерно 400-500 человек в каждой. Обе команды составляют почти 50% всего штата.
  • Отношение количества менеджеров к количеству специалистов примерно 1:7 или 1:10.
  • Все специалисты проходят через 4-6 недельный тренинг в учебном центре, где они изучают систему Facebook путём исправления ошибок (баг-фиксинг) и слушая лекции старших/штатных специалистов. Примерно 10% людей из каждого тренировочного класса не проходят дальше и увольняются с рекомендациями от компании.
  • После учебного центра все специалисты получают доступ к актуальной базе данных (в сопровождении стандартной лекции «С великой силой приходит великая ответственность» и чётким списком «преступления-к-увольнению» (fire-able offenses), например, раскрытие личных данных пользователя).
  • [Ред. thx fryfrog] «Есть также очень хорошие меры безопасности, чтобы уберечь любого в компании от совершения ужасных вещей, которые могут придти в голову. Окружающие имеют возможность войти в курс дела и попытаться решить проблему. Но если вы всё же „становитесь“ тем, кому необходима помощь, этот факт регистрируется наряду с причиной и тщательно рассматривается. Сбиваться с истинного пути здесь не позволительно, конечно же».
  • Любой специалист может изменить любую часть кода Facebook и комитить его по своему желанию.
  • Культура, управляемая разработчиками. «Менеджеры продуктов, по-существу, бесполезны здесь» — цитата специалиста. Специалисты могут изменять спецификации самого процесса разработки, изменять порядок рабочих проектов и внедрять новые идеи в любое время.
  • В течение ежемесячных меж-командных совещаний, специалисты — единственные, кто предоставляет отчет о прогрессе. Отделы маркетинга и менеджмента принимают участие в этих совещаниях, но если они слишком откровенны, это докладывается руководству как «продакт слишком много говорил на последнем совещании». Они на самом деле хотят, чтобы специалисты открыто были собственниками своих разработок и являлись главным звеном связи для проектов, которые они же и разработали.
  • Выделение ресурсов для проектов абсолютно добровольное.
    • PM собирает группу специалистов, пытается дать им возможность войти в азарт, обсуждая собственные идеи.
    • Специалисты решают, какая из идей звучит более интересно, чтобы начать работу над ней.
    • Специалисты общаются со своими менеджерами и говорят: «Я бы хотел поработать вот над этими 5 вещами в течение недели».
    • Тех. директора обычно оставляет предпочтения специалистов на их усмотрение, иногда могут попросить сделать определённые задачи в первую очередь.
    • Специалисты управляют всей разработкой сами — JavaScript на фронтенде, код базы данных на бекенде и всё, что между ними. Если они хотят получить помощь дизайнера (штат профильных дизайнеров ограничен), они вынуждены достаточно сильно заинтересовать дизайнера, чтобы тот взялся за их проект. То же самое относится к архитекторам. Но ожидается, что в большинстве случаев специалисты сами справятся со всеми своими потребностями.

  • Стоит ли идея выеденного яйца обычно становится ясно в течение недели её внедрения и дальнейшего тестирования на выборочных пользователях, например, 1% пользователях штата Невада.
  • В общем и целом специалисты предпочитают работать над инфраструктурой, масштабируемостью и «трудными проблемами» — самые престижные области. Может быть трудно наблюдать специалистов, увлечённо работающих над фронтенд-проектами и пользовательскими интерфейсами. Это противоположно тому, что вы можете видеть на других потребительских рынках, где каждый хочет разрабатывать вещи, к которым пользователи непосредственно прикасаются, и вы можете ткнуть пальцем на конкретную часть и сказать «я сделал это». В Facebook серверная часть, вроде алгоритмов новостных лент, алгоритмы таргетированной рекламы, оптимизация memcache и т.п., — первоклассные проекты, над которыми специалисты хотят работать.
  • Комиты, которые влияют на некоторый высоко-приоритетный функционал (например, новостная лента), проходят проверку кода перед слиянием (прим. пер. «merge»). Новостная лента весьма важна, так что сам Цукерберг просматривает любые её изменения, но это — исключительный случай.
  • [Исправление — thx epriest] «Существует обязательная проверка кода всех изменений (одним или несколькими специалистами). Я думаю, что пункт просто поясняет, что Цук не смотрит на каждое изменение персонально».
  • [Исправление thx fryfrog] «Все изменения просматриваются как минимум одним человеком, и система такова, что любой другой может взять и просмотреть твой код, даже если ты не просил. В противном случае, это может привести к умышленному внедрению вредоносного кода в непроверенный код».
  • Специалисты ответственны за тестирование, исправление ошибок и поддержку своей работы после запуска. Доступны несколько unit-testing и integration-testing фреймворков, но они используются только время от времени.
  • [Исправление thx fryfrog] «Я также хотел бы добавить, что у нас, конечно же, есть QA, просто не официальная группа. Каждый сотрудник, находящийся в офисе или подключённый по VPN, использует версию сайта, включающую все изменения, стоящие в очереди на очередную выкладку. Эта версия обновляется постоянно и обычно за 1-12 часов до того, как весь мир её увидит. Всем сотрудникам настоятельно рекомендуется сообщать о любых найденных ошибках, и всё это очень хорошо работает».
  • re: удивлён отсутствием QA или автоматизированных юнит-тестов — «большинство специалистов способны писать безошибочный код. Это то, что они не видят смысла делать в большинстве компаний: когда есть QA-отдел, легко просто швырнуть всё им, чтобы найти ошибки.» [Пожалуйста, заметьте, что это было субъективное мнение, я написал это из-за разительного контраста, который видится в стандартной практике разработки других компаний].
  • [Исправление thx epriest] «У нас есть автоматическое тестирование, включая „push-blocking“ тесты, которые обязаны проходить перед выкладкой релиза. Мы абсолютно не верим в фразу „большинство специалистов способны писать безошибочный код“, мы больше считаем, что это разумно как один из основных принципов разработки.»
  • re: удивлён отсутствием влияния/контроля PM — у менеджеров много независимости и свободы. Ключ к независимости — построить действительно хорошие отношения с техническими директорами. Нужно быть достаточно технически-подкованным, чтобы не предлагать глупые идеи. Кроме этого, нет необходимости просить разрешение или проходить какие-то проверки роадмепов/беклогов. «Мой директор по продукту даже не знает все вещи, которые есть в моем роадмепе». Соответственно, есть несколько PM, но все они чувствуют, что несут большую ответственность за действительно важную область в компании, с личной заинтересованностью.
  • По-умолчанию, все комиты кода упаковываются в недельные релизы (вторники).
  • При дополнительных усилиях изменения могут быть выложены в тот же день.
  • Релизы по вторникам требуют присутствия всех специалистов, кто комитил код на предыдущей неделе для релиз-кандидата, который должен быть выложен.
  • Перед началом релиза специалисты должны присутствовать на специальном IRC-канале для «зова на выкладку», иначе будут наказаны на публичном «посрамлении».
  • Команда операционистов запускает релиз, постепенно выкатывая его на серверы.
    • Facebook имеет около 60 000 серверов.
    • Существует 9 концентрических уровней для выкатки нового релиза.
    • [Исправление thx epriest] «Девять этапов выкладки не концентрические. Существует 3 концентрических этапа (p1 = внутренний релиз, p2 = маленький внешний релиз, p3 = полный внешний релиз). Остальные шесть этапов — вспомогательные уровни типа внутреннего инструментария, сервера загрузки видео, т.п.»
    • Самый маленький уровень — 6 серверов.
    • Например, каждый вторничный релиз выкатывается на 6 серверов (уровень 1), затем команда операционистов наблюдает за этими 6-ю серверами и убеждается, что они работают правильно перед тем, как выкатывать на следующий уровень.
    • Если в релизе возникают какие-либо проблемы (например, падают ошибки, т.п.), тогда выкладка отменяется. Специалист, который сделал неисправный комит, вызывается для исправления ошибки. Затем выкладка начинается с начала.
    • Таким образом, релиз может проходит через уровни многократно: 1-2-3-исправления. Возврат к 1. 1-2-3-4-5-исправления. Возврат к 1. 1-2-3-4-5-6-7-8-9.

  • Команда операционистов действительно хорошо подготовлена, сплочена и очень заботится о своём деле. Их серверные показатели представляют собой больше, чем просто отчеты об ошибках, показателях загрузки и использовании памяти — они также включают в себя пользовательские показатели. Например, если новый релиз меняет процент людей, пользующихся Facebook, команда операционистов видит это в своих показателях и поэтому может остановить релиз для выяснения проблемы.
  • В течение выкладки релиза команда операционистов использует пейджинговую связь, основанную на IRC, которая может перебрасывать информацию инженерам через Facebook, e-mail, IRC, IM и СМС, если требуется их внимание. Игнорирование сообщений операционистов приводит к публичному «посрамлению».
  • Как только код выкачен на уровень 9 и он стабилен, недельная вакладка считается завершённой.
  • Если функционал не был разработан вовремя ко дню недельной выкладки, то это не так критично (если он не содержит жестких внешних зависимостей) — функционал просто будет полностью внедрен когда будет доделан.
  • Получая svn-жалобы (svn-blammed), публичное посрамление или слишком частая задержка проектов может сказаться увольнением специалиста. «Это очень высокоэффективная культура». Люди, которые непродуктивны или не супер-одарены, действительно ставят себя под удар. Менеджеры буквально возьмут, отведут неуспевающих в сторону в течение 6 месяцев после найма и скажут «Просто не получилось, вы недостаточно подходите для этой культуры». Вообще, это применительно к любому уровню компании, даже нанятые на С-уровень и VP-уровень были быстро уволены, если они не были супер-продуктивными.
  • [Исправление, thx epriest] «Люди не вызываются для ознакомления с ошибками. Они вызываются только лишь если они попросили, чтобы изменения вошли в релиз, но не для поддержки изменений, когда что-то пошло не так (и если не нашли никого для замены)».
  • [Исправление, thx epriest] «Из-за жалоб вас НЕ уволят (прим. переводчика: имеется ввиду svn-blame). Мы чрезвычайно снисходительны в этом отношении, и большинство главных специалистов выкладывали как минимум одну ужасную вещь, включая меня самого. Насколько я знаю, никто не был когда-либо уволен за совершение подобного рода ошибок.»
  • [Исправление, thx fryfrog] «Я также не знаю никого, кто был бы уволен за ошибки, приведённые в статье. Я знаю людей, кто ненароком ронял сайт. Они тяжело работают над исправлением того, что вызвало проблему, и каждый учится на этом. Публичное посрамление гораздо более эффективно, нежели страх быть уволенным, по моему мнению».


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

Оригинальная статья

Если в переводе есть неточности и ошибки, пожалуйста, напишите в личку, внесу исправления.
Tags:
Hubs:
+48
Comments 44
Comments Comments 44

Articles