?

Log in

No account? Create an account
разработка в гугле - Поклонник деепричастий [entries|archive|friends|userinfo]
Anatoly Vorobey

[ website | Website ]
[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

Links
[Links:| English-language weblog ]

разработка в гугле [фев. 11, 2017|04:59 pm]
Anatoly Vorobey
[Tags|]

Software Engineering at Google (PDF)

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

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

Comments:
From: (Anonymous)
2017-02-11 03:39 pm

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

Для меня это не очень актуально, я не начальник, а обычный маленький разработчик, притом работаю в основном на небольшие фирмы, в каждой из которых свои порядки, от которых они не намерены отказываться. Если я буду слишком настойчиво доказывать, как надо правильно вести дела, это только против меня сработает. Либо начальство на своих собственных идеях повёрнуто, либо разработчики-аксакалы работают как привыкли и встречают в штыки любые предложения. В общем, почитав может начальнику своему подсуну, как-бы не всерьёз.
(Ответить) (Thread)
[User Picture]From: olialia
2017-02-11 04:18 pm
можете прокомментировать "20% time" из личного опыта? и как оно конкретно устроено: один день в неделю?
спасибо
(Ответить) (Thread)
[User Picture]From: netch
2017-02-11 05:36 pm
Вот-вот. Я слышал, что его уже лет 5 как отменили. Тогда насколько древний сам документ?
(Ответить) (Parent) (Thread) (Развернуть)
From: (Anonymous)
2017-02-11 04:36 pm
Удивил выбор языков Python, C++, Java, Go
А как же JavaScript? А как обстоят дела с функциональными языками?
(Ответить) (Thread)
[User Picture]From: dimrub
2017-02-11 05:44 pm
Есть очень небольшое количество кода на Хаскелле, и есть как минимум одна купленная гуглем компания (ITA software), код который, по крайней мере на момент покупки, был на Лиспе. Джава скрипт используется для кода, бегущего в браузере, само собой.
(Ответить) (Parent) (Thread)
[User Picture]From: kray_zemli
2017-02-11 07:33 pm
В компании, где я работаю, около 75% времени уходит на изучение чужого кода. У нас практически полностью отсутствует документация даже на архитектуру, не то чтобы на код. И есть тенденция превращения в спагетти-код тех участков, у которых нет отвечающего за них "собственника". Многие заинтересованы, чтобы "их" часть кода никто не понимал кроме них самих, но это приводит к проблемам, когда люди уходят, даже не из компании, а в другоц проект.

Как с этим в гугле? Как они решают эту проблему? Есть ли какие-то стандарты документирования? Есть ли разграничение ответственности между модулями большой программы?
(Ответить) (Thread)
[User Picture]From: kray_zemli
2017-02-11 07:39 pm
Всё дошло до того, что уже никто не понимает, как система работает целиком. Поэтому некому предложить "нормальную" архитектуру, чтобы потом постепенно на неё перейти. Тестовая база неявно является спецификацией поведения. Часто практикуется "экспериментальное программирование", когда люди наугад перетасовывают код, пока побочные эффекты не примут приемлимую форму. Может, это везде так. В конце-концов, это моя первая работа в it. Но мне страшно и возникает желание сбежать в другую компанию. Старички в ответ лишь посмеиваются.
(Ответить) (Parent) (Thread)
[User Picture]From: plus25c
2017-02-11 08:39 pm
можно спросить, почему не MS TFS?
(Ответить) (Thread)
From: (Anonymous)
2017-02-11 11:41 pm
Неожиданный вопрос. Что такого есть в MS TFS, что его стоит рассматривать как серьёзную альтернативу другим решениям?
(Ответить) (Parent) (Thread) (Развернуть)
[User Picture]From: hervejoncour
2017-02-11 09:29 pm
ЗдОрово. Мои друзья, работающие у вас, рассказывали насколько грамотно всё организовано и я уже который год пытаюсь внедрить нечто подобное у нас на ист косте в финансовой компании. Можно позавидовать такой организации.

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

Скажите, а что происходит , когда code reviewer, говорит, что ему не нравится конкретный код? Ведь если человек со стороны, то иногда достаточно сложно вникнуть в какие-то тонкости и если в коде нет явных ляпов, то на какие критерии reviewer полагается?
(Ответить) (Thread)
[User Picture]From: avva
2017-02-12 12:34 am
Reviewer практически всегда из той же команды и как минимум в общих чертах он понимает, зачем этот код и что он должен делать. Т.е. он не со стороны в этом смысле. Понятно, что над данным конкретным кодом, возможно, в последнее время работал только его автор, но его задача в том числе писать так, чтобы другому разработчику, знакомому с проектом в целом, не было слишком тяжело понять.

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

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

В итоге обмена комментариями автора и reviewer'а в идеальном случае получается код, который reviewer тоже хорошо понимает и может при необходимости легко продолжить над ним работу дальше. На практике reviewer может положиться на то, что автор понимает, что делает в определенных местах, особенно если речь идет о вызове каких-то других библиотек или API, с которыми reviewer незнаком. Но структура кода в целом и причина, почему написано так, а не иначе, ему обычно понятна.
(Ответить) (Parent) (Thread) (Развернуть)
[User Picture]From: djuffin
2017-02-11 10:10 pm
А еще есть Андроид где все совсем по-другому.
(Ответить) (Thread)
[User Picture]From: michaelm1234
2017-02-12 09:55 am
начинаю читать, и вот тут такое:

> 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 тоже ?

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

Edited at 2017-02-12 10:11 (UTC)
(Ответить) (Thread)
[User Picture]From: avva
2017-02-12 10:17 am
Групп без общего кода довольно мало; как минимум стандартные библиотеки protocol buffers и RPC используют подавляющее большинство проектов.

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

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

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

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

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

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

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

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

Этот вопрос не очень понял.
(Ответить) (Parent) (Thread) (Развернуть)
[User Picture]From: loqva
2017-02-12 02:25 pm

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

Вот, встретила прекрасное в сети, и этот пост кажется мне подходящим местом, чтоб поделиться:
https://youtu.be/RU8mFmhcz-s
(Ответить) (Thread)
[User Picture]From: monka
2017-02-12 10:34 pm
О, теперь я знаю, о чем можно рассказывать! А то раньше никогда не уверена была, что можно, а что защищено NDA.
(Ответить) (Thread)
[User Picture]From: avva
2017-02-12 10:50 pm
У меня та же мысль промелькнула :)
(Ответить) (Parent) (Thread)
[User Picture]From: nec_p1us_u1tra
2017-02-16 06:33 pm
> 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, а нам еще епонцы за него платят"
(Ответить) (Thread)