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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

> 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)

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

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

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

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

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

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

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

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

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

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

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

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

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