Коли DevTools допомагає, а коли — ні

1. DevTools — турборежим локальної розробки

DevTools легко сприймати як обов’язкову частину Spring Boot: увімкнули — і все «живіше», швидше, веселіше. Але це приблизно як звикнути їздити містом лише за навігатором, а потім раптом виявити, що ви не знаєте, де північ. DevTools — помічник, який прискорює локальну розробку, але не повинен підміняти розуміння того, як застосунок зазвичай стартує і працює.

Якщо дивитися на catalog-service як на навчальний шаблон, DevTools — це «знімний прискорювач». Він не змінює архітектуру домену, не робить ваші @ConfigurationProperties правильнішими і не лагодить зламане зв’язування. Він просто допомагає частіше отримувати результат: виправили контролер — майже одразу побачили новий JSON, виправили index.html — швидко оновили сторінку, виправили YAML — контекст перебудувався і підтягнув нове значення.

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

Звичайний запуск і порівняння поведінки

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

У режимі DevTools JVM процес зазвичай не перезапускається. Перезапускається application context, перебудовується частина завантаження класів, пересобираються біни, піднімається вбудований сервер, виконуються startup runners — але сам процес залишається тим самим. І саме це «сам процес той самий» іноді впливає на сприйняття. Наприклад, якщо якась бібліотека або інфраструктурна частина тримає статичний стан у base classloader’і, він може переживати рестарти. У звичайному повному stop/start такого не буде — усе почнеться з нуля.

Ще одна причина — відтворюваність. Ви хочете, щоб колега або ви самі через тиждень могли запустити проєкт без хитрих локальних умов і отримати таку саму поведінку. DevTools має прискорювати, але не перетворювати запуск на квест: «а у вас DevTools точно увімкнено? а exclude не надто широкий? а IDE не тримає старий процес?».

І так, у catalog-service DevTools підключений як developmentOnly, тобто він не повинен ставати частиною «звичайного життя» застосунку як артефакту. Це заздалегідь захищає від ситуації «випадково притягнули DevTools у нелокальне середовище і отримали сюрпризи».

2. Вимкнення DevTools

За замовчуванням local-режим у нас залишається простим: DevTools підключений як developmentOnly, налаштування живуть у application-local.yaml, restart увімкнений. М’яке й жорстке вимкнення — це тимчасові діагностичні режими, а не новий штатний стан проєкту.

Три рівні вимкнення

Коли кажуть «вимкни DevTools», новачки часто роблять одне й те саме: викидають залежність із Gradle. Іноді це нормально, але частіше — це надто грубо. У реальності є кілька рівнів вимкнення, і вони розв’язують різні задачі. Зручно тримати в голові таку карту.

Звучить схоже, але різниця суттєва. Варіант №2 — це найчастіше «тимчасово перестати реагувати на кожне збереження файлу». Варіант №3 — це вже «мені треба, щоб старт був максимально чистий, без участі restart-механіки взагалі».

М’яке вимкнення авторестарту

Коли ви втомилися від нескінченних рестартів, особливо якщо правите багато файлів підряд, хочеться кнопочку «завмри». І така кнопочка є: spring.devtools.restart.enabled=false. Це зручний, конфігураційний спосіб сказати DevTools: «не стеж за змінами і не перебудовуй контекст автоматично». Важливо лише розуміти, що саме ви вимикаєте і що при цьому залишається увімкненим.

Ось найпряміший варіант для локального профілю:

# src/main/resources/application-local.yaml
# Локальний профіль: DevTools залишається на classpath, але перестає автоматично перезапускати контекст
spring:
  devtools:
    restart:
      enabled: false # Вимикаємо авторестарт під час збереження файлів

Це рішення добре тим, що воно залишається в межах нашої загальної моделі: усе, що стосується локальної поведінки, ми намагаємося тримати в application-local.yaml. Ми не розкидаємо dev-only налаштування по спільному application.yaml, щоб потім не дивуватися: «чому у мене в dev/production щось дивне».

Але є важливий нюанс, про який варто пам’ятати: навіть після такого вимкнення підтримка restart classloader усе ще може бути ініціалізована. Тобто ви вимкнули «автоматичну реакцію», але сам механізм може бути піднятий. Тому якщо ваша проблема виглядає як «щось дивне з класами і classloader’ами», м’якого вимкнення може не вистачити — тоді потрібен жорсткіший варіант.

І ще один момент: цей спосіб вимкнення ідеальний як «режим тиші», але він не замінює звичайний stop/start. Якщо ви змінили щось велике й хочете гарантовано почати «з чистого аркуша», DevTools тут просто не обов’язковий — іноді чесніше перезапустити застосунок вручну. Закінчили перевірку — поверніть enabled назад або просто приберіть цей ключ, щоб local-режим знову залишався швидким за замовчуванням.

Повне вимкнення до старту застосунку

Бувають ситуації, коли ви хочете, щоб застосунок стартував так, ніби DevTools взагалі не існує. Найнадійніший спосіб — виставити системну властивість до запуску контексту. Усередині коду це виглядає так (так, це саме той приклад, який іноді роблять на час діагностики):

