Пользователь
0,0
рейтинг
18 января 2011 в 17:52

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

Перевод оригинальной статьи.

Как 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 эволюционирует со временем, и особенно увидеть, как эта культура сможет продолжить расширяться с расширением самой компании до тысяч работников.
Что вы думаете? Будет ли «культура, управляемая разработчиками», работать в вашей компании?

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

Если в переводе есть неточности и ошибки, пожалуйста, напишите в личку, внесу исправления.
Nicholas S. @theOnlyBoy
карма
38,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое

Комментарии (44)

  • НЛО прилетело и опубликовало эту надпись здесь
    • –3
      Попробуйте прочитать оригинал статьи, возможно, больше понравится.
    • +3
      Согласен, про литературный перевод автор явно не слышал.
    • +2
      Аналогично. Перевод корявый, как будто за автоматизированным переводчиком поправляли, но не все поправили.
    • +1
      Дело не только в переводе, но и в согласованности частей предложений. Чтобы понять смысл, приходится брать отдельные слова и заново строить из них предложение.
      • –6
        Проще не брать отдельные слова, а взять и прочитать оригинал. Перевод вообще наугад.
    • +1
      В оригинале текст тоже не слишком складный. Так что и то и другое.
  • –1
    Интересный материал, спасибо.

    «Любой специалист может изменить любую часть кода Facebook и комитить его по своему желанию» — от этого предложения, мне стало не по себе :)
    • –1
      Все можно откатить назад, в случае чего.
    • НЛО прилетело и опубликовало эту надпись здесь
  • +8
    Перевод ужасный, интересно но читать невозможно.
    Такое нельзя переводить дословно, надо и текстовые конструкции оптимизировать к русскому формату, т.к. то что нормально для иностранного языка при дословном переводе кошмарно смотрится в русском…
    • –7
      Увы, я не профессиональный переводчик, переводил в паузах рабочего дня, хотел поделиться интересной статьей. Лучше, конечно, всегда читать в оригинале, если можете.

      Да, и запятые я ставлю все-таки лучше, чем вы.
      • +3
        >Увы, я не профессиональный переводчик, переводил в паузах рабочего дня, хотел поделиться интересной статьей. Лучше, конечно, всегда читать в оригинале, если можете.

        Перевести для остальных — прекрасное дело. Однако, перевод не очень, мягко говоря.

        >Да, и запятые я ставлю все-таки лучше, чем вы.

        Это несомненно. Только какое отношение это имеет к тому, что текст переведен плохо, и читать его невозможно?
        • –3
          Да я согласен с вами, перевод так себе.
          • –1
            Чего, хороший что ли?
  • 0
    2000 человек?

    Они или какой-то другой facebook разрабатывают или на асме всё пишут?
  • 0
    Хорошая статья. Интересная. Но перевод просто беспощадно убил :)
  • +5
    Чем там занимаются менеджеры?
    Я один не понял?
    • +4
      отводят в сторонку, и говорят «Не получилось у тебя с нами» :)
    • 0
      Разжигают и поддерживают энтузиазм, обсуждая фичи. Остальное туманно.
      Например, так и не понял, кто планирует в каком порядке реализовывать идеи.
      • 0
        Разработчики сами и планируют в большинстве случаев.

        # Специалисты решают, какая из идей звучит более интересно, чтобы начать работу над ней.
        # Специалисты общаются со своими менеджерами и говорят: «Я бы хотел поработать вот над этими 5 вещами в течение недели».
        # Тех. директора обычно оставляет предпочтения специалистов на их усмотрение, иногда могут попросить сделать определённые задачи в первую очередь.
  • +4
    Это ярки пример того, как переводит google + человек, а не человек + google.
    Ведь всех же учили когда-то «Прочитай, осмысли и изложи своими словами максимально близко к оригиналу»
  • НЛО прилетело и опубликовало эту надпись здесь
  • +1
    В оригинале blame не имеет такого негативного оттенка, как «посрамление».
    • 0
      Укажите, где «blame» переведено как «посрамление»?
      • 0
        Моя ошибка.
  • 0
    Ну и я очень поражен наличием доступа к живой базе данных у программистов.
  • 0
    Очень-очень интересная информация, которая очень-очень ужасно структурирована и криво переведена. Это просто черновик какой-то. Кто кому там отвечает? Кто с кем ведёт диалог? Где чьи слова и что дописал «переводчик»? Структурируйте текст, отдайте паре человек на вычитку, используйте устоявшуюся терминологию, замените англоязычное построение предложений на русскоязычное.
    Тема очень интересная, за это спасибо.
    Успехов.
    • –1
      Если кто-то возьмется доработать — пожалуйста.
  • 0
    Это просто невозможно читать. Ужасный перевод.
  • 0
    Перевести engineer, как специалист, а не инженер — это сильно :)
    • 0
      Посмотрите в словарь терминов, в компьютерной терминологии переводится как «специалист». Хотя инженер применимо тоже.
  • +2
    Хахах посрамление классное словцо!
  • +8
    Я прочитал этот текст до конца!
  • НЛО прилетело и опубликовало эту надпись здесь
    • НЛО прилетело и опубликовало эту надпись здесь
  • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      Судя по перекачки мозгов из Google в Facebook, то предположу что во второй культура лучше.
  • 0
    Свобода, возможность изменять код по своему желанию, бла бла бла. В итоге фейсбук выглядит и работает как взорвавшаяся макаронная фабрика. Вроде макароны можно жевать и их много, но на красиво уложенные спагетти это не похоже.
    • НЛО прилетело и опубликовало эту надпись здесь
      • 0
        Недавно была статья и срач под ней, что Facebook очень сильно переоценен.
      • –1
        Замечательный аргумент. Миллионы леммингов не могут ошибаться.
  • 0
    Прочел до конца.
    Текст какой-то каструбатый. Сложно читать.
    А идеи интересные.
  • 0
    в FB даже в таком важном деле как разработка кода все пахнет социальщиной…

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.