Abr@X@bra.ru
Как Google создает веб-фреймворки

Как Google создает веб-фреймворки

18.05.2017
21
Общеизвестно, что Google использует единый репозиторий для совместного использования кода - всего 2 миллиарда строк.



Над структурой кода Google работают более 25 000 разработчиков программного обеспечения. Работа над Google идет из десятков офисов в разных странах мира. В обычный рабочий день они вносят 16 000 строк кода по изменению или дополнению кода.

В этой статье рассказывается о специфике построения веб-фреймворка с открытым исходным кодом – Angular.

Только одна версия

Репозиторий просто огромен, у вас есть только одна версия всего. Это очевидно. Тем не менее, это хорошо, потому что это означает, что в Google у вас не может быть приложения FooBar, которое использует Angular 2.2.1 и другое приложение BarFoo, которое находится на 2.3.0. Оба приложения должны быть в одной версии - последней.



Вот почему Гуглеры иногда говорят, что все программное обеспечение в Google живет на грани кровопролития.

Если ваша душа кричит «опасно», прямо сейчас, это понятно. Но впереди сюжетный поворот.

74 тыс. Тестов на коммит

Angular делает проверку на 1601 тест. Когда изменяется код в Angular репозитории Google, автоматом запускаются тесты, которые зависят от структуры. На данный момент это около 74 тысяч тестов (в зависимости от того, насколько велики изменения).

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

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

Ломаешь код, исправь его

Когда разработчики Angular хотят внести изменения, они должны пойти и исправить это для своих пользователей. Поскольку все в Google живет в одном репо, и они могут сразу начать исправление.

Любое изменение в Angular также включает все исправления для этого изменения во всех приложениях Google, которые зависят от него. Таким образом, поломка и исправление кода входят в репо одновременно и, конечно же, после надлежащего анализа кода всеми затронутыми сторонами.

Приведем конкретный пример. Когда кто-то из команды Angular вносит изменения в код приложения AdWords, он переходит к исходному коду этого приложения и исправляет его. Они могут использовать существующие тесты AdWords в процессе, и они могут добавлять новые. Затем они помещают все это в свой список изменений и просят о пересмотре. Поскольку их список изменений касается кода как в репо Angular, так и в репо AdWords, системе автоматически требует подтверждение кода для обеих этих команд. Только после этого можно представить изменения.

Это имеет очевидный эффект. Разработчики фреймворка Angular имеют доступ к миллионам строк кода, которые создаются на их платформе, и они регулярно затрагивают этот код сами. Им не нужно предполагать, как используется их структура. (Очевидное предупреждение состоит в том, что они видят только код Google, а не код всех Workivas, Wrikes и StableKernels в мире, которые также используют Angular.)

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

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

Крупномасштабные изменения

Что, если в Angular необходимо внести существенные изменения (скажем, переход от 2.x к 3.0), и это изменение нарушает 74 тысячи тестов? Пойдет ли команда и исправит все? Будут ли они вносить изменения в тысячи исходных файлов, большинство из которых они не авторизовали?

Ответ – да.

Многие изменения вносятся полностью автоматическими, без необходимости подтверждения от разработчика.

Когда метод класса Foo изменяется с bar () на baz (), создается инструмент (измерения), который проходит через единый репозиторий Google, находит все экземпляры этого класса Foo и его подклассы и меняет все упоминания о bar ( ) на baz ().



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

Показатели эффективности

У Angular отличные показатели по тестам. Google очень строг к измерению производительности своих приложений.

Поэтому, когда команда Angular вносит изменения, которые делают загрузку AdWords на 1% медленнее, они знают, что делают. Когда команда Angular заявила, что приложения стало на 40% меньше и на 10% быстрее, они не говорили о каких-то синтетических крошечных примерах TodoMVC. Они говорили о реальных, критически важных, производственных приложениях с миллионами пользователей и мегабайтами кода бизнес-логики.

Что все это значит?

Явная цель Angular - быть лучшими в классе по производительности и надежности для создания больших веб-приложений. Эта статья надежно охватывает последнюю часть - надежность - и почему важно, чтобы критически важные приложения Google, такие как AdWords и AdSense, использовали инфраструктуру. Это не просто команда, хвастающаяся своими пользователями - как объяснялось выше, наличие больших внутренних пользователей делает Angular менее вероятным, чтобы ввести поверхностные изменения. Это делает основу более надежной.



Сделай свой бизнес лучше

Сайты на 1С-Битрикс

Сделать заказ
Angular
Читайте также:
Я все еще люблю jQuery - и вы тоже

Я все еще люблю jQuery - и вы тоже

В последнее время в JQuery широко используется стигма. Похоже, что все настойчиво избегают этого в современной разработк...
Читать
Перенос сайта на 1С-Битрикс

Перенос сайта на 1С-Битрикс

На рынке очень много систем управления сайтом. У всех есть свои плюсы и минусы, но есть общие недостатки на который...
Читать
Протокол HTTPS или защита в интернете

Протокол HTTPS или защита в интернете

Путешествуя по интернету, кликая по ссылкам, запуская просмотр видеороликов, отправляя сообщение другу и или коллеге по ...
Читать