Читабельность: храм инженерного совершенства Google

Читабельность: храм инженерного совершенства Google

Зонов Андрей

Оригинал

Если задуматься о шести годах работы в Google, то процесс удобочитаемости особенно выделяется в многообразии технологических требований

Автор был наставником по читабельности и просмотрел около 100 000 строк кода Python в Google, написанного сотнями разных авторов. При этом он один из тысяч сотрудников Google, которые коллективно помогли сотням тысяч сотрудников Google пройти процесс читабельности. Масштаб этой программы сформировал концепцию всей технологической индустрии «идиоматический Python/Java/C++/Go».

Что такое читабельность, как она влияет на гуглеров, ее культурное значение внутри Google и имеет ли смысл воссоздавать ее за стенами Google.

Читабельность в Google

В Google каждое изменение должно получить один апрув со стороны владельца участка кодовой базы. Большинство компаний так делают – здесь нет ничего странного. Однако, что уникально для Google, каждое изменение также должно быть одобрено кем-то, кто «обладает читабельностью». Удобочитаемость означает, что вы знаете все тонкости языка, шаблоны проектирования, экосистему библиотек и идиоматическое использование языка в Google, и поэтому вам доверяют выявлять любые проблемы в использовании языка. Требование читабельности удовлетворяется, если автор или любой рецензент обладает читабельностью. По моим оценкам, от трети до половины гуглеров читабельны на своем основном рабочем языке.

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

Больше о читабельности в книге SWE.

Влияние читабельности на сотрудников Google

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

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

Читабельность и я

Мой собственный путь к читабельности был трудным. Вначале я совершил ошибку, представив небольшое улучшение исследовательского кода бывшего стажера для улучшения читаемости. Назначенный рецензент разорвал весь файл на части, а не только те изменения, которые я внес! Это было неприятное и серьезное непредвиденное изменение масштаба, и из того, что я узнал позже, будучи наставником по читабельности, этот отрицательный отзыв, вероятно, отбросил меня на 5-10 отличий в прогрессе в читабельности. Честно говоря, этот ранний обзор был пустой тратой нашего времени и, вероятно, стоил Google 5000 долларов из-за потери производительности, если принять во внимание дополнительные ненужные проверки читабельности, которые мне пришлось пройти.

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

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

Я мог бы пойти по простому пути, выковыривая нюансы, которые не заметил линтер. Но для меня наставничество по читабельности означало инженерное мастерство в широком смысле. Помимо стиля и тестирования, я комментировал архитектуру кода, удобство сопровождения, использование библиотек, проектирование систем, решения о сборке или покупке и многое другое. Сам испытав неожиданный обзор расширения объема, я знал, что не должен просить автора переписать всю его кодовую базу. У меня был бюджет терпения, который мне выделяли на каждый обзор, и я старался использовать его настолько разумно, насколько мог.

Спустя несколько месяцев работы в качестве наставника по читабельности я обнаружил, что могу проверять код в 10 раз быстрее, чем когда я только начинал. За считанные минуты я мог понять цель изменения, контекст того, почему окружающая кодовая база может выглядеть именно так, а иногда даже историю карьеры автора. (Например: «Кажется, вы имеете опыт работы с Java. Этот шаблон дизайна посетителей более лаконично выражен в Python с использованием пользовательских итераторов дерева».) Я стал десятикратным инженером, по крайней мере, в этой конкретной способности просматривать код.

Роль читабельности в культуре Google

Читабельность — это лишь верхушка айсберга культуры Google. Вначале Крейг Сильверстайн, сотрудник №1 в Google, внимательно и тщательно просматривал первый дифф каждого нового сотрудника на предмет лучших практик и единообразного стиля. Я не знаю, предвидел ли Крейг, какой станет читабельность, но можно с уверенностью сказать, что он и другие первые сотрудники Google понимали мультипликативную отдачу от единообразного стиля кода, взаимозаменяемости инженеров, отличных инструментов и централизованных систем для повышения производительности программистов.

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

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

