Як зіскочити з Android Studio та опанувати VS Code розробнику на Flutter

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті.

Розробкою мобільних застосунків я займаюсь вже майже 5 років. Увесь цей час для роботи використовував Android Studio (AS надалі). На Flutter я програмую близько 3 років і не так давно почав помічати, що «Студія» зі зручного інструменту стала перетворюватись на перевантажений комбайн.

І все б нічого, але абсолютна більшість інструментів направлена на покращення користувацького досвіду саме нативного розробника. Для Flutter-девелопера це скоріш вантаж, який якщо і потрібен, то настільки нечасто, що ним можна знехтувати. Тому я спробував VSCode і хочу поділитись з вами своїм досвідом. Можливо, я замотивую когось перейти з AS з іншої IDE, а можливо, продемонструю, що перехід того не вартий.

Тож, кому буде цікавою ця стаття:

• Flutter-розробникам, які працюють на Android Studio, проте відчувають, що їм щось в ній не подобається.
• Flutter-розробникам, які вже працюють з VS Code. Можливо, ви знайдете щось цікаве і корисне.
• Будь-яким розробникам, які хотіли б дізнатись щось нове про VS Code.

Хоч ця стаття і планувалась як порівняння AS з VSCode, проте інформації буде більше саме про VSCode і про те, як там усе працює.

Ще одна важлива деталь перед тим, як почати. Я буду розповідати саме про реалізацію якоїсь функції в VSCode та/або порівняння її реалізації з Android Studio. Якщо ви не знайомі взагалі з якоюсь функцією (наприклад, що за команда git blame, нащо вона потрібна і як використовується без прив’язки до IDE), я не буду її тут розписувати. Це виходить за рамки статті й значно збільшить її об’єм.

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

Keymap & Shortcuts

Я з тих людей, які намагаються не перенести користувацький досвід з однієї системи на іншу, а зрозуміти, чого розробник екосистеми хотів домогтися. Тому я не почав відразу змінювати всі шорткати на студійні, а спробував власноруч оцінити зручність запропонованого рішення.

Наведу приклад моїх типових повсякденних шорткатів VSCode та їхні аналоги в студії:

А проте, деякі комбінації я змінив та доповнив. Просто не зміг звикнути до стандартних.

Command Palette

Command Palette — це також дуже зручний інструмент, який приблизно можна охарактеризувати як суміш finder та терміналу. Цей інструмент дозволяє:

• шукати файл;
• шукати глобально і в межах цього файлу код за назвою класу, змінної, поля тощо;
• керувати вашими плагінами (це найголовніше, бо робити ви це будете регулярно).

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

Звичайна Палітра

Для початку потрібно запам’ятати комбінацію cmd + P. Ця комбінація відкриває Command Palette (буду інколи називати просто «палітра») в режимі, який дозволяє шукати файли за назвою чи за шляхом до них або викликати допоміжні команди з меню. Наприклад, якщо ввести слово debug і поставити пробіл, то ви побачите перелік конфігурацій для запуску застосунку в відлагоджувальному режимі. Якщо ввести view — ви відповідно побачите перелік усіх меню які зараз можна показати.

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

Палітра для роботи з командами «>»

Другою (а можливо, і першою) за частотою використання у вас буде палітра, що дозволяє шукати та виконувати команди всіх плагінів і підменю VSCode. Для відкриття цієї палітри використовуйте комбінацію cmd + shift + P.

Відкриється вже знайомий нам Command Palette з символом >. Ви можете почати відразу вводити назву команди чи почати з назви плагіна, потім почати вводити команду. Можете пропускати символи (як я зазначав раніше) чи ігнорувати пробіли. Пошук доволі гнучкий (не тільки в цій палітрі, а всюди), тож проблем з пошуком відповідних речей у вас не повинно виникати.

Пошук за символами у відкритому файлі «@»

cmd + shift + O. Відкриється Command Palette, але вже з проставленим символом @. Це дозволить шукати символи в межах відкритого файлу. Під «символами» мається на увазі пошук за назвою класів, методів, полів.

Пошук за символами по всьому проєкту «#»

Те саме, що і в попередньому абзаці, але по всьому проєкту, включно з залежностями. Cmd + shift + T.

Перейти до рядка «:»

