Делай как вGoogle
 Скачать 5.77 Mb.
|
|
365 Заключение Code Search превратился из естественной замены grep в важнейший инструмент, повышающий продуктивность разработчиков и использующий технологии веб- поиска, разработанные в Google. Но что это значит для вас? Если вы работаете над небольшим проектом, который легко вписывается в вашу IDE, то Code Search вам вряд ли нужен. Если вы отвечаете за продуктивность инженеров, работающих с бо- лее крупной базой кода, то, вероятно, некоторые идеи, изложенные в этой главе, вам стоит взять на вооружение. Самая важная из этих идей состоит в том, что понимание кода является ключом к его разработке и поддержке, а это означает, что инвестиции в инструменты исследования кода принесут реальные дивиденды, которые трудно переоценить. Каждая возмож- ность Code Search ежедневно помогает разработчикам. Среди них: интеграция с Kythe (позволяет исследовать семантику кода) и поиск рабочих примеров (отличный от поиска или наблюдения за изменениями). Что касается влияния инструмента — о нем мы рассказываем сотрудникам на тренинге «Нуглер». Вы можете настроить стандартный профиль индексирования для IDE, обмен зна- ниями о grep, запуск ctags или свои нестандартных инструменты индексирования, напоминающие Code Search. В любом случае они почти наверняка будут использо- ваться, причем часто совсем не так, как вы предполагали, и ваши разработчики от этого только выиграют. Итоги y Помощь разработчикам в исследовании кода может значительно повысить их про- дуктивность. Ключевым инструментом для этого в Google является Code Search. y Инструмент поиска кода образует основу для других инструментов и играет роль стандартного инструмента, на который ссылаются вся документация и все остальные инструменты разработки. y Огромный размер кодовой базы в Google предопределил создание специального инструмента, отличного, например, от grep или индексации в IDE. y Как интерактивный инструмент, Code Search должен действовать быстро и обес- печивать бесперебойное течение процесса «вопрос-ответ». Также он должен иметь низкую задержку при выполнении всех своих функций: поиска, просмотра и индексирования. y Инструмент поиска получит широкое использование, только если ему доверяют, а доверие к нему появится, только если он проиндексирует весь код, вернет все результаты, первыми отобразив наиболее релевантные. Более ранние и менее мощные версии Code Search тоже были полезны и использовались до тех пор, пока были понятны их ограничения. ГЛАВА 18 Системы и философия сборки Автор: Эрик Куффлер Редактор: Лиза Кэри Если спросить инженеров в Google, что больше всего им нравится в компании (по- мимо бесплатной еды и первоклассного оборудования), то можно услышать удивительный ответ: им нравится система сборки 1 . В Google было потрачено много сил и времени на создание собственной системы сборки с нуля. Усилия оказались настолько успешными, что Blaze — основной компонент системы сбор- ки — несколько раз был повторно реализован экс-гуглерами в других компаниях 2 В 2015 году Google наконец открыла исходный код Blaze под названием Bazel ( https://bazel.build ). Назначение системы сборки По сути, все системы сборки предназначены для преобразования исходного кода, написанного инженерами, в выполняемые двоичные файлы, понятные машинам. Хорошая система сборки обычно обладает двумя важными свойствами: Скорость Разработчик должен иметь возможность ввести одну команду, чтобы запустить сборку и получить двоичный файл в считаные секунды. Безошибочность Каждый раз, когда разработчик запускает сборку на любом компьютере, он должен получать один и тот же результат (при условии, что исходные файлы и другие входные данные совпадают). Многие старые системы сборки пытаются найти компромисс между скоростью и безошибочностью, используя короткие пути, которые могут привести к получению несогласованных сборок. Bazel избавил разработчиков от необходимости выбирать между скоростью и безошибочностью. 1 Согласно данным внутреннего опроса, 83 % гуглеров сообщили, что довольны системой сборки, что ставит ее на четвертое место среди 19 инструментов, предложенных в опросе. Средний показатель удовлетворенности инструментом составил 69 %. 2 См. https://buck.build/ и https://www.pantsbuild.org/index.html Так ли необходимы системы сборки? 367 Системы сборки предназначены не только для людей; их также могут использовать машины, чтобы автоматически создавать сборки для тестирования кода или выпуска продукта в продакшен. Фактически большинство сборок в Google запускаются ав- томатически, а не вручную. Почти все наши инструменты разработки так или иначе связаны с системой сборки, что дает огромную выгоду всем, кто работает с нашей базой кода. Вот небольшой пример использования нашей автоматизированной системы сборки: y Код автоматически собирается, тестируется и передается в продакшен без участия человека. Разные команды проводят сборки с разной скоростью: одни еженедель- но, другие — ежедневно, а третьи — настолько быстро, насколько это возможно (глава 24). y Изменения, внесенные разработчиком, автоматически тестируются, когда он отправляет их для обзора (глава 19), благодаря чему автор изменений и рецен- зент могут сразу увидеть любые проблемы, возникшие из-за изменений на этапе сборки или тестирования. y Изменения повторно тестируются непосредственно перед включением их в глав- ную ветвь репозитория, что значительно уменьшает вероятность сохранения неработоспособных изменений. y Авторы низкоуровневых библиотек могут тестировать свои изменения во всей базе кода и гарантировать, что эти изменения безопасны для миллионов тестов и двоичных файлов. y Инженеры могут вносить крупномасштабные изменения, затрагивающие де- сятки тысяч исходных файлов (например, переименовывать общий символ), и безопасно отправлять в репозиторий и тестировать эти изменения. Подробнее о крупномасштабных изменениях в главе 22. Все это возможно только благодаря инвестициям Google в свою систему сборки. Конечно, Google уникальна с точки зрения масштаба, однако любая организация любого размера может получить аналогичные преимущества, включив в свой про- изводственный процесс современную систему сборки. В этой главе мы выясним, какие системы сборки считаются в Google «современными» и как их использовать. Так ли необходимы системы сборки? Системы сборки позволяют масштабировать разработку. Как будет показано в сле- дующем разделе, отсутствие надлежащей системы сборки порождает проблемы масштабирования. Мне достаточно компилятора! Потребность в системе сборки может быть неочевидна. В конце концов, едва ли кто- то из нас использовал систему сборки, когда учился программированию — почти 368 Глава 18. Системы и философия сборки все мы начинали с таких инструментов командной строки, как gcc или javac , или их эквивалентов в IDE. Пока весь исходный код располагается в одном каталоге, вполне можно использовать такую команду: javac *.java Она предписывает компилятору Java взять каждый файл с исходным кодом на Java в текущем каталоге и преобразовать его в двоичный файл класса. В простейшем случае этого более чем достаточно. Однако ситуация быстро усложняется с увеличением размеров проекта. Компилятор javac может найти импортируемый код в подкаталогах, находящихся в текущем каталоге, но он не умеет искать код, хранящийся в других местах файловой систе- мы (например, в библиотеке, совместно используемой несколькими проектами). Кроме того, он может преобразовывать код только на Java. Поскольку разные части больших систем часто пишутся на разных языках программирования, которые име- ют множество зависимостей между собой, ни один компилятор для единственного языка не сможет собрать всю систему. Как только приходится иметь дело с кодом на нескольких языках или с несколькими единицами компиляции, сборка кода превращается в многоэтапный процесс. В такой ситуации приходится задумываться, от чего зависит тот или иной код, и выполнять сборку частей в правильном порядке, возможно, с помощью разных инструментов для каждой части. Если изменится любая из частей, этот процесс придется повто- рить, чтобы избежать зависимости от устаревших двоичных файлов. Для кодовой базы даже среднего размера этот процесс быстро становится утомительным и под- верженным ошибкам. Компилятор также не знает, как обрабатывать внешние зависимости, например сто- ронние файлы JAR в Java. Часто лучшее, что можно сделать в отсутствие системы сборки, — загрузить зависимость из интернета, поместить ее в папку lib на жест- ком диске и настроить компилятор для чтения библиотек из этой папки. Однако со временем легко забыть, какие библиотеки туда помещены, откуда они взялись и используются ли они до сих пор. И останется надеяться только на удачу при их обновлении по мере выхода новых версий. Сценарии командной оболочки спасут ситуацию? Предположим, что ваш любительский проект изначально достаточно прост, чтобы собрать его с помощью компилятора, но постепенно в нем появляются вышеопи- санные проблемы. Возможно, вы все еще думаете, что вам не нужна настоящая система сборки и достаточно автоматизировать наиболее утомительные этапы сборки, написав несколько простых сценариев командной оболочки, которые позаботятся о сборке компонентов в правильном порядке. Это принесет облегче- ние на какой-то период, но довольно скоро вы начнете сталкиваться с еще более сложными проблемами: Так ли необходимы системы сборки? 369 y Поддержка сборки становится все более утомительной. По мере усложнения системы работа со сценариями начинает отнимать столько же времени, сколько работа с фактическим кодом. Отладка сценариев командной оболочки — трудная задача, все больше и больше нестандартных случаев начинают наслаиваться друг на друга. y Сборка происходит медленно. Чтобы гарантировать актуальность всех зависи- мостей, вы запускаете сценарий, который собирает их по порядку при каждом запуске. Вы задумываетесь о добавлении логики для определения частей, кото- рые действительно необходимо собрать повторно, но эта задача кажется ужасно сложной. Или, может быть, вы думаете о том, чтобы каждый раз указывать, какие части следует пересобрать, но это опять приводит вас в исходную точку. y Хорошая новость: пора выпускать новую версию! Вы вспоминаете, какие аргу- менты нужно передать команде jar , чтобы выполнить окончательную сборку ( https://xkcd.com/1168 ), как выгрузить результат и отправить в центральный репозиторий, как создать и разместить обновления в документации, как от- править пользователям уведомления. Хм-м, пожалуй, для этого нужно написать еще один сценарий... y Катастрофа! Ваш жесткий диск выходит из строя, и теперь вам нужно воссоздать всю систему. Вы были достаточно предусмотрительны и хранили все файлы с ис- ходным кодом в VCS, но как быть с библиотеками, загруженными из интернета? Сможете ли вы найти их снова и гарантировать соответствие версий? Ваши сценарии, вероятно, зависели от определенных инструментов, установленных в определенных местах, — сможете ли вы воссоздать идентичную среду, чтобы сценарии работали как раньше? А как быть с переменными окружения, которые вы настроили давным-давно, чтобы добиться правильной работы компилятора, а потом забыли о них? y Несмотря ни на что, ваш проект достаточно успешен, и вы можете нанять еще нескольких инженеров. Теперь вы понимаете, что предыдущие проблемы еще не были катастрофой — теперь вам нужно снова и снова проходить один и тот же болезненный процесс настройки окружения для каждого нового разработчика. И несмотря на прилагаемые усилия, все системы разработчиков будут немного от- личаться друг от друга. Часто то, что работает на одном компьютере, не работает на другом, и каждый раз требуется несколько часов, чтобы правильно настроить пути к инструментам или проверить версии библиотек, чтобы выяснить, в чем разница. y Вы решаете автоматизировать систему сборки. Теоретически для этого достаточно поставить новый компьютер и настроить на нем запуск сценария сборки по ночам с помощью cron . Вам по-прежнему нужно пройти болезненный процесс настройки, но теперь у вас нет преимуществ человеческого мозга, способного обнаруживать и решать мелкие проблемы. Теперь, входя по утрам в систему, вы видите, что ночная сборка потерпела неудачу, потому что вчера разработчик внес изменение, которое работало в его системе, но не работает в системе автоматической сборки. 370 Глава 18. Системы и философия сборки Каждая такая проблема легко исправляется, но делать это приходится так часто, что каждый день вы тратите массу времени на поиск и применение простых ис- правлений. y По мере развития проекта сборки выполняются все медленнее и медленнее. Однажды, ожидая завершения сборки, вы с грустью смотрите на пустующий рабочий стол коллеги, который находится в отпуске, и задумываетесь о возмож- ности задействовать простаивающие вычислительные мощности. Это проблема масштабирования. Для одного разработчика, работающего над парой сотен строк кода в течение одной-двух недель (типичный опыт младшего разработ- чика, только что окончившего университет), компилятора более чем достаточно. Сценарии помогут вам продвинуться немного дальше. Но как только вам потребу- ется координировать действия нескольких разработчиков и работу их компьютеров, даже идеального сценария сборки будет недостаточно, потому что очень трудно учесть незначительные различия между системами. На этом этапе нужно начинать инвестировать в систему сборки. Современные системы сборки К счастью, все описанные проблемы уже решены существующими универсальными системами сборки. По сути, они не сильно отличаются от вышеупомянутого подхода «сделай сам» на основе сценариев: они запускают те же самые компиляторы и тре- буют знания особенностей базовых инструментов. Но эти системы разрабатывались много лет, что сделало их гораздо более надежными и гибкими, чем сценарии, которые вы можете написать сами. Все дело в зависимостях Рассматривая проблемы, описанные выше, мы снова и снова наблюдали одну и ту же закономерность: намного легче управлять своим кодом, чем его зависимостями (глава 21). Зависимости могут быть самыми разнообразными: от задачи (напри- мер, «отправить документацию, прежде чем отметить выпуск завершенным») или от артефакта (например, «для сборки кода нужна последняя версия библиотеки компьютерного зрения»). Иногда ваш код может иметь внутренние зависимости от других частей кодовой базы или внешние зависимости от кода или данных, при- надлежащих другим командам (в вашей или сторонней организации). Но в любом случае идея «мне нужно это, чтобы получить то» постоянно повторяется в системах сборки, и управление зависимостями, возможно, является их самой фундаменталь- ной задачей. Системы сборки на основе задач Сценарии командной оболочки из предыдущего раздела были примером прими- тивной системы сборки на основе задач. Главной единицей работы такой системы Современные системы сборки 371 является задача. Каждая задача — это своего рода сценарий, который может вы- полнять любую логику и зависеть от других (заранее выполненных) задач. Боль- шинство современных систем сборки, таких как Ant, Maven, Gradle, Grunt и Rake, основаны на задачах. Большинство современных систем сборки требуют, чтобы вместо сценариев команд- ной оболочки инженеры создавали файлы сборки, описывающие порядок сборки. Вот пример из руководства Ant ( https://oreil.ly/WL9ry ): простой файл сборки 372 Глава 18. Системы и философия сборки Файл сборки написан на XML и определяет простые метаданные о сборке и зада- чи (теги в XML 1 ). Каждая задача выполняет список команд, поддерживаемых системой Ant, включая создание и удаление каталогов, запуск javac и создание файла JAR. Набор команд можно расширить с помощью подключаемых модулей (плагинов), чтобы охватить любую логику. Каждая задача может также определять задачи, от которых она зависит, перечислив их в атрибуте depends . Эти зависимости образуют ациклический граф (рис. 18.1). dist compile clean init Рис. 18.1. Ациклический граф зависимостей Пользователи выполняют сборку, вызывая инструмент командной строки Ant и пере- давая ему задачи в аргументах. Например, когда пользователь запускает команду ant dist , система сборки Ant выполняет следующие шаги: 1. Загружает файл build.xml в текущий каталог и анализирует его, чтобы создать граф (рис. 18.1). 2. Отыскивает задачу с именем dist , указанную в командной строке, и обнаружи- вает, что она зависит от задачи с именем compile 3. Отыскивает задачу compile и обнаруживает, что она зависит от задачи init 4. Отыскивает задачу init и обнаруживает, что она не имеет зависимостей. 5. Выполняет команды, перечисленные в задаче init 6. Выполняет команды, перечисленные в задаче compile , после выполнения всех зависимостей этой задачи. 7. Выполняет команды, перечисленные в задаче dist , после выполнения всех за- висимостей этой задачи. В итоге код, выполняемый системой Ant при запуске задачи dist , эквивалентен следующему сценарию командной оболочки: ./createTimestamp.sh mkdir build/ javac src/* -d build/ mkdir -p dist/lib/ jar cf dist/lib/MyProject-$(date --iso-8601).jar build/* Если убрать синтаксис, то файл сборки мало чем отличается от сценария сборки. Тем не менее мы уже многого добились. Теперь мы можем создавать новые файлы 1 В терминологии Ant задачи называются «целями» (target), а команды — «задачами» (task). |