Если вы согласны с основным тезисом Google, читаемость — это всего лишь механизм масштабирования и плавильный котел, с помощью которого достигается глобальное соответствие. Я хорошо помню один обзор читабельности какого-то сложного, перегруженного AutoGraph кода TensorFlow 2, написанного инженером из случайной неисследовательской части Google. Вероятно, кроме меня, в мире было всего 10 человек, которые могли бы должным образом просмотреть этот код, и он случайно оказался в моей очереди. Я уверен, что среди наставников по читабельности есть много других экспертов в предметной области, которые распространяют свой опыт по всему Google. Единственные другие «плавильные котлы» Google, которые я могу вспомнить, — это инструменты поиска кода и LLM-инструменты для генерации кода, но в них нет того человеческого прикосновения, которое приносит читабельность.

Должна ли ваша компания внедрять читаемость?

Определяющими чертами читабельности в Google являются:

  • Консенсус по поводу планки читабельности
  • Процесс наставничества инженеров до тех пор, пока они не станут компетентными в читаемости
  • Автоматизации не дающие смержить изменения без проверки кем-то, кто компетентен в читаемости

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

Критерий (3) является наиболее сложным для реализации как технически, так и организационно. В GitHub есть функция защищенных ветвей, но в нем нет возможности добавлять такие концепции, как «читабельность Python», и я не думаю, что GitHub торопится реализовывать читабельность. В организационном отношении больше всего недовольства вызывает программное обеспечение, и я легко могу увидеть, как вице-президент подрывает читабельность, заявляя, что предстоящий запуск их продукта важнее, чем обеспечение читаемости.

Лично я не согласен с тем, что глобальная последовательность Google перевешивает локальную неэффективность. Apple и Amazon имеют репутацию компаний, у которых очень разный опыт работы в зависимости от того, где вы находитесь в компании, и это должно быть плохо. Однако это также означает, что команды могут действовать быстро, не консультируясь с остальной частью компании. Google чувствовал себя смертью от тысячи порезов; Чем больше становился Google, тем сильнее было давление на использование монолитных продуктов и процессов, которые не могли быть адаптированы ко всем возможным сценариям использования. Я неоднократно видел, как одна конкретная история разыгрывалась: «Мы никогда не запускали и не демонстрировали наш исследовательский проект, потому что нашим единственным вариантом развертывания было пройти все процессы утверждения конфиденциальности/нормативного/юридического/PR/Pubapprove и потратить несколько месяцев на выяснение стека обслуживания TensorFlow. ». В конечном счете, я считаю, что лучше разделить компанию на более мелкие и гибкие подразделения с отдельными субкультурами, адаптированными к текущим потребностям.

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

Читабельность облегченная

В летней программе по математике, которую я посещал в старшей школе, была фраза: «Докажи или опровергни, и спаси, если возможно». Опровергнув читабельность, я хотел бы спасти ее, предложив «Readability Lite», которая состоит из:


  • Консенсус по поводу планки читабельности
  • Процесс наставничества инженеров до тех пор, пока они не станут компетентными в читаемости
  • Неблокирующий механизм, стимулирующий людей к читабельности.

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

Для (1) я бы предложил, чтобы панель включала понимание модели памяти языка; понимание, если не твердое понимание языковых решений типичных задач (серверы/клиенты, сериализация/десериализация, регулярные выражения, метапрограммирование, массивы, время, ввод-вывод, ведение журнала, измерение производительности/отладка/оптимизация), понимание нюансов управления зависимостями , хорошие методы тестирования (в том числе, как спроектировать архитектуру для облегчения тестирования) и некоторое понимание того, почему технический выбор компании соответствует ее техническим требованиям/требованиям к продукту. Не все «типовые задачи» будут применимы к каждой компании; выбирайте по своему вкусу!

Для (2) вы хотели бы найти и стимулировать старших/штатных + инженеров, которые хотят наставлять других, возможно, через своего рода гражданское ожидание при оценке производительности.

Что касается (3), я думаю, что самое простое решение — сделать читабельность обязательным требованием для повышения до старшего инженера. [подсказка о том, слишком высока или слишком низка моя планка для «старших» инженеров]

Заключение

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

Report Page