Мабуть, вже здогадались :) Можна перейти до рядка в файлі та до потрібного символа в рядку.

Source Control

Дозволяє отримати інформацію про всі зміни (changes), які зараз є в коді. На відміну від студії, де відразу ж можна скористатись комбінацією cmd + K, щоб зробити коміт, тут потрібно спочатку зафіксувати (stage) зміни. Це можна зробити через палітру (cmd + shift + P; Git: Stage All Changes). Або через хоткій. У мене це cmd + shift + A. Альтернативно можна скористатися відповідною кнопкою навпроти імені файлу. Після цього робимо commit за допомогою палітри або хоткія (як, в принципі, і будь-який наступний етап, тому я більше не буду повторюватись) і потім push. Також ви можете для будь-якого коміту стейджити окремий файл і навіть окремі рядки коду в файлі. Це може бути доволі зручно, коли ви намагаєтесь розбити якийсь великий шматок роботи на декілька маленьких і зрозумілих комітів.

Якщо у вас немає бажання стейджити зміни перед кожним комітом, ви можете активувати Smart Commit у налаштуваннях. Це дозволяє відразу робити коміт з усіма актуальними змінами, якщо жодних змін не було застейджено вручну.

Якщо ви застейджили окремі рядки в файлі, то можна окремо дивитись як на зміни, що застейджені, так і на ті, що не застейджені. Для перегляду файлу без порівняння з початковою версією є окрема кнопка (Open File).

Є ще один маленький нюанс щодо роботи з файлами через Source Control, що може бути неочевидним. Навпроти імені файлу ви інколи можете побачити букви M, або ж U.

Або ж червоні цифри.

Коротко:

• M — Modified.
• U — Untracked.
• Цифри — кількість помилок при компіляції, які знайшов аналізатор коду.

Плагіни

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

Git (GitLens)

Цей плагін можна вважати доповненням до Source Control. Деякі корисні функції для початку розробки за допомогою VS Code:

Git Blame

Наразі Source Control не має зручної реалізації git blame з коробки, як от, наприклад, Annotation в AS. Проте тут вона доволі непогана. Виконайте через палітру Toggle File Blame, щоб зліва від робочого простору з’явилось аналогічне до AS меню зі змінами в коді. Якщо виконати Toggle Line Blame, то плагін буде підказувати, хто і коли змінив саме рядок, на якому зараз знаходиться курсор. Також прикольна штука — File Heatmap: залежно від кольору, який з’явиться біля рядка коду, можна швидко зробити висновок, як давно внесено зміни в файл. Доволі зручно, коли потрібно шукати, що зламалось, наприклад, після останнього мержа.

Commits

Це підменю являє собою відображення всього дерева комітів. Розповідати тут мало чого, крім цікавої фічі доволі зручного порівняння гілок. Потрібно натиснути на кнопку, показану на скріні.

І в меню, яке з’явиться з палітри, вибрати потрібну гілку. Ви зможете подивитись коміти Ahead і Behind, а також зміни відносно вибраної гілки в кожному файлі.

Ще деякі підменю

Наступні підменю також потрібні й цікаві, проте немає сенсу розписувати щось дуже детально, тому коротко про головні:

• File History — як можна здогадатись, це історія змін у файлі. Показує як історію запушених в remote комітів, так і зміни: незастейджені/застейджені/закомічені.
• Branches — перелік гілок. На відміну від commits тут більше уваги приділено саме перегляду гілок і керуванню ними.
• Search & Compare — аналогічно порівнянню з меню Commits, але трішки зручніше. Можна знайти конкретний коміт або посилання (тег, гілка або посилання на коміт).
• Stashes — говорить саме за себе. Це ваш код у git stash.

Git Graph

Плагін, який дає можливість дуже зручної візуальної презентації вашого репозиторію. Крім цього, додає такі зручні функції як:

• прив’язка до issue — дає можливість навігації до issue через посилання у коментарі до коміту у вигляді номеру issue;
• автоматизація створення Pull Request для Github, Bitbucket або Gitlab.

Інтеграція з GitLab (GitLab Workflow)

Цей плагін буде до душі будь-кому, хто працює з GitLab і має регулярно робити код-рев’ю та/або слідкувати за життям проєкту. Цей плагін дає слідкувати за мерж-реквестами, створювати їх, писати коментарі, закривати треди та має ще безліч функцій, що економлять час та дозволяють рідше виходити з VSCode.

