разработка в гугле

[avva]

Software Engineering at Google (PDF)

Краткое описание того, как устроен процесс работы программистом в Гугле - как хранят исходный код, как устроены системы тестирования, как разные команды работают друг с другом итд.

По-моему все довольно точно описано. Может, стоит добавить, что на практике бывает, что внутри какой-то команды эти принципы работают плохо, или часть из них игнорируют итд. Гугл - большая компания, и в ней бывает всякое. В статье описано, как обычно устроен процесс в нормальной инженерной команде.

Comments

Потом как-нибудь почитаю, спасибо.

[(Anonymous)]

Для меня это не очень актуально, я не начальник, а обычный маленький разработчик, притом работаю в основном на небольшие фирмы, в каждой из которых свои порядки, от которых они не намерены отказываться. Если я буду слишком настойчиво доказывать, как надо правильно вести дела, это только против меня сработает. Либо начальство на своих собственных идеях повёрнуто, либо разработчики-аксакалы работают как привыкли и встречают в штыки любые предложения. В общем, почитав может начальнику своему подсуну, как-бы не всерьёз.

[olialia.livejournal.com]

можете прокомментировать "20% time" из личного опыта? и как оно конкретно устроено: один день в неделю?
спасибо

[(Anonymous)]

Удивил выбор языков Python, C++, Java, Go
А как же JavaScript? А как обстоят дела с функциональными языками?

[netch]

Вот-вот. Я слышал, что его уже лет 5 как отменили. Тогда насколько древний сам документ?

[dimrub.livejournal.com]

Нет, не отменили, но немного изменили. Раньше не было вообще никакого контроля: 20% времени что хочешь, то и делай. Теперь надо представить проект, над которым хочешь работать, начальству для ознакомления, и переодически отчитываться о продвижении (и в течении обозримого времени либо дойти до момента, когда проект из 20% превращается в "настоящий", либо прекратить над ним работу).

[dimrub.livejournal.com]

Есть очень небольшое количество кода на Хаскелле, и есть как минимум одна купленная гуглем компания (ITA software), код который, по крайней мере на момент покупки, был на Лиспе. Джава скрипт используется для кода, бегущего в браузере, само собой.

[avva.livejournal.com]

Javascript несомненно используется в браузере, и это один из самых главных языков по числу строк кода. Его не упомянули в списке из неинтересных соображений (формально говоря это список языков, утвержденных к написанию кода для production servers).

Функциональные языки тут и там используются спорадически их поклонниками, но не более того.

[kray-zemli.livejournal.com]

В компании, где я работаю, около 75% времени уходит на изучение чужого кода. У нас практически полностью отсутствует документация даже на архитектуру, не то чтобы на код. И есть тенденция превращения в спагетти-код тех участков, у которых нет отвечающего за них "собственника". Многие заинтересованы, чтобы "их" часть кода никто не понимал кроме них самих, но это приводит к проблемам, когда люди уходят, даже не из компании, а в другоц проект.

Как с этим в гугле? Как они решают эту проблему? Есть ли какие-то стандарты документирования? Есть ли разграничение ответственности между модулями большой программы?

[kray-zemli.livejournal.com]

Всё дошло до того, что уже никто не понимает, как система работает целиком. Поэтому некому предложить "нормальную" архитектуру, чтобы потом постепенно на неё перейти. Тестовая база неявно является спецификацией поведения. Часто практикуется "экспериментальное программирование", когда люди наугад перетасовывают код, пока побочные эффекты не примут приемлимую форму. Может, это везде так. В конце-концов, это моя первая работа в it. Но мне страшно и возникает желание сбежать в другую компанию. Старички в ответ лишь посмеиваются.

[dimrub.livejournal.com]

Есть стандарты документирования кода - в самом коде, и требования к понятности кода, и эти стандарты соблюдаются в той или иной степени благодаря культуре code reviews: когда тот, кто делает ревью, что-то не понимает в коде, он просит это либо переписать, либо прокоментировать. Иногда также очень помогает наличие юнит-тестов (написание которых считается хорошим тоном), по ним можно понять, почему код написан именно так, и не иначе, и как им пользоваться. Документация на более высоком уровне есть не всегда - это уже сильно зависит от технического руководства того или иного вопроса (но те части технической инфраструктуры, которые используются большим числом внутренних пользователей, как правило, достаточно подробно описаны, и даже снабжены небольшими курсами - code labs). Недовольство уровнем внутренней документации - одна из постоянных жалоб работников Гугля, звучащая в ежегодных опросах работников.

