Мини-интервью: Евгений Борисов — о Spring

В онлайн-трансляции JPoint 2017 между докладами мы брали небольшие интервью у спикеров, а теперь решили выложить их в открытый доступ. Самое первое из них было с Евгением Борисовым о его Spring (Boot)-докладах — и ответы получились такими, что из них можно узнать не только о самих докладах, но и о состоянии всей Spring-экосистемы.

На предстоящем Joker он совместно с Кириллом Толкачёвым тоже будет говорить о Spring Boot, но ещё подробнее: там выступление займёт целых два временных слота.

— Уважаемые участники, я рад приветствовать вас в нашей мобильной студии. И с нами открывает серию мобильных интервью Евгений Борисов: NAYA Technologies, Spring-потрошитель — у него много имен, и вы все их знаете.

— Здравствуйте!

— Евгений, начнём с простого. У тебя два доклада сегодня и завтра: «Проклятие Spring Test» и «Spring — Глубоко и не очень». Можешь рассказать, что будет?

— Давайте начнём с «Проклятия Spring Test». Во-первых, это не совсем проклятие Spring Test, это проклятие Spring Boot Test. Речь пойдёт не о том, как правильно методологически писать код согласно TDD. В последних версиях Spring Boot появилось очень много разных фишек, которые ещё не сформировали так называемые best practices, и не очень понятно, как ими всеми правильно пользоваться. В последний месяц мне пришлось очень много переписываться с разработчиками Spring, потому что ни в документации, ни в каких-то других источниках на некоторые неочевидные вопросы ответы были не найдены, и поэтому цель доклада не столько показать, как правильно делать вещи, а больше осветить с технической точки зрения, что каждая функциональная аннотация (например, в этом новом мире Spring Boot Test) умеет делать, как это правильно работает, ну и высказать какое-то сформировавшееся на данный момент мнение, когда и чем правильно было бы пользоваться. Может быть через год, когда накопится ещё больше опыта со всеми этими новыми вещами, можно будет сформулировать какую-то более стройную версию, в каком порядке, как правильно всё это дело писать именно по TDD. Но на данный момент это не совсем по TDD, это именно технические ограничения и возможности новых фишек Spring Boot Test.

— От Кирилла Толкачёва, совместно с которым будет этот доклад, я слышал, что там будет рассмотрено много «подводных граблей». Есть неочевидные моменты, которые могут всё сильно подпортить. Интересно, есть ли какой-нибудь один конкретный, наглядный, который вот сейчас, в отрыве от доклада, можно озвучить?

— Spring Boot вышел несколько лет назад, и чем дальше, тем больше он набирает популярность. Все любят писать микросервис, Spring Boot очень сильно в этом помогает, потому что он и решает проблему зависимости, и умеет делать упаковку, уже с embedded Tomcat, чтобы у нас получался независимый jar-ник, который является микросервисом. Несколько лет назад не было никакой возможности сымитировать то, что Spring Boot будет делать по-настоящему. То есть получается, что ты пишешь код на Spring Boot, а когда ты пишешь тесты, у тебя там Spring Boot нет. Соответственно, когда ты создаёшь тестовый объект при помощи стандартного SpringRunner, что-то в него inject-ишь и начинаешь что-то проверять, у тебя вся магия, которую Spring Boot должен сделать, — она не происходит. И все твои интеграционные тесты начинают разваливаться, и приходится тут и там подкладывать костыли. Где-то чуть больше года назад появился новый модуль, по-моему, из версии Spring Boot 1.2, параллельно появился модуль Spring Boot Test, который, благодаря магической аннотации @SpringBootTest, плюс-минус имитирует то, что делает настоящий Spring Boot, и тогда палки-костыли подставлять не нужно. Но у него есть очень много разных side-эффектов. Я не думаю, что сейчас имеет смысл начинать их обсуждать, потому что мы углубимся в очень технические детали, а как раз об этом и будет доклад.

— Ясно. А второй доклад?

