Делай как вGoogle
 Скачать 5.77 Mb.
|
|
Будущее управления версиями Компания Google — не единственная организация, публично обсуждающая пре- имущества подхода на основе монолитного репозитория. Microsoft, Facebook, Netflix и Uber тоже публично заявили, что используют этот подход. Ассоциация DORA много писала об этом. Маловероятно, что эти успешные компании заблуждаются или их опыт неприменим к организациям меньшего размера. Большинство аргументов против монолитных репозиториев сводятся к техниче- ским ограничениям, связанным с организацией единственного репозитория. Если клонирование репозитория происходит быстро и не требует больших затрат, разра- ботчики с большей вероятностью будут придерживаться небольших и изолирован- ных изменений (и избегать ошибок, связанных с фиксацией в неправильной ветви для разработки). Если клонирование репозитория (или выполнение любой другой стандартной операции VCS) потребует от разработчика впустую тратить свое время, то легко понять, что организация будет избегать использования такого большого репозитория. К счастью, мы смогли не попасть в эту ловушку, уделив должное вни- мание созданию масштабируемой VCS. Если посмотреть на серьезные улучшения Git за последние несколько лет, то ста- новится очевидным, как много работы было сделано для поддержки крупных репо- зиториев: поверхностное клонирование, разреженные ветви, оптимизация и многое другое. Мы полагаем, что этот процесс продолжится и стремление к «небольшому хранилищу» уменьшится. Другой важный аргумент против монолитных репозиториев: они не соответствуют процессу разработки ПО с открытым исходным кодом. Да, это правда, но многие практики в мире открытого исходного кода обусловлены приоритетом свободы, от- 1 Или у вас есть желание и возможность настроить и поддерживать VCS на протяжении всего срока службы кодовой базы или организации. В противном случае — лучше избегать такого варианта, потому что он влечет много накладных расходов. Будущее управления версиями 343 сутствием координации и нехваткой вычислительных ресурсов. Раздельные проекты в мире открытого исходного кода фактически являются отдельными организациями, которые могут видеть код друг друга, управлять объемом вычислительных ресурсов, координировать работу и централизовать управление. Менее распространенная, но, пожалуй, более обоснованная проблема, связанная с использованием монолитного репозитория, заключается в том, что с ростом ор- ганизации уменьшается вероятность соответствия каждого фрагмента кода одним и тем же юридическим и нормативным требованиям, а также требованиям к секрет- ности и конфиденциальности. Одним из естественных преимуществ разрозненных репозиториев является возможность иметь разные группы авторизованных разра- ботчиков, правила видимости, разрешения и т. д. Вшить все то же самое в монолит- ный репозиторий можно, но это потребует дополнительных расходов на настройку и обслуживание. В то же время отрасль, похоже, снова и снова изобретает средства связи между репозиториями. Иногда они помещаются в VCS (как, например, подмодули в Git) или в систему сборки. Если набор репозиториев поддерживает согласованное пред- ставление о том, «что такое главная ветвь» и «какое изменение произошло первым», и имеет механизмы описания зависимостей, то можно легко представить объедине- ние разрозненной коллекции физических репозиториев в один общий виртуальный монолитный репозиторий. Несмотря на то что система Piper очень хорошо зареко- мендовала себя, инвестиции в масштабируемый виртуальный монолитный репози- торий и инструменты для управления им, а также использование готовых настроек и политик для каждого репозитория могли бы оказаться более выгодным вложением. Мы уверены, что как только кто-то в сообществе открытого исходного кода создаст достаточно большую группу совместимых и взаимозависимых проектов и опубликует их представление в виртуальном монолитном репозитории, практика разработки с открытым исходным кодом начнет меняться. Мы видим такую тенденцию в ин- струментах, способных синтезировать виртуальные монолитные репозитории, а также в работе, проделанной (например) крупными разработчиками дистрибутивов Linux, публикующими взаимно совместимые версии тысяч пакетов. Благодаря юнит-тестам, непрерывной интеграции и автоматическому подбору версий для новых исправлений владельцы могут обновлять главную ветвь своего пакета (конечно, без нарушения правил), и мы думаем, что эта модель завоюет популярность в мире открытого ПО. В конце концов, это просто вопрос эффективности: подход на основе (виртуального) монолитного репозитория с правилом единственной версии сокращает сложность разработки ПО на целое (сложное) измерение — время. Мы ожидаем, что в ближайшие 10–20 лет управление версиями и зависимостями будет развиваться в следующем направлении: VCS сосредоточатся на поддержке более крупных репозиториев с улучшенным масштабированием производитель- ности, но при этом избавят от необходимости использовать большие репозитории, предложив более совершенные механизмы объединения данных в границах проектов и организаций. Кто-то, возможно, группа управления пакетами или разработчик дис- 344 Глава 16. Управление версиями и ветвями трибутивов Linux, станет автором создания стандартного виртуального монолитного репозитория. С помощью утилит этот монолитный репозиторий обеспечит легкий доступ к совместимому набору зависимостей как к одному целому. В целом мы по- нимаем, что номера версий — это временные метки и что разрешение асимметрии версий добавляет сложность дополнительного измерения (времени), что требует больших затрат, которых мы можем научиться избегать. Но переход начнется с со- здания чего-то логически похожего на монолитный репозиторий. Заключение VCS являются врожденным компонентом совместной работы, основанной на общих вычислительных ресурсах и компьютерных сетях. Они развивались в соответствии с понятными нам нормами программной инженерии. Ранние VCS использовали упрощенные механизмы блокировки на уровне файлов. Но по мере роста типичных проектов и команд, занимающихся программной инжене- рией, проблемы масштабирования этого подхода становились все более очевидными, и наше понимание управления версиями изменилось. С развитием модели разра- ботки открытого ПО со множеством распределенных участников VCS стали более децентрализованными. Мы ожидаем сдвига в технологии VCS, которая предполагает постоянную доступность сети и уделяет больше внимания хранению данных и со- зданию облака, чтобы избежать передачи ненужных файлов и артефактов. Этот сдвиг становится все более важным для крупных, долгоживущих проектов программной инженерии, даже при том что он означает изменение подхода, использовавшегося в простых проектах с одним разработчиком и с одной машиной. Сдвиг в сторону облач- ных технологий конкретизирует подход DVCS: даже если разрешена распределенная разработка, все равно требуется использовать централизованный источник истины. Текущая децентрализация в DVCS — это естественная реакция технологии на потреб- ности отрасли (особенно сообщества открытого ПО). Однако конфигурация DVCS должна строго контролироваться и сочетаться с политиками управления ветвями, принятыми в организации. Часто это может приводить к неожиданным проблемам с масштабированием: для безупречной работы в автономном режиме требуется го- раздо больше локальных данных. Неспособность обуздать потенциальную сложность свободного ветвления может привести к неограниченному росту накладных расходов на разработку и развертывание кода. Однако сложные технологии необязательно должны использоваться комплексно: как мы видели, простота политики ветвления в моделях разработки на основе монолитного репозитория и главной ветви обычно способствует плодотворной работе. Излишняя свобода выбора ведет к издержкам. Мы поддерживаем представленное здесь правило единственной версии: разработчики в организации не должны иметь выбора, куда выполнять фиксации или от какой версии существующего компонента зависеть. Мы знаем лишь несколько допустимых политик, дающих выбор: они могут раздражать отдельных разработчиков, но улучшают конечный результат. Итоги 345 Итоги y Используйте управление версиями для любых проектов разработки ПО, раз- мер которых превышает размер «игрушечного проекта с одним разработчиком, который никогда не будет обновляться». y Возможность выбора «от какой версии зависеть» всегда порождает проблемы масштабирования. y Правило единственной версии на удивление важно для эффективности органи- зации. Устранение возможности выбора, куда производить фиксации или от чего зависеть, значительно упрощает работу. y Некоторые языки программирования поддерживают затенение, раздельную компиляцию, сокрытие компоновщика и т. д. Но эти приемы не помогают создать что-то полезное и формируют технический долг. y Исследования («State of DevOps», «Ускоряйся!») показали, что существует тесная взаимосвязь между разработкой в главной ветви и эффективностью софтверных организаций. Долгоживущие ветви разработки — не лучшая идея по умолчанию. y Используйте любую VCS, подходящую для ваших нужд. Чтобы хранить отдельные проекты в отдельных репозиториях, разумно организовать зависимости между репозиториями так, чтобы они ссылались на «главную ветвь». С каждым годом появляется все больше VCS и систем сборки, которые позволяют иметь как не- большие, разрозненные репозитории, так и единую «виртуальную» главную ветвь для всей организации. ГЛАВА 17 Code Search Авторы: Александр Нойбек и Бен Сент-Джон Редактор: Лиза Кэри Code Search — это инструмент для просмотра и поиска кода в Google, который со- стоит из пользовательского интерфейса и множества серверных компонентов. Его появление, как и многих других инструментов разработки в Google, было обусловлено масштабом кодовой базы. Первоначально Code Search создавался как комбинация внутренних инструментов типа grep 1 с ранжированием и внешнего пользовательского интерфейса Code Search 2 . Его место как ключевого инструмента для разработчиков Google было закреплено благодаря его интеграции со службами Kythe и Grok 3 , добав- ляющими перекрестные ссылки и возможность перехода к определениям символов. Эта интеграция сместила фокус с поиска кода на просмотр кода, и при создании более поздней версии Code Search разработчики отчасти руководствовались принципом: «Позволить получить ответ на вопрос о коде одним щелчком мыши». Теперь ответы на такие вопросы, как: «Где определяется этот символ?», «Где он используется?», «Как его подключить?», «Когда он был добавлен в кодовую базу?» и даже: «Сколько тактов процессора он потребляет?», можно получить одним или двумя щелчками мыши. В отличие от IDE или редакторов кода, Code Search оптимизирован для чтения и изучении больших объемов кода. По этой причине он во многом полагается на об- лачные компоненты, осуществляющие поиск и разрешающие перекрестные ссылки. В этой главе мы подробно расскажем об инструменте Code Search: как гуглеры ис- пользуют его, почему мы решили создать отдельный веб-инструмент для поиска кода и как он решает проблемы, связанные с поиском и просмотром кода в масштабе репозитория Google. 1 Изначально GSearch работал на ПК Джеффа Дина, который однажды взбесил всю компанию, уйдя в отпуск и выключив свой компьютер! 2 Закрыт в 2013 году. См. https://en.wikipedia.org/wiki/Google_Code_Search (https://oreil.ly/xOk-e ). Описание на русском языке доступно по адресу: https://ru.wikipedia.org/wiki/Google_Code_ Search . — Примеч. пер. 3 Эта служба, ныне известная как Kythe ( http://kythe.io ), предоставляет перекрестные ссыл- ки (кроме всего прочего): сообщает точки использования определенного символа, например имени функции, с полной информацией о сборке, чтобы дать возможность отличить его от других похожих символов. Пользовательский интерфейс Code Search 347 Пользовательский интерфейс Code Search Центральным элементом пользовательского интерфейса Code Search (рис. 17.1) является поле поиска. Так же как поле поиска в веб-интерфейсе поисковой системы Google, оно предлагает «подсказки», которые разработчики могут использовать для быстрого перехода к файлам, символам или каталогам. В ответ на сложные запросы поле поиска возвращает страницу результатов с фрагментами кода. Сам поиск можно рассматривать как мгновенный «поиск в файлах» (действующий подобно команде grep в Unix) с ранжированием по релевантности и некоторыми особенностями, ха- рактерными для программного кода, такими как правильная подсветка синтаксиса, оценка области видимости и выделение комментариев и строковых литералов. Code Search также имеет интерфейс командной строки и может использоваться другими инструментами через API RPC. Его используют при постобработке или, если набор результатов слишком велик, для проверки вручную. Рис. 17.1. Пользовательский интерфейс Code Search При просмотре одного файла на большинстве символов можно щелкнуть и быстро получить информацию об этом символе. Например, щелчок на имени функции перенесет вас к ее определению, щелчок на имени импортируемого файла — к фак- тическому файлу с исходным кодом, а щелчок на идентификаторе ошибки в коммен- тарии — к соответствующему отчету об ошибке. Эта возможность обеспечивается инструментами индексирования на основе компилятора, такими как Kythe ( http:// kythe.io ). Если щелкнуть на имени символа в точке его определения, откроется панель, в которой перечислены все места, где он используется. Точно так же при наведении указателя мыши на локальные переменные внутри функции будут подсвечены все появления этой переменной в реализации. 348 Глава 17. Code Search Благодаря интеграции с Piper (главу 16) Code Search может также отображать историю файла. То есть с его помощью можно увидеть более старые версии файла, изменения и их авторов и переходить к ним в Critique (глава 19), сравнивать версии файлов, просматривать историю фиксаций изменений и даже видеть удаленные файлы. Как гуглеры используют Code Search? Аналогичные функции доступны и в других инструментах, однако гуглеры по- прежнему активно используют интерфейс Code Search для поиска и просмотра файлов и для изучения кода 1 . Если инженер хочет найти ответы на вопросы о коде, то достичь этой цели легче всего с Code Search 2 Где? Около 16 % запросов Code Search связаны с поиском, где в кодовой базе находится конкретная информация, например определение функции, конфигурация, вызовы API или файл в репозитории. На вопрос «где?» можно ответить с помощью поисковых запросов или семантических ссылок, таких как «перейти к определению символа». Такие вопросы часто возникают при решении крупных задач, таких как рефакторинг или сбор мусора, или при обсуждении проектов с другими инженерами. Code Search предоставляет два вида помощи при таком поиске: ранжирование ре- зультатов и расширенный язык запросов. Ранжирование учитывает общие случаи, а язык запросов помогает конкретизировать поиск (например, ограничивать доступ в коде, исключать языки, рассматривать только функции), чтобы находить редкие случаи. Пользовательский интерфейс Code Search позволяет с легкостью делиться резуль- татами поиска с коллегами. Так, при выполнении обзора кода можно включить ссылку, такую как: «Рассматривали ли вы возможность использования этого специа- лизированного хеш-массива: cool_hash.h ?» Такие ссылки также можно использовать в документации, в отчетах об ошибках и в результатах вскрытия, и они считаются в Google каноническим способом ссылки на код. Ссылаться можно даже на старые версии кода, поэтому ссылки остаются действительными с течением времени и по мере развития кодовой базы. 1 Наличие вездесущего браузера кода оказывает благотворное влияние: инженеры стремятся писать код, который легко просматривать. Они используют не слишком глубокие иерархии, которые не требуют множества щелчков мышью для перехода от точки вызова к фактической реализации, и выбирают именованные типы вместо более обобщенных сущностей, таких как строки или целые числа, потому что это облегчает поиск их применений. 2 Sadowski C., Stolee K. T., Elbaum S. How Developers Search for Code: A Case Study. In Proceedings of the 2015 10th Joint Meeting on Foundations of Software Engineering (ESEC/FSE 2015). https:// doi.org/10.1145/2786805.2786855 Как гуглеры используют Code Search? 349 Что? Примерно четверть всех случаев использования Code Search — это просмотр фай- лов и поиск ответа на вопрос: «Что делает та или иная часть кодовой базы?» Такое применение в большей степени относится к исследованиям — чтению и изучению исходного кода перед внесением своих изменений или для оценки чужих. Чтобы упростить такие исследования, в Code Search поддерживается возможность быстрой навигации через иерархию вызовов и между связанными файлами (напри- мер, между заголовочными файлами и файлами реализации, тестирования и сборки). Code Search должен ответить на множество вопросов, возникающих у разработчиков в процессе просмотра файлов. Как? Примерно треть всех случаев использования Code Search — это изучение примеров решения похожих задач. К этому моменту разработчик, как правило, уже нашел нужный ему API (например, для чтения файла из удаленного хранилища) и хочет увидеть, как его использовать в конкретной ситуации (например, как настроить удаленное соединение и обработать определенные типы ошибок). Code Search также часто используется с целью поиска библиотек для конкретных задач (например, для эффективного вычисления идентификационных меток целочисленных значений) и последующего выбора наиболее подходящей реализации. Для такого рода при- менения типично сочетание поиска и просмотра перекрестных ссылок. Почему? Вместе с выяснением, что делает код, многие пытаются выяснить, почему код ведет себя не так, как ожидалось. Около 16 % случаев использования Code Search связаны с попытками найти ответ на вопрос: «Почему был добавлен тот или иной фрагмент кода?» или «Почему фрагмент ведет себя определенным образом?» Вопрос, который часто возникает при отладке: «Почему в этих обстоятельствах возникает ошибка?» Важной здесь является возможность определения и изучения точного состояния кодовой базы в указанный момент. При отладке проблемы в продакшене нередко приходится исследовать кодовую базу в состоянии, в котором она находилась не- сколько недель или месяцев назад, а при поиске причин сбоев в тестах для нового кода обычно изучаются изменения, давность которых составляет всего несколько минут. Code Search поддерживает оба варианта исследований. |