Розробка Vivaldi: робота над помилками

image

Всім привіт!

Розробка програмного забезпечення — це сьогодні сама по собі справа складне в зв'язку з великою кількістю різноманітних мов програмування, операційних систем, платформ, пристроїв та інших факторів. Але, мабуть, створення браузера — це одна з найбільш важких завдань, що вимагають особливої уваги: все-таки, браузер — це на сьогоднішній день головне додаток, з яким працює щодня кожен користувач Інтернету. А враховуючи, що контент сьогодні представлений в настільки складному динамічному вигляді, що й не снився розробникам перших браузерів, при цьому принципи роботи з контентом переросли з «подивитися — почитати» у повноцінну роботу з додатками, завдання виявляється зовсім не тривіальною. Загалом, висновок напрошується один: браузери сьогодні стають все складніше і, як наслідок, у процесі розробки код проникає все більше помилок. Як з цим можна боротися? Як з цим боремося ми в Vivaldi? Ось про це коротко і поговоримо.

Отже, почну з головного. З чого складається процес розробки? Він складається з декількох важливих етапів, що включають власне написання коду, тестування і випуск публічної версії. Так це працює, наприклад, якщо ви пишете програму рівня «Hello, world!». Втім, насправді при розробці браузера це працює точно так само, просто на більш складному рівні, що включає кілька релізів різного ступеня готовності та кілька «фільтрів» відлову помилок. у нашій компанії процес виглядає наступним чином.

Перший етап

imageНа першому етапі відбувається додавання розробниками свого коду в браузер, при цьому на серверах компанії щодня йде процес компіляції вихідного коду браузера в бінарні пакети, за кілька версій в день. Це — внутрішні збірки, в яких розробники мають можливість перевірити свої свіжі правки, як кажуть, у справі — на живому браузері.

Також на цьому етапі відбувається і первинний вилов помилок — тут розробники перевіряють працездатність свого коду, все в ньому працює так, як було задумано. Крім того, у даних збірках присутні всі експериментальні функції, проходять процес створення і налагодження — в самому сиром і непридатному до використання вигляді. У зв'язку з цим дані внутрішні складання ніколи не залишають меж компанії (за рідкісним винятком, коли витік відбувається за недогляд — як, наприклад, це сталося буквально вчора :-) ).

Окремі «щасливчики» могли зрозуміти це, виявивши після оновлення зелену іконку браузера (див. ліворуч) — саме вона використовується для внутрішніх тестових збірок. Втім, зелена іконка є й у складання наступного етапу.

Другий етап

На цьому етапі випускається збірка для Sopranos — наших добровільних тестерів з усього світу (включаючи Росію), які надають нам неоціненну та унікальну допомогу у створенні браузера. Їх збірка, що випускається щодня, також має зелену іконку і всі експериментальні функції, але найбільш явні помилки в свіжому коді розробників там вже виловлені. На цьому етапі тестери (а всі вони — відмінні специ в програмуванні та відладці) перевіряють, як знову доданий код вплинув на вже існуючі функції. Це дуже важливий етап, що дозволяє виявити основну масу дійсно критичних недоліків. Також можна додати, що саме Sopranos в першу чергу перевіряють всі повідомлення про помилки, які щодня надходять в нашу BTS від користувачів, і це вже

Третій етап

imageЦе — наші щотижневі публічні тестові збірки, виходять з чорної (насправді — з серо-синей) іконкою (див. праворуч). Дані версії збираються для широкого тестування і в них відсутні багато експериментальні функції, які ще не готові до такого масового використання — ми просто потонемо в повідомленнях про те, що щось не працює. Ну, і елемент сюрпризу теж ніхто не відміняв.

Щотижневі збірки для нас мають не менш важливе значення, ніж внутрішні: саме тут відбувається вилов основної маси помилок і недоліків завдяки тому, що у користувачів даних версій виключно широкий розкид як по «залізу», так і з особистих звичок у роботі з браузером. Відбувається повноцінний тест-драйв браузера в реальних бойових умовах. Користувачі знаходять такі недоліки, які виявилися прихованими від очей як самих розробників, так і офіційних тестерів Sopranos.

Головна ж мета випуску подібних тестових публічних збірок — шліфування та полірування коду браузера для підготовки вже стабільної версії браузера, яка виходить приблизно раз на 6 тижнів і знаменує собою

Четвертий етап

imageОтже — фінальна версія. Звична червона іконка і порівняно стабільний, налагоджений код. Чому — «порівняно»? Тому, що ідеал недосяжний і повністю позбавитися від помилок в коді сьогодні практично нереально — надто складними стали сьогодні програмні продукти. Це як з літаками. Мало хто знає, що абсолютно в кожному літаку, що перевозить у цю хвилину пасажирів з однієї географічної точки до іншої, є журнал відомих на даний момент неполадок — список недоліків, з якими літак допускається до роботи. Іншими словами, абсолютно справними літаки не бувають ніколи в принципі.

І з браузером — аналогічна історія. Він завжди містить певну кількість недоліків, не критично впливають на роботу програми і дозволяють повноцінно використовувати цю версію в повсякденній роботі. Частина з них відома розробникам, частина — ні. І ось саме цю частину знаходять згодом користувачі вже стабільної версії — про що нас і повідомляють допомогою відправки повідомлень про помилки через відповідну онлайнову форму. Ці повідомлення потрапляють під контроль Sopranos, перевіряються, групуються і доповідаються розробникам з пропозицією виправити ось прямо зараз або трохи пізніше — в залежності від критичності помилки або недоліку.

Найчастіше знайдені на даному етапі недоліки є досить специфічними, рідкісними або малосущественными, що призводить до досить довгому терміну їх виправлення, але якщо повідомлень від користувачів багато і проблема носить явно не поодинокий характер — розробники підвищують пріоритет цієї проблеми і пересувають в черзі ближче до моменту виправлення.

В якості підсумку

Звичайно, весь процес описаний досить схематично і не включає безлічі дрібних, але важливих деталей, але загалом і в цілому показує, як все працює. Що ж дає такий багаторівневий підхід? Він дає рівномірність процесу розробки та налагодження браузера. Всі помилки фільтруються на кожному етапі в залежності від критичності, при цьому робиться це поступово, зі звичною періодичністю. Таким чином розробники мають приблизно постійний обсяг помилок у процесі виправлення і в процесі очікування черги, тестери (як офіційні, так і неофіційні — щотижневих збірок) розподіляють між собою обов'язки по вилову помилок в залежності від своєї кваліфікації, а кінцеві користувачі браузера отримують досить стабільну версію, яка буде надійно працювати у щоденному режимі. Ось, коротко, і все. Якщо у вас є питання — задавайте їх у коментарях, я постараюся відповісти.

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

p.s. Так, якщо раптом ви забули, звідки можна завантажити браузер Vivaldi — ласкаво просимо!
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.