На жаль, GitLab Workflow не дає можливості затвердити запит на мерж :( Найшвидший спосіб зробити це — перейти в Overview потрібного мерж-реквесту і натиснути Open in GitLab. Тому залишається чекати, поки це реалізують, і бути активним на їхньому репозиторії.

Ще є проблема з переглядом своїх коментарів до коду, що змінився після код-рев’ю, якщо рядок з коментарем видалили. У пригоді тут стане меню Comments у панелі.

До речі, користувачам GitLab CI має сподобатись команда Validate GitLab CI config для файлів конфігурацій. Це дозволить швидко перевірити, чи все гаразд, особливо у разі об’ємних та складних конфігурацій чи коли редагувальнику бракує досвіду.

Підключення цього плагіну не є тривіальним, новачкам не завадить інструкція. Зазначу лише, що у разі помилок з instanceUrl або токеном, варто скористатись функцією Remove Your GitLab Personal Access Token через палітру. Це допоможе впоратись з тонною повідомлень про неможливість завантажити репозиторій.

Декілька невеличких цікавих плагінів

Плагіни:

• Thunder Client — маленький Postman.
• Live Share — допоміжний плагін у парному програмуванні або парному рев’ю.
• Dart build runner — зручний інструмент для роботи з build runner.
• Clipboard Manager — розширення можливостей буферу обміну, майже так само як в AS.

Run/Debug

Тут нічого складного. Launch emulator дозволяє запускати емулятор Android і симулятор iPhone, що встановлюються окремо. Також є вбудований так званий flutter emulator, який емулює роботу Android.

Через палітру вводите Debug: і вибираєте спосіб запуску, а потім і сам пристрій для запуску, якщо їх під’єднано декілька.

Для запуску необхідно обрати конфігурацію з переліку і натиснути на кнопку Run.

Праворуч від переліку конфігурацій є кнопка у вигляді шестерні, що відкриває json-файл з налаштуванням саме конфігурацій. Наприклад, щоб додати аргумент для запуску —no-sound-null-safety, треба додати поле args: [«—no-sound-null-safety(або будь-який інший параметр)»] до вашої конфігурації.

"name": "work.ua",
           "request": "launch",
           "type": "dart",
           "program": "lib/main.dart",
           "args": [
               "--no-sound-null-safety"
           ]
       },

Tests

Для запуску тестів використовуйте меню Run, де виберіть потрібну вам конфігурацію запуску. В нашому випадку це Flutter: Run all tests. На вкладці Testing можна перевірити результат виконання у вигляді переліку тестів, пофарбованих в інтуїтивно зрозумілі кольори:

• зелений — усе добре;
• жовтий — тест пропущено;
• червоний — біда.

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

Консольний вивід тесту доступний на вкладці Testing. Через палітру можна виконати Test: Show Output. Відкриється новий екземпляр терміналу з логами тестів.

Мінуси порівняно з AS

Поки за час роботи зі студією я знайшов лише це:

• Кожен індивідуальний тест, що потребує додаткових аргументів на кшталт —no-sound-null-safety, потрібно запускати через термінал, щоб не додавати конфігурацію запуску. В AS можна редагувати тимчасові конфігурації через GUI. Як варіант, можна зробити окрему конфігурацію з полем args і в ній змінювати шлях до потрібного тесту.
• Написання і супровід Swift або Java/Kotlin-коду все ж буде зручніше в Android Studio/Xcode. Тож повністю від них я б не відмовлявся.

Висновок

На момент написання статті я вже пів року використовую VS Code як основну IDE. Можна сказати, що вона задовольняє мої потреби на 90%. При супроводі коду Flutter лізти в нативний код доводиться доволі рідко, тому з цим нюансом розробки цілком можна жити.

Особисто я віддаю перевагу VS Code через зручність і функціональність, плагіни й те, як влаштована робота з ними. Мені подобається досвід, який я отримую від роботи з VS Code.

Розробникам, у котрих більшість коду знаходиться на нативному боці, я б рекомендував залишитись на Android Studio, насамперед, якщо це Kotlin. А тим, у кого більшість коду на стороні Flutter і хто відкритий до нового досвіду, — спробуйте, воно того варте.