— Тут очень важно объяснить, в первую очередь, почему у меня так много докладов о Spring. Я считаю, что то накопленное количество дизайн-паттернов и опыта большим числом программистов — оно всё реализовано в Spring контейнерe и, соответственно, для того, чтобы писать красивый код, который будет менеджериться с этим контейнером, чтобы у нас была инверсия контроля и много всяких разных других вещей, которые правильно делать, нужен какой-то фреймворк. Со Spring сравниться сейчас не может никто. Проблема в том, что, особенно ещё и благодаря Spring Boot, Spring очень сильно занижает порог вхождения. Можно взять ребёнка, он зайдёт на сайт start.spring.io, скачает себе какой-то темплейт проекта, поставит пару аннотаций и у него всё заработает. Проблема в том, что будет дальше, когда у него что-то начнёт разваливаться, сможет ли он это починить, сможет ли он с этим разобраться, поймёт ли он, как правильно что-то использовать, какие паттерны, какие антипаттерны. Поскольку я очень много с этим работаю, и по сути своей работы я хожу в разные компании, где-то я консультирую, где-то я занимаюсь менторингом, а где-то провожу тренинги, я вижу ошибки, которые делают люди. Наш мир не идеален, к сожалению. То есть нельзя сказать: «Правильно делать вот так!» — и все так делают, и вот такой кейс никогда не может возникнуть. Возникают очень многие антипаттерны, и вопрос, как потом это всё разруливать, потому что не всегда получается сказать: «Мы что-то неправильно сделали в архитектуре, давайте мы сейчас сядем и это всё перепишем по-новому».

Соответственно, надо как-то разрулить ситуацию сейчас, а для этого надо понимать, что на самом деле всё это делает. И в данном докладе — «Spring Boot — Глубоко и не очень» — почему именно «глубоко и не очень»? Потому что на JPoint-е очень любят кишки, и у меня есть несколько кейсов, в которых мы реально очень сильно уходим под кишки и смотрим, как работает Spring, чтобы лучше понять, как он работает, и тут не всегда есть какой-то совет. То есть я вот эти закапывания в кишки делаю не для того, чтобы сказать: «Ребята! С завтрашнего дня начинайте делать вот это!». Я просто придумываю иногда какие-то даже не совсем эзотерические кейсы, то есть я беру какие-то аллегории с продакшн-кейсов, которые у нас происходили в разных местах, упрощаю их очень сильно и на их примере пытаюсь ковыряться в этих кишках. При этом, почему опять же «глубоко и не очень», что — «не очень»? Есть очень простые и тривиальные ситуации, но, к моему удивлению, оказывается, люди не знают совершенно банальных вещей, потому что никогда, может быть, этим не интересовались, и иногда из-за этого вылезают какие-то очень странные штуки. Не все люди знают, как правильно отрабатывает аннотация @Autowired в разных случаях, не все знают, что каждая версия Spring может что-то чуть-чуть поменять, и появляется какое-то очень странное поведение. Очень часто человек от Spring что-то ждёт, а этого нет, он пишет какой-то свой собственный костыль, переходит на следующую версию Spring, там это уже встроено, его костыль отвалился, в результате происходит какая-то беда. И доклад будет освещать подобные аспекты из совершенно разных областей Spring.

— Spring — это хорошо. Раньше ты ещё рассказывал про Spark, в том числе у тебя были тренинги по Spark. Почему в этот раз Spark нет на JPoint? Есть ли причина?

— Нет никакой причины, я думал ограничиться одним докладом, в итоге получилось два. Если было бы больше времени, может быть сделал бы по Spark тоже.

— Спасибо, Евгений. До встречи на докладе!

  1. Евгений Борисов
    Разрабатывает на Java с 2001 года и принял участие в большом количестве Enterprise-проектов. Пройдя путь от простого програмиста до архитектора и устав от рутины, он вышел в свободные художники. Сегодня Женя пишет и проводит курсы, семинары и мастер классы для различной аудитории: live-курсы по J2EE для офицеров израильской армии. Spring – по WebEx’у для румын, Hibernate через GoToMeeting для канадцев, Troubleshooting и Design Patterns для украинцев. @jekaborisov