package com.example.catalogservice;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;

@SpringBootApplication
public class CatalogServiceApplication {

    public static void main(String[] args) {
        // Важливо: задаємо властивість ДО SpringApplication.run(...),
        // інакше restart-механіка могла вже встигнути ініціалізуватися
        System.setProperty("spring.devtools.restart.enabled", "false");

        // Зазвичай акуратніше передавати це як JVM-аргумент (-Dspring.devtools.restart.enabled=false),
        // а рядок у main() тримати лише як тимчасовий діагностичний прийом
        SpringApplication.run(CatalogServiceApplication.class, args);
    }
}

Сенс тут не в тому, щоб назавжди залишити такий рядок у main() (зазвичай це якраз погана ідея для постійного стану проєкту), а в тому, щоб однозначно вимкнути restart-support ще до того, як Spring Boot почне ініціалізувати застосунок. Це схоже на «запуск у безпечному режимі»: ви виключаєте один шар поведінки і перевіряєте, що змінилося.

На практиці те саме можна зробити через JVM-аргумент -Dspring.devtools.restart.enabled=false під час запуску, і це навіть акуратніше, бо не потребує правки коду. Але в межах навчального проєкту корисно один раз побачити, що «до run(...)» дійсно має значення: частина інфраструктурних рішень ухвалюється дуже рано, і іноді важливо потрапити саме в цей ранній момент.

Головна думка: якщо ви намагаєтеся розслідувати поведінку, яка схожа на classloader-магію, то вимикати DevTools «після старту» — запізно. Потрібен варіант, який діє одразу. Перевірили гіпотезу — прибрали цей рядок або JVM-аргумент і повернулися до звичайного local-режиму. Залишати такий тумблер у main() на постійній основі — майже гарантований майбутній сюрприз.

3. Коли DevTools заважає: симптоми й діагностика

DevTools найчастіше працює ідеально і просто економить час. Але коли він починає заважати, відчуття у новачка зазвичай однакові: «я нічого не розумію, воно саме перезапускається, а помилка то з’являється, то зникає». Щоб не перетворювати діагностику на шаманство, корисно знати кілька характерних симптомів і мати простий сценарій перевірки.

Один із найпоказовіших симптомів — коли проблема зникає після повного stop/start, але вперто відтворюється або «плаває» під час devtools-рестартів. Це прямий натяк, що десь є стан, який переживає рестарти. У нашому навчальному catalog-service ми намагаємося не створювати таку ситуацію, але в реальному житті це буває, наприклад, через статичні кеші в бібліотеках, через фонові потоки або через об’єкти, які утримуються в base classloader’і.

Другий симптом — коли у винятках починають миготіти слова, схожі на RestartClassLoader. Наприклад, ви можете побачити щось на кшталт ClassCastException, де формально «клас не може бути приведений до цього самого класу». Звучить як анекдот, але це класичний ефект двох завантажувачів: для JVM «однакова назва класу» не означає «той самий клас», якщо його завантажили різні classloader’и. У такому разі DevTools стає підозрюваним номер один.

Третій симптом більш буденний: ви в налагоджувачі поставили брейкпоінт, а після чергового рестарту він ніби «перестав спрацьовувати», або ви бачите, що IDE тримає стару картину класів. Це не завжди DevTools, але DevTools часто бере участь у цьому танці, бо класи справді «переїжджають» у новий restart classloader.

Четвертий симптом — коли ви змінюєте конфіг, очікуєте, що його застосовано, але застосунок поводиться так, ніби конфіг старий. Тут DevTools може бути винен опосередковано: наприклад, ви виключили потрібний шлях із рестарту або, навпаки, очікуєте рестарту від файлу, за яким DevTools не стежить. Тоді проблема розв’язується не «вимкнути DevTools назавжди», а «привести політику restart до ладу». Але перший крок діагностики все одно корисний: вимкнути restart і подивитися, що зміниться.

Щоб не тримати все це в голові як набір «страшилок», зручно дивитися на діагностику як на маленький алгоритм. Його можна навіть зобразити як блок-схему:

flowchart TD
    %% Швидка перевірка: відокремлюємо помилки коду/конфігурації від ефектів рестартів DevTools
    A["Дивна поведінка після змін"] --> B{"Проблема відтворюється після повного stop/start?"}
    B -- "Так" --> C["DevTools, імовірно, не причина: шукаємо в коді або конфігурації"]
    B -- "Ні" --> D{"DevTools увімкнений?"}
    D -- "Ні" --> C
    D -- "Так" --> E["Вимикаємо restart (enabled=false) і перевіряємо"]
    E --> F{"Проблема зникла?"}
    F -- "Так" --> G["Це ефект рестартів/classloader: тимчасово працюємо без рестарту або вимикаємо restart-support повністю"]
    F -- "Ні" --> C

Зверніть увагу на важливу методичну деталь: DevTools тут не «цап-відбувайло», а просто один із чинників середовища. Ми не починаємо з «видалити залежність». Ми спочатку чесно перевіряємо, чи впливає вона взагалі.