Что же касается job security through obscurity - с таким я не сталкивался. Наоборот, как правило, стараются делать так, чтобы все (или как можно больше) членов команды имели представление о том, как работает тот или иной кусок кода (и уж точно никто не запутывает код специально).

Гугль - далеко не первое мое место работы, и культура написания кода тут сильно выше, чем во всех предыдущих моих местах работы (ваши старички правы: как правило все именно так плохо, как вы описываете). Я думаю, дело тут примерно наполовину в хорошо налаженной инфраструктуре, описанной в статье выше, а наполовину - в критериях отбора людей.

[plus25c.livejournal.com]

можно спросить, почему не MS TFS?

[hervejoncour.livejournal.com]

ЗдОрово. Мои друзья, работающие у вас, рассказывали насколько грамотно всё организовано и я уже который год пытаюсь внедрить нечто подобное у нас на ист косте в финансовой компании. Можно позавидовать такой организации.

Чуть больше десяти лет я работал в Самсунге, одной из их групп в Нью Джерси, так у них не было даже version control system в то время, что было для меня сильным шоком.

Скажите, а что происходит , когда code reviewer, говорит, что ему не нравится конкретный код? Ведь если человек со стороны, то иногда достаточно сложно вникнуть в какие-то тонкости и если в коде нет явных ляпов, то на какие критерии reviewer полагается?

[hervejoncour.livejournal.com]

А вы пользуетесь какими-нибудь frameworks, типа ExtJS/angular или всё своё?

[hervejoncour.livejournal.com]

честно говоря очень трудно понять каким образом можно переключиться и 20% времени заниматься чем-то соверешенно иным. Мне кажется, тут может проявиться конфликт интересов, тем более если у 20% проекта есть свои deadlines, а это не просто coding for fun.

[dimrub.livejournal.com]

Да, это действительно очень непросто. Нужна очень сильная мотивация - не у всех она есть, но некоторым это удается, и довольно много успешных проектов выросли из 20%. Есть еще некоторые ньюансы:

1. Проект на 20% не обязательно должен быть самостоятельным проектом - это может быть вклад в уже имеющийся проект (а это , как правило, проще).
2. Есть способы найти сообщников, и сделать совместный проект, а это веселее, чем в одиночку, шансы на успех повышаются.
3. Дедлайны хоть и есть, но они не такие жесткие - фактически, как правило ожидается, что за пару-тройку кварталов проект дойдет до стадии proof of concept, когда его можно будет показать начальству, и выбить под него head count (после чего он уже не является проектом на 20%).

[djuffin.livejournal.com]

А еще есть Андроид где все совсем по-другому.

[avva.livejournal.com]

В этом полный разброд. Самое близкое к внутреннему стандарту что у нас есть это
https://developers.google.com/closure/
но многие пользуются только js-компилятором оттуда, а не библиотекой Closure (которая по-моему отстала от современных фреймворков во многом). Многие пользуются Angular, есть еще несколько внутренних фреймворков, которые сделали разные команды. Кто-то и на jQuery фигачит.

Взгляд со стороны

[archaicos.livejournal.com]

Android выглядит как некий живой код в том смысле, что он живой, пока над ним трудятся люди, которые стояли у истоков и написали этот код. Документации катастрофически мало. Нужно читать код. Читать код тоже нелегко, т.к. скудные комментарии не заменяют документацию. Документация и комментарии или очень поверхностны и не раскрывают важных деталей, или очень специфичны в деталях и не дают понять общую картину. Надо не забывать ещё и про кучу абстракций, дополнительно усложняющих дело. Прокачивать понимание такого кода тяжело. Описание в commit'ах чрезвычайно краткое. Внутренняя система дефектов недоступна извне. Количество исправлений и откатов (в т.ч. с упоминанием сломанных тестов) намекает на то, что тестирование недостаточное, и внутреннее понимание собственной же имплементации прихрамывает.

Вон там ниже пишут «А еще есть Андроид где все совсем по-другому».

[(Anonymous)]

Неожиданный вопрос. Что такого есть в MS TFS, что его стоит рассматривать как серьёзную альтернативу другим решениям?

[plus25c.livejournal.com]

ну вроде это лучшее, что есть...

[avva.livejournal.com]

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

[avva.livejournal.com]

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

