Всем привет!

Разработка программного обеспечения – это сегодня само по себе дело сложное в связи с обилием всевозможных языков программирования, операционных систем, платформ, устройств и прочих факторов. Но, пожалуй, создание браузера – это одна из наиболее трудных задач, требующих особого внимания: всё-таки, браузер – это на сегодняшний день главное приложение, с которым работает ежедневно каждый пользователь Интернета. А учитывая, что контент сегодня представлен в столь сложном динамическом виде, что и не снился разработчикам первых браузеров, при этом принципы работы с этим контентом переросли из “посмотреть – почитать” в полноценную работу с приложениями, задача оказывается совсем не тривиальной. В общем, вывод напрашивается один: браузеры сегодня становятся всё сложнее и, как следствие, в процессе разработки в код проникает всё больше ошибок. Как с этим можно бороться? Как с этим боремся мы в Vivaldi? Вот об этом вкратце и поговорим.

Итак, начну с главного. Из чего состоит процесс разработки? Он состоит из нескольких важных этапов, включающих собственно написание кода, тестирование и выпуск публичной версии. Так это работает, например, если вы пишете программу уровня “Hello, world!”. Впрочем, на самом деле при разработке браузера это работает точно так же, просто на чуть более сложном уровне, включающем несколько релизов разной степени готовности и несколько “фильтров” отлова ошибок. в нашей компании процесс выглядит следующим образом.

Первый этап

На первом этапе происходит добавление разработчиками своего кода в браузер, при этом на серверах компании ежедневно идёт процесс компиляции исходников браузера в бинарные пакеты, по несколько версий в день. Это – внутренние сборки, в которых разработчики имеют возможность проверить свои свежие правки, как говорится, в деле – на живом браузере.

Также на этом этапе происходит и первичный отлов ошибок – здесь разработчики проверяют работоспособность своего кода, всё ли в нём работает так, как было задумано. Кроме того, в данных сборках присутствуют все экспериментальные функции, проходящие процесс создания и отладки – в самом сыром и непригодном к использованию виде. В связи с этим данные внутренние сборки никогда не покидают границ компании (за редким исключением, когда утечка происходит по недосмотру – как, например, это произошло буквально вчера 🙂 ).

Отдельные “счастливчики” могли понять это, обнаружив после обновления зелёную иконку браузера (см. слева) – именно она используется для внутренних тестовых сборок. Впрочем, зелёная иконка имеется и у сборки следующего этапа.

Второй этап

На этом этапе выпускается сборка для Sopranos – наших добровольных тестеров со всего мира (включая Россию), которые оказывают нам неоценимую и уникальную помощь в создании браузера. Их сборка, выпускаемая ежедневно, также имеет зелёную иконку и все экспериментальные функции, но самые явные ошибки в свежем коде разработчиков там уже отловлены. На этом этапе тестеры (а все они – отличные спецы в программировании и отладке) проверяют, как вновь добавленный код повлиял на уже существующие функции. Это очень важный этап, позволяющий выявить основную массу действительно критичных недочётов. Также можно добавить, что именно Sopranos в первую очередь проверяют и все сообщения об ошибках, ежедневно поступающие в нашу BTS от пользователей, и это уже

Третий этап

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

Еженедельные сборки для нас имеют не менее важное значение, чем и внутренние: именно здесь происходит отлов основной массы ошибок и недочётов благодаря тому, что у пользователей данных версий исключительно широкий разброс как по “железу”, так и по
личным привычкам в работе с браузером. Происходит полноценный тест-драйв браузера в реальных боевых условиях. Пользователи находят такие недочёты, которые оказались скрытыми от глаз как самих разработчиков, так и официальных тестеров Sopranos.

Главная же цель выпуска подобных тестовых публичных сборок – шлифовка и полировка кода браузера для подготовки уже стабильной версии браузера, которая выходит примерно раз в 6 недель и знаменует собой

Четвёртый этап

Итак – финальная версия. Привычная красная иконка и сравнительно стабильный, отлаженный код. Почему – “сравнительно”? Потому, что идеал недостижим и полностью избавиться от всех ошибок в коде сегодня практически нереально – слишком сложными стали сегодня программные продукты. Это как с самолётами. Мало кто знает, что абсолютно в каждом самолёте, перевозящем в данную минуту пассажиров из одной географической точки в другую, имеется журнал известных на данный момент неполадок – список недочётов, с которыми самолёт допускается к работе. Другими словами, абсолютно исправными самолёты не бывают никогда в принципе.

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

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

В качестве итога

Конечно, весь процесс описан довольно схематично и не включает множества мелких, но важных деталей, но в общем и целом показывает, как всё работает. Что же даёт такой многоуровневый подход? Он даёт равномерность процесса разработки и отладки браузера. Все ошибки фильтруются на каждом этапе в зависимости от критичности, при этом делается это постепенно, с привычной периодичностью. Таким образом разработчики имеют примерно постоянный объём ошибок в процессе исправления и в процессе ожидания очереди, тестеры (как официальные, так и неофициальные – еженедельных сборок) распределяют между собой “обязанности” по отлову ошибок в зависимости от своей квалификации, а конечные пользователи браузера получают достаточно стабильную версию, которая будет надёжно работать в ежедневном режиме. Вот, вкратце, и всё. Если у вас есть вопросы – задавайте их в комментариях, я постараюсь ответить.

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