
Около десяти лет тому назад, я работал, в паре со своим «тимлидом», над разработкой штуки, которая кешировала данные из базы. Или чем-то похожим. Продукт, который мы «пилили», было невозможно запустить локально. Процесс разработки был следующим: делаешь изменения, собираешь «джарник», закидываешь его по FTP на сервер, «рестартуешь» сервис из веб-консоли «веблоджика» или через терминал, ждёшь 5 минут, идёшь проверять свой кусочек. Не очень удобно и очень долго, цикл обратной связи очень медленный, работа неэффективна. Дело осложнялось ещё и тем, что на нескольких разработчиков выдавали один сервер и приходилось синхронизироваться с коллегами.
И вот, у нас опять что-то не работает и «тимлид» делает следующую вещь: добавляет в настройки «веблоджика» какую-то штуку, создаёт конфигурацию в IntelliJ и включает remote debug. После этого заходит на страничку с нашей функциональностью, нажимает кнопочку и дебаггер останавливается в нужном месте, позволяя нам понять, что вообще происходит. Я не помню, использовал ли я «дебаг» до этого, но факт того, что мы можем запустить что-то на удалённом сервере и остановить его, а потом получить себе в IDE контекст выполнения — здорово взорвал мне мозг. Теперь можно было посмотреть, что происходит на сервере, какие объекты и куда подгрузились и так далее, и так далее.
Но самое интересное было потом. Оказывается, если подключиться дебаггером к серверу, потом сделать какие-то изменения в коде и перекомпилировать проект, то Idea предлагает сделать hotswap и заменить код на сервере свежесобранным. Вот тут я прозрел окончательно. Огромное количество девелоперов в той компании тратили время (часы, дни, недели!) на «ребуты» серверов, на пересборку и «переподкладывание» классов и «джарников», на синхронизацию и т. д., а оказывается, что можно за секунду «подсунуть» JVM свои изменения и тут же смотреть на результаты.
Эта техника очень серьёзно подняла мою продуктивность. Поэтому первое, чему я учил свежеприбывших «джунов» — это как настраивать «ремоут дебаг», как подключаться и как «переподкладывать» классы в «рантайме», чтобы быстро вносить и проверять свои изменения. Кроме того, «дебаггер» был лучшим способом быстро понять, что вообще приходит тебе извне. Так как продукт был очень комплексным, то данные, перед тем, как прийти в точку назначения, проходили миллион слоёв платформы и других кусков бизнес-логики. И функция evaluate expression здорово помогала посмотреть в «потроха» незнакомых объектов.
Интересно, что до сих пор я нечасто вижу людей, которые подключены к запущенному серверу приложений (даже локальному) и «перекладывают» там свои изменения. Вместо этого все предпочитают «рестартовать» код или, ещё хуже, запускают CI/CD для того, чтобы протестировать свои изменения.
Автор: Рожок.
Ещё материалы по этой теме:
- F-образный принцип чтения веб-страниц
- Пятисот или пятиста?
- Я понял, чем занимаются продуктовые дизайнеры