Далее, у нас есть культура довольно придирчивых reviews. Совершенно нормально с точки зрения reviewer'а указать не только на ошибки или баги, но и на места, которые следует по его мнению прокомментировать, рефакторнуть, добавить юнит-тестов или вообще написать по-другому. Автор кода не обязан соглашаться и может отстаивать свою точку зрения, но обычно, если нет с его зрения серьезных причин не делать то, что предлагает reviewer, он это делает. Примеры совершенно обычных комментариев, которые я получаю или сам посылаю в code reviews:

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

В итоге обмена комментариями автора и reviewer'а в идеальном случае получается код, который reviewer тоже хорошо понимает и может при необходимости легко продолжить над ним работу дальше. На практике reviewer может положиться на то, что автор понимает, что делает в определенных местах, особенно если речь идет о вызове каких-то других библиотек или API, с которыми reviewer незнаком. Но структура кода в целом и причина, почему написано так, а не иначе, ему обычно понятна.

[plus25c.livejournal.com]

да, здорово!

[hervejoncour.livejournal.com]

Спасибо за подробное объяснение.

[hervejoncour.livejournal.com]

Спасибо!

[oldjackaroo.livejournal.com]

Исключения из правила "reviewer из той же команды" тоже достаточно часты, в основном это когда нужен readability reviewer, а в своей команде его нет или он перегружен другими делами. Правда, чаще всего он при этом не лезет глубоко в логику кода, ограничиваясь проверкой формальных правил и рекомендаций по конкретному языку (которые иногда спорны - за что я недолюбливаю Go).

[michaelm1234.livejournal.com]

начинаю читать, и вот тут такое:

> Most of Google’s code is stored in a single unified source-code repository

Какой смысл держать большой общий архив для групп без общего кода вообще ?

> Almost all development occurs at the “head” of the repository

как так можно жить в огромном архиве без бранчей? группа А изменяет библиотеку для группы Б; если группа А поломала свою библиотеку так все пользователи горько плачут. Как быть с промежуточной итеграцией которая затрагивает результаты разных групп? так вроде невозможно откатать архив даже ?

> Most software at Google gets rewritten every few years

звучит очень странно. Это верно для Chrome и Android тоже ?

Еще концептуальный вопрос: когда Гугл подавится количеством данных которые он собирает на всех своих пользователей, в том смысле что будет невозможно извлечь информацию которая определяет интересы / профиль пользователя? Вот я задаю кучу запросов поиска на разные темы и хром посылает обратно домой все сайты по котрым я хожу: как Гугл вообще может подытожить чем я интересуюсь, когда я это сам не знаю?

[avva.livejournal.com]

Групп без общего кода довольно мало; как минимум стандартные библиотеки protocol buffers и RPC используют подавляющее большинство проектов.

В отдельных случаях группы держат свой код в отдельной репозитории, главные примеры этого - Chrome и Android, как указано в статье. Другой пример из тех, что не упомянуты - репозитория группы, которая работает над гуглевскими изменениями в ядре Линукса.

>как так можно жить в огромном архиве без бранчей?

Бранчи есть и используются, но главным образом как для рилизов. Есть группы, которые всю свою разработку ведут на бранче и время от времени синхронизируются с HEAD, но это исключение, а не правило.

>группа А изменяет библиотеку для группы Б; если группа А поломала свою библиотеку так все пользователи горько плачут.

Повсеместное использование юниттестов и presubmit-проверок означает, что библиотеки, которыми пользуются другие группы, редко оказываются сломанными в HEAD. Типичная presubmit-проверка запускает автоматически в специальном тестовом облаке все юнит-тесты кода, который зависит от любых файлов, измененных в данном сабмите. Не всегда это помогает, потому что в зависимости от тяжести и изолированности данной библиотеки ее использование в другом коде может быть mocked out, но в таких случаях библиотека сама обычно имеет обширные юнит-тесты, которые проверяют ее поведение.

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

Вдобавок ко всему вышеупомянутому небольшое количество особенно важных базовых библиотек обновляются не все время, а каждую неделю-две, организованными рилизами; при этом их разработка все равно идет в HEAD, но сделано так, что код, который их использует, по умолчанию видит версию последнего рилиза (сидящую тут же, в общей репозитории).

>Как быть с промежуточной итеграцией которая затрагивает результаты разных групп? так вроде невозможно откатать архив даже ?

Этот вопрос не очень понял.

[michaelm1234.livejournal.com]

