Делай как вGoogle
 Скачать 5.77 Mb.
|
|
Стимулы и признание Хорошую культуру необходимо активно развивать, и для продвижения культуры обмена знаниями необходимо иметь систему поощрений и вознаграждений. Для многих организаций характерна распространенная ошибка, когда на словах говорят о наборе ценностей, а на деле активно поощряют поведение, не связанное с этими цен- ностями. Люди реагируют на стимулы, а не на дежурные фразы, поэтому при создании системы поощрений и вознаграждений важно, чтобы слова не расходились с делом. Google использует различные механизмы признания заслуг, от общекорпоративных стандартов, таких как анализ эффективности и критерии продвижения, до взаимных поощрений между гуглерами. Штатное расписание, которое мы используем для измерения вознаграждений, таких как премии и карьерный рост, побуждает инженеров делиться знаниями. На более высоких уровнях поощряется авторитет сотрудника, который должен увеличиваться с карьерным ростом. На высших уровнях примеры лидерства включают следующее: y Растите будущих лидеров, служите наставниками для младших сотрудников, помогайте им развиваться как в техническом плане, так и в корпоративном. y Поддерживайте и развивайте сообщества разработчиков ПО в Google, выполняя обзоры кода и дизайна, организуя инженерное образование и разработку, а также давая экспертные рекомендации. Подробнее о лидерстве в главах 5 и 6. Штатное расписание — это способ управления культурой сверху. Но в Google культура также управляется снизу, например через программу вознаграждения коллег — это Распространение знаний с ростом организации 73 денежное вознаграждение и формальное признание, которыми любой гуглер может поощрить другого гуглера за его работу 1 . Например, когда Рави предлагает дать премию коллеге Джулии за то, что она является главным автором списка рассыл- ки — регулярно отвечая на вопросы, чем приносит пользу многим сотрудникам, — он публично признает ее вклад в обмен знаниями и ее авторитет за пределами команды. Поскольку вознаграждения со стороны коллег ориентированы на сотрудников, они интересуют всех. Кроме вознаграждений от коллег распространено также публичное признание вкла- да (как правило, меньшего по отдаче или усилиям, чем те, которые заслуживают вознаграждения от коллег), повышающее авторитет гуглера среди коллег. Когда гуглер дает другому гуглеру вознаграждение или похвалу, он может отправить копию наградного письма группам или отдельным лицам, способствуя увеличению известности своего коллеги. Кроме того, руководители, получая такие наградные письма, обычно рассылают их членам своей команды, чтобы те могли отметить до- стижения друг друга. Система, в которой люди могут выражать официальное признание своим коллегам, является мощным инструментом поощрения, стимулирующим сотрудников про- должать творить и удивлять коллег. Важно не вознаграждение, а признание. Создание канонических источников информации Каноническими называют централизованные, общекорпоративные источники ин- формации, которые позволяют стандартизировать и распространять экспертные зна- ния. Они лучше всего подходят для хранения информации, которая имеет отношение ко всем инженерам в организации и препятствуют образованию информационных островков. Например, руководство по организации рабочего процесса разработчика должно быть каноническим, тогда как руководство по запуску локального экземпляра Frobber в основном используют только инженеры, работающие над Frobber. Создание канонических источников информации требует больше инвестиций, чем поддержка локальной информации, такой как командная документация, но также дает более широкие преимущества. Наличие централизованного источника справоч- ных материалов в организации упрощает поиск информации, а также избавляет от проблем, связанных с ее фрагментацией, которые могут возникнуть, когда несколько групп, сталкивающихся с похожими проблемами, создают свои, часто противоречи- вые, руководства. Поскольку каноническая информация хорошо видна и обеспечивает общее на уровне организации понимание данных, важно, чтобы ее содержимое активно под- держивалось и проверялось экспертами в предметной области. Чем сложнее тема, тем важнее наличие явных владельцев канонического источника сведений о ней. 1 К числу вознаграждений от коллег относятся денежные премии и сертификаты, а также наградная запись гуглера во внутреннем инструменте gThanks. 74 Глава 3. Обмен знаниями Читатели могут заметить, что какая-то каноническая информация устарела, но обычно у них нет достаточного опыта для ее изменения, даже если инструменты позволяют это сделать. Создание и поддержка централизованных канонических источников информа- ции — дорогостоящий и трудоемкий процесс, и не все материалы можно совместно использовать на уровне организации. При оценке усилий, которые придется при- ложить для формирования этого ресурса, учитывайте особенности аудитории. Кому нужна информация? Вам? Команде? Всем участникам проекта? Всем инженерам? Руководства разработчиков В Google имеется широкий набор официальных руководств для инженеров, включая руководства по стилю ( http://google.github.io/styleguide ), официальные рекомендации по разработке ПО 1 , руководств по проверке кода 2 и тестированию 3 , а также «Советы недели» (TotW, tips of the week) 4 Объем информации чрезвычайно велик, и бессмысленно ожидать, что инженеры прочтут ее всю от начала до конца, а тем более усвоят одномоментно. Поэтому экс- перт, уже знакомый с некоторым руководством, может отправить ссылку на него коллеге-инженеру для ознакомления. Так эксперт экономит время, которое мог потратить на объяснение практики, принятой в компании, а учащийся узнает о су- ществовании канонического источника информации, к которому можно обратиться в любое время. Такой процесс масштабирует знания, поскольку позволяет экспертам определять и удовлетворять конкретные информационные потребности, используя общие ресурсы. Ссылки go/ Ссылки go/ (которые иногда называют ссылками goto/ ) — это сокращения внутренних URL в Google 5 . Большинство внутренних ссылок в Google имеют, по крайней мере, одну внутреннюю ссылку go/ . Например, « go/spanner » предоставляет информацию о Spanner, а « go/python » ссылается на руководство Google для разработчиков на Python. Сама информация может храниться в любом репозитории (g3doc, Google Drive, Google Sites и т. д.), но наличие ссылки go/ обеспечивает запоминающийся и интуитивно определяемый способ доступа к данным. Такое решение дает ряд пре- имуществ: y Ссылки go/ настолько короткие, что ими легко обмениваться в разговоре («Обяза- тельно проверь go/frobber! »). Это гораздо проще, чем искать ссылку и отправлять ее в сообщении. Удобство обмена ссылками повышает скорость распространения знаний. 1 Например, книги о разработке ПО в Google. 2 См. главу 9. 3 См. главу 11. 4 Доступны для нескольких языков. Извне доступен сборник для C++ ( https://abseil.io/tips ). 5 Ссылки go/ не имеют отношения к языку Go. Распространение знаний с ростом организации 75 y Ссылки go/ имеют постоянный характер и будут работать, даже если изменится базовый URL. Когда владелец перемещает контент в другой репозиторий (на- пример, из Google doc в g3doc), он может просто обновить целевой URL ссылки go/ . Сама ссылка go/ остается неизменной. Ссылки go/ настолько укоренились в культуре Google, что возник благоприятный замкнутый круг: ищущий информацию о Frobber сначала проверяет ссылку go/ frobber , и если она не указывает на «Руководство разработчика Frobber» (вопреки ожиданиям), то гуглер сам настраивает ссылку. В результате гуглеры часто угадывают правильную ссылку go/ с первой попытки. Лабораторные работы Лабораторные работы (codelab) Google размещены в учебных пособиях, которые объясняют инженерам новые идеи или процессы путем объединения теории, при- меров и упражнений 1 . Каноническая коллекция лабораторных работ для технологий, широко используемых в Google, доступна на go/codelab . Перед публикацией лабо- раторные работы проходят несколько этапов формального анализа и тестирования и являются интересным промежуточным звеном между статической документацией и учебными классами, однако обладают не только лучшими, но и худшими их черта- ми. Практический характер лабораторных работ делает их более привлекательными, чем традиционная документация, — инженеры могут получить к ним доступ по за- просу и выполнить самостоятельно, но они требуют дорогостоящей поддержки и не учитывают индивидуальных потребностей учащегося. Статический анализ Инструменты статического анализа — это мощный способ обмена знаниями, которые можно проверить в программе. Каждый язык программирования имеет свои особые инструменты статического анализа, но все они объясняют авторам и рецензентам кода, как можно улучшить код с помощью стиля и передовых практик. Некоторые инструменты идут дальше и предлагают автоматически применить рекомендации. Подробнее об инструментах статического анализа и их использовании в Google в главе 20. Подготовка инструментов статического анализа требует вложения сил и средств, но зато они легко масштабируются. Когда в инструмент добавляется проверка использо- вания передовых практик, каждый инженер, использующий этот инструмент, узнает об их существовании. У инженеров появляется дополнительное свободное время для изучения чего-то другого. Инструменты статического анализа расширяют знания инженеров и позволяют организациям внедрять передовой опыт последовательно. 1 Извне лабораторные работы доступны по адресу: https://codelabs.developers.google.com . (Ла- бораторные работы на русском языке, хотя и не все, можно найти по адресу: https://codelabs. developers.google.com/lang-ru/ — Примеч. пер.) 76 Глава 3. Обмен знаниями Важно оставаться в курсе событий Есть информация, которая имеет решающее значение для работы, например знание особенностей типичного рабочего процесса разработки. Другая информация, такая как обновления популярных инструментов оценки производительности, — менее критична, но все же важна. Таким образом, требования к среде обмена информацией зависят от важности распространяемых сведений. Например, пользователь ожидает, что официальная документация будет обновляться, но обычно не ждет того же от информационных бюллетеней, благодаря чему владелец может уменьшить затраты на их поддержку и обслуживание. Новостные рассылки В Google широко используются новостные рассылки для всех инженеров: EngNews (технические новости), Ownd (новости, касающиеся конфиденциальности и без- опасности) и Google Greatest Hits (отчеты о наиболее интересных ситуациях за квартал). Это хороший способ передачи информации, которая представляет интерес для инженеров, но не является критически важной. Изучив эту сторону проблемы информирования, мы обнаружили, что новости вызывают больший интерес, когда рассылаются реже и содержат исключительно полезные сведения. В противном случае они воспринимаются как спам. Большинство рассылок в Google распространяется по электронной почте, однако создатели некоторых из них проявили креатив. «Тестирование в туалете» (советы по тестированию) и «Обучение в уборной» (советы по повышению производитель- ности) — это одностраничные информационные бюллетени, размещаемые в туа- летных комнатах. Этот уникальный способ распространения новостей выделяется среди других источников информации, а все выпуски бюллетеней сохраняются в электронном архиве. Историю о том, как появился бюллетень «Тестирование в туалете», вы найдете в главе 11. Сообщества Гуглеры любят создавать сообщества, объединяющие сотрудников разных подраз- делений, для обмена знаниями по различным темам. Эти открытые каналы связи позволяют учиться у коллег, находящихся за пределами вашего круга общения, и предотвращать образование информационных островков и дублирование сведений. Особой популярностью пользуются Google Groups: в Google есть тысячи внутрен- них групп, официальных, полуофициальных и неофициальных. Некоторые из них обсуждают вопросы устранения неполадок, другие (например, Code Health) больше ориентированы на дискуссии и оказание помощи. Внутренняя служба Google+ также популярна среди гуглеров как неформальный источник информации, где специали- Удобочитаемость: наставничество через обзоры кода 77 сты описывают интересные технические неполадки или подробности о проектах, над которыми работают. Удобочитаемость: наставничество через обзоры кода Термин «удобочитаемость» имеет в Google более широкое толкование, чем просто удобочитаемость кода. Это стандартизированный общекорпоративный процесс на- ставничества, главной целью которого является распространение передовых практик программирования. Удобочитаемость охватывает широкий спектр знаний, включая языковые идиомы, структуру кода, дизайн API, использование распространенных библиотек, документацию и тестирование. Внедрение поддержки удобочитаемости начиналось с усилий одного человека. В самом начале существования Google Крейг Сильверстейн (идентификационный номер сотрудника 3) лично садился рядом с каждым новым сотрудником и проводил построчную «проверку удобочитаемости» его первого кода, отправляемого в репози- торий. Это была очень придирчивая проверка, которая охватывала все — от способов улучшения кода до следования соглашениям об использовании пробелов и отступов. Благодаря таким проверкам база кодов в Google приобрела единообразный вид, но, что особенно важно, в ходе обзора новые сотрудники учились передовым практикам, узнавали, что из общей инфраструктуры им доступно, и получали наглядное пред- ставление о том, как следует писать код в Google. Со временем поток людей, нанимаемых в Google, вырос настолько, что один человек уже не мог уделить внимание всем новичкам. Многие инженеры нашли прошлый опыт настолько ценным, что добровольно приняли участие в программе. Сегодня около 20 % инженеров Google участвуют в процессе поддержки удобочитаемости как рецензенты или авторы кода. В чем заключается процесс поддержки удобочитаемости? Код-ревью обязателен в Google. Каждый список изменений (CL, changelist) 1 требует одобрения удобочитаемости владельцем сертификата удобочитаемости. Сертифи- цированные авторы неявно подтверждают удобочитаемость своих собственных CL, а CL других авторов одобряют один или несколько квалифицированных рецензен- тов. Это требование появилось после того, как компания Google выросла до такой степени, что стало невозможно обеспечить получение каждым инженером обзоров кода, которые учили бы передовым практикам с желаемой степенью строгости. Подробнее о том, как в Google осуществляются обзоры кода и что в этом кон- тексте означает «одобрение», в главе 9. 1 Список изменений (changelist) — это список файлов в VCS, в которые вносились изменения. Список изменений является синонимом набора изменений (changeset, https://oreil.ly/9jkpg ). 78 Глава 3. Обмен знаниями Обладание сертификатом удобочитаемости в Google обычно называется «владением удобочитаемостью» для некоторого языка. Инженеры, владеющие удобочитаемостью, демонстрируют умение писать понятный, идиоматичный и легкосопровождаемый код, который иллюстрирует лучшие практики Google и лучший стиль оформления кода для данного языка. Для этого централизованная группа рецензентов удобо- читаемости проводит CL через процесс оценки удобочитаемости, после которого сообщает, насколько представленные изменения демонстрируют уровень мастерства автора. По мере того как авторы усваивают рекомендации по удобочитаемости, они получают все меньше и меньше замечаний, пока наконец сами не получат сертификат удобочитаемости. Обладателю сертификата доверяют продолжать применять свои знания в своем коде и выступать в роли рецензента кода другого инженера. Примерно 1–2 % инженеров Google являются рецензентами удобочитаемости. Все рецензенты — это добровольцы, и любой, кто получит сертификат удобочитаемости, может выдвигать себя на роль рецензента удобочитаемости. Рецензенты придержи- ваются самых высоких стандартов, потому что от них ожидается не только глубокое знание языка, но и способность обучать. Они должны воспринимать поддержку удобочитаемости прежде всего как процесс наставничества и сотрудничества, а не контроля или состязания. Рецензентам и авторам CL рекомендуется дискутировать в процессе рецензирования. Рецензенты добавляют ссылки в свои комментарии, чтобы авторы могли узнать мотивы, по которым те или иные рекомендации вошли в руководство по стилю («забор Честерсона»). Если обоснование какой-то рекомен- дации неясно, авторы должны просить разъяснений («задавать вопросы»). Поддержка удобочитаемости — это процесс, управляемый человеком, цель которого — масштабировать знания стандартизированным и в то же время персонализированным способом. Дополняя комплекс письменных и коллективных знаний, удобочитаемость сочетает в себе преимущества документации, доступ к которой можно получить с помощью ссылок, и общения с наставниками, которые знают, на какие фрагменты руководства лучше сослаться. Канонические и языковые рекомендации полностью документированы (и это хорошо!), но объем информации настолько велик 1 , что усвоить его трудно, особенно новичкам. Зачем нужен этот процесс? Код читают множество людей, особенно в масштабах Google и нашего (очень боль- шого) монолитного репозитория 2 . Любой инженер может заглянуть в код других 1 По состоянию на 2019 год одно только руководство по стилю для C++ насчитывало 40 стра- ниц. Дополнительный документ, описывающий совокупность передовых практик, во много раз длиннее. 2 Узнать, почему в Google используется монолитный репозиторий, можно здесь: https:// cacm.acm.org/magazines/2016/7/204032-why-google-stores-billions-of-lines-of-code-in-a-single- repository/fulltext . Также имейте в виду, что не весь код в Google хранится в монолитном репозитории: процесс контроля удобочитаемости, о котором мы сказали, применяется только к монолитному репозиторию, потому что это понятие согласованности внутри репозитория. |