І останнє. Не плутайте «DevTools заважає» з «DevTools незручний». Якщо вам просто не подобається, що сервіс рестартить надто часто, це розв’язується налаштуваннями exclude/additional-exclude і звичкою зберігати файли осмислено. Якщо ж ви бачите ефекти, схожі на класи, які ніби роз’їхалися, дивні винятки або помилки, що зникають, — тоді так, DevTools краще на час вимкнути й налагодити поведінку в максимально звичайному режимі.

4. Стратегія DevTools у catalog-service

У нашому курсі catalog-service — не просто «проєкт для галочки», а майбутній шаблон. Тому DevTools ми використовуємо так, щоб він не залишав після себе слідів в архітектурі й не перетворював конфігурацію на «ліс локальних заклинань». Стратегія проста: DevTools підключений як developmentOnly, у application-local.yaml живуть лише зрозумілі devtools-налаштування, а restart за замовчуванням увімкнений. Усі вимкнення й тумблери живуть рівно стільки, скільки потрібна діагностика.

Якщо ви хочете, щоб DevTools був завжди увімкнений у локальному профілі, це має виглядати максимально прозоро: у вас є application-local.yaml, і там видно, що рестарт дозволений. Якщо ви хочете тимчасово вимкнути рестарт — ви змінюєте рівно одну властивість у локальному профілі або передаєте системну властивість перед запуском, і цю зміну легко пояснити словами. Головне — не перетворювати DevTools-налаштування на «шум»: чим більше там магічних патернів, тим частіше ви думатимете, що застосунок «сам по собі дивний», хоча насправді ви просто забули, які правила йому задали.

Гарна звичка в такому проєкті — періодично запускати сервіс у режимі, максимально схожому на звичайний: без авторестартів. Не заради покарання, а заради впевненості: ви перевіряєте, що ваше зв’язування й конфігурація не залежать від «особливого режиму». Це особливо корисно для config-first проєкту: вам важливо бачити, що @ConfigurationProperties стабільно біндиться і валідовується, і що зміни конфігів не дають «фантомних» ефектів.

І ще одне: якщо вам доводиться додати в main() тимчасовий System.setProperty(...) для діагностики — сприймайте це як тимчасову лупу, а не як частину дизайну застосунку. У нормальному стані шаблону CatalogServiceApplication має бути чистим і не містити «локальних тумблерів». Локальні тумблери у нас уже є — вони називаються профілі й YAML.

5. Типові помилки DevTools

Коли DevTools тільки з’являється в проєкті, він часто викликає дві протилежні реакції: одні починають вірити, що «тепер завжди буде швидко і правильно», інші в першому ж незрозумілому випадку кричать «усе, видаляю DevTools». Обидва підходи приводять до однакового результату: ви втрачаєте керованість.

Помилка №1: вимикати DevTools у спільному application.yaml, а потім дивуватися, що локально все стало повільнішим.
Це дуже часта історія: хтось один раз вимкнув рестарт, щоб спокійно порефакторити, і залишив налаштування в загальній конфігурації. Через день інша людина або ви самі запускаєте проєкт і отримуєте «чому воно не оновлюється?». DevTools-налаштування майже завжди мають жити в application-local.yaml, щоб не зачіпати базову поведінку.

Помилка №2: плутати «вимкнути авторестарт» і «повністю прибрати restart-механіку».
spring.devtools.restart.enabled=false вимикає автоматичний рестарт як реакцію на зміни, але при цьому DevTools залишається на classpath, і частина його інфраструктури може все одно брати участь у старті. Якщо ви боретеся з classloader-ефектами, вам потрібен варіант «до SpringApplication.run(...)» або повна відмова від залежності, інакше ви лікуватимете симптоми, а не причину.

Помилка №3: діагностувати помилки лише в режимі DevTools і вважати це «реальною» поведінкою застосунку.
DevTools — це спеціальний режим. Якщо ви бачите дивину, яку ніяк не можете пояснити, порівняння зі звичайним запуском — дуже сильний крок. Іноді виявляється, що проблема взагалі не в DevTools, а в тому, що ви змінили конфігурацію, але очікували «reload» там, де потрібен «restart», або виключили потрібний шлях. Але доки ви не порівняли режими, у вас немає точки опори.

Помилка №4: одразу видаляти залежність із Gradle замість тимчасового вимкнення restart.
Видалення залежності — це як вимкнути електрику в усьому будинку, бо вас дратує лампочка в коридорі. Іноді потрібно, але частіше це занадто грубо. Зазвичай розумніше спочатку вимкнути рестарт у application-local.yaml, а якщо стало краще — уже вирішувати, чи потрібна повна відмова від DevTools на час.

Помилка №5: перетворювати DevTools-налаштування на «таємну магію», яку ніхто не розуміє.
Коли в application-local.yaml з’являється десяток патернів exclude/additional-paths, і ніхто вже не пам’ятає, що вони означають, DevTools перестає бути прискорювачем і стає джерелом випадковості. У навчальному й шаблонному проєкті важливо, щоб будь-яке налаштування можна було пояснити словами: «це не рестартить, бо статичний ресурс» або «за цим каталогом стежимо, бо він зовнішній».