Спасибо.

>Этот вопрос не очень понял.

Группа А хочет поделится промежуточным результатом с группой Б; посредством отдельного бранча можно поделится промежуточным результатом не затрагивая главный бранч.

[avva.livejournal.com]

Все равно не очень понятно. Как группа Б должна использовать новую работу группы А?

- если это настолько сырой код, что он не проходит тесты или не отвечает стандартам и его нельзя сабмитить в HEAD, то делиться им с группой Б преждевременно. В исключительных случаях нет проблемы сказать человеку: нужное тебе находится в CL (ChangeList) номер 12345678, он еще в разработке, но если тебе очень нужно его попробовать, можешь его клонировать и локально у себя построить свой проект с его участием.

- если это готовый для сабмита промежуточный результат и какой-то совершенно новый код (новые функции, новые RPC), то нет проблем сабмитить его в HEAD и пусть группа Б им пользуется, а другие пока нет, потому что просто не знают о нем. При желании есть возможность не дать другим группам линковаться с этим кодом, но этим редко пользуются (этим чаще пользуются для кода, который должен быть внутренним и не предназначен для вызова другими группами).

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

Предложенный способ - специальный бранч для группы Б - технически можно провернуть, но это очень анти-паттерновое поведение, если так и поступают, то очень редко.

Не совсем про Гугль

[loqva.livejournal.com]

Вот, встретила прекрасное в сети, и этот пост кажется мне подходящим местом, чтоб поделиться:
https://youtu.be/RU8mFmhcz-s

[azangru.livejournal.com]

А Polymer как же? :-)

[a-konst.livejournal.com]

ну разве что если добавить "среди написанного Microsoft"

[monka.livejournal.com]

О, теперь я знаю, о чем можно рассказывать! А то раньше никогда не уверена была, что можно, а что защищено NDA.

[avva.livejournal.com]

У меня та же мысль промелькнула :)

[(Anonymous)]

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

[plus25c.livejournal.com]

да, я уже поняла. спасибо.

[occuserpens.livejournal.com]

Google CEO pens encouraging reply to 7-year-old girl's job application (https://www.cnet.com/news/google-ceo-sundar-pichai-replies-to-7-year-old-girls-job-application/)

[nec-p1us-u1tra.livejournal.com]

> Most of Google’s code is stored in a single unified source-code repository, and is accessible to all software engineers at Google​

В Оракле категорически нет. source code is strictly confidential, access provided on "need-to-have" basis.

> Each subtree of the repository can have a file listing the user ids of the “owners” of that subtree.

Что с массовыми увольнениями? Уход команды, добровольный или нет, осиротит поддерево?

> Individual build steps must be “hermetic”: they depend only on their declared inputs.
> Individual build steps are deterministic.

О. Неужели нету "этот код написал 20 лет назад священными предками и собирается только при данных танцах. Менять не смей, ибо может вообще больше никогда не собраться"? Круто.

> Most software at Google gets rewritten every few years. Rewriting code cuts away all the unnecessary accumulated complexity that was addressing requirements which are no longer so important.

Завидую. "А это вот делаем через жопу, потому что иначе оно не работает на Солярисе 8, а нам еще епонцы за него платят"

[shadow-ru.livejournal.com]

Вообще-то, он есть в списке. Или файл обновили?

[efix.livejournal.com]

а можете немного расказать про readability training process?

[dimrub.livejournal.com]

Мои сведения несколько устарели, поскольку свой С++ readability я получил уже лет 7 назад, а больше никакого получить не пытался (ну, пытался Пайтон, но забил на это дело). Раньше для получения ридабилити надо было предоставить комиссии большой комит, с кучей всяких требований: чтобы был целый новый класс, чтобы контрол лоджик был, чтобы тесты (само собой), плюс какой-то минимум по числу строк и по нетривиальности кода. Потом этот коммит представитель комиссии долго-предолго мурыжил (это при том, что коммит уже одобрен кем-то из других программистов в проекте!) и, наконец, давали одобрямс. Теперь, насколько я знаю (но очень понаслышке) процесс изменился, и он постепенный: человек, находящийся в процессе, все свои нетривиальные коммиты посылает комиссии, та дает ему какое-то число очков за каждый, и по достижении какой-то отметки автоматически дается ридабилити. Как-то так, вроде бы.

[efix.livejournal.com]

Понятно, спасибо!
Я думал там как-то особо натаскивают писать клин код.