Интервью с Барухом Садогурским: идеальный стэк технологий для Enterprise-разработки

    Барух Садогурский — Developer advocate в компании JFrog. Duke Awards в 2011 и 2013 годах, JavaOne Rock Star в 2014 г.

    Интервью проводил Владимир Сонькин, эксперт Luxoft Training в области разработки ПО на Java.



    LT: Барух, каким ты видишь стек технологий для Enterprise-проекта сегодня?

    БС: В качестве основы проекта – Java, можно Spring взять, который нужен везде, дальше зависит от требований. Если там есть web-интерфейс, то можно посмотреть на различные фреймворки, отталкиваясь от того, будет ли это продукт для внутреннего пользования или внешнего, насколько нужны всякие «свистелки» в пользовательском интерфейсе. Выбор будет зависеть от того, что именно мы делаем, какая у нас бизнес-задача: обработка ли это BigData или работа с файлами, или ещё что-то.
    В плане сборки также, Apache Maven – это солидный, надежный выбор, Gradle – это более стильный, молодежный инструмент со своими рисками. Git – как source control system, CI-сервер – Jenkins. Сегодняшний стек достаточно понятен. И где-то, может быть по краям, попробовать что-то свежее, например, написать тесты на Spok. Он, конечно, не нов, но для Enterprise-разработчиков это достаточно свежий выбор. Однако, так как тесты не идут в продакшн, то в этой области можно что-то пощупать и поэкспериментировать.

    LT: А вот если посмотреть на Scala – она в общем, уже зрелый язык. Некоторые небольшие Enterprise-проекты просто из интереса выбирают Scala. Как ты думаешь, в этом есть смысл?

    БС: Меня несколько пугает то, что сейчас происходит со Scala, потому что есть тренд ухода от Scala, например компания TypeSafe, которая пыталась зарабатывать деньги на библиотеках, связанных со Scala. Некоторое время назад было объявлено об уходе TypeSafe с сильного акцента на Scala на гораздо больший акцент в Java, потому что большая часть enterprise-разработки на Java, где собственно находятся деньги. Поэтому они наняли много новых людей, которые подтягивают какие-то Java-интерфейсы, которых раньше у них не было, потому что был в основном акцент на Scala.

    Мы также видим другие библиотеки, которые были очень ориентированы на Scala. Например, Spark, где мы видим в новом релизе, как Java API подтянуты до уровня Scala, и, похоже на то, что дальше они будут развиваться не хуже API Scala, если даже не лучше.
    Я бы сказал, что в глобальной картине мы видим некоторый разворот в сторону Java. И я абсолютно не удивлен этому, потому что Scala, как академический язык, совершенно прекрасное творение, но для Enterprise-хардкора, чтобы гнать код в продакшн, он не подходит, потому что сложен для разработчиков, которые решают реальные бизнес-проблемы, которым нужен мощный, но, в тоже время, не очень сложный инструмент, у которых в жизни есть вещи важнее, чем разбираться в системе типов Scala.

    Именно поэтому я никогда не был большим фанатом Scala, и тенденция ухода от Scala меня не удивляет. Безусловно Scala никуда не денется и продолжит развиваться, но в гораздо более нишевом формате.

    LT: То есть Scala убила её чрезмерная сложность?

    БС: Не то, что сложность. Я бы сказал – академичность. Мне кажется, с самого начала Scala была не очень хорошим выбором для массовой разработки. И когда Scala называли следующей Java, мне это было достаточно дико слышать, потому что там все очень академично и непросто для такого массового языка, который должен будет прийти на смену Java.

    LT: У Kotlin, например, порог вхождения ниже, чем у Scala?

    БС: Да, он повыше, чем в Groovy, но намного ниже, чем в Scala. Его очень приятно учить после Java. С Kotlin все по-другому, потому что ребята из JetBrains постарались выбрать те фичи, которые нужны. Посмотрим, как дальше пойдет, потому что принятие в индустрии зависит не только от качества самого языка, но и многих других причин. Например, как ты знаешь, если у создателя языка была борода, то язык будет популярным :).


    Создатели С — Кен Томсон и Дэнис Ричи — гениальные парни с гениальными бородами.

    LT: Как ты думаешь, рост популярности Java связан с тем, что вышла Java SE 8, в которую было много привнесено хорошего из той же самой Scala?

    БС: Безусловно, это сыграло свою роль – как окончание стагнации Java. Это большой плюс. Мы видим революционный релиз Java 8, мы слышим о том, что будет много интересных вещей в Java 9. В общем то, какая-то жизнь в Java опять появилась. Побег от Java в многих компаниях может быть окончен. Можно писать на Java и быть более продуктивным.

    LT: А если бы ты сам начинал сейчас Enterpeise-проект, ты бы выбрал Apache Maven в качестве фреймворка для сборки?

    БС: Это очень зависит от того, с кем придется работать: чем сильнее команда и чем больше мы полагаемся на то, что люди смогут досконально разобраться в системе сборки – тем больше мы можем уходить от Apache Maven. Но на самом деле реальность другая: обычно разработчикам не до нюансов моих build-скриптов, и в общем то следует иметь простой и надежный сборщик Apache Maven. Поэтому выбор будет зависеть от материалов, с которыми нужно работать, и сроков, будет ли у людей время для того, чтобы вникнуть в тонкости build-скриптов.

    LT: Если говорить в таком же разрезе о языках программирования: Java – это стандарт де-факто для Enterprise-разработки. А какие технологии и языки кажутся тебе на сегодняшний день самыми перспективными?

    БС: Очень хорошее сравнение, полагаю, что мы можем сравнить Apache Maven с Java, потому что это стандарт де-факто, потому что все знают, потому что достаточно предсказуемо и понятно. Я бы не сказал, что они простые, но можно рассчитывать на то, что люди будут знать про них.

    В Gradle же все больше завязано на другие языки программирования, потому что скрипты можно писать на Groovy, а скоро можно будет писать на Kotlin, и это придает некую гибкость в сравнении с Java.
    Поэтому если мы говорим об интересных языках, на которые я бы сегодня посмотрел, то Groovy – это прекрасная возможность расширить свой кругозор с небольшими инвестициями, потому что Groovy очень похож на Java. Ну и Kotlin сейчас выглядит очень многообещающе, так как ребята из JetBrains старались собрать все лучшее из других языков. Мы можем увидеть там очень много хорошего из Scala, Groovy и Java. Поэтому нужно за всем этим внимательно следить. Для большого Enterprise-проекта завтра я бы Kotlin не взял, но поиграться, потыкать, разобраться – да.

    LT: В сентябре в Люксофте у нас будет твой мастер класс на тему Apache Maven, производительности Java, профайлинга.

    БС: Да, мастер-класс будет на тему Apache Maven, а по произодительности Java, профайлингу и дефагингу будет лекция в качестве бонус-трэка.

    LT: Расскажи, пожалуйста, почему был выбран Maven при том, что сейчас есть много других популярных сборщиков? Почему стоить прийти на твой мастер-класс?

    БС: С Apache Maven все достаточно просто — как обычно у нас бывает в индустрии: у нас есть продвинутые, новаторские, интересные, современные и необычные инструменты, которые не всегда являются самыми популярными, и у нас также есть де-факто стандарты, которые не включают в себя все самое новое и интересное, но являются рабочими лошадками, которые делают то, что нужно. И в системах сборки у нас похожая ситуация: на рынке есть Gradle, который мы все очень любим посмотреть и покопать, который фонтанирует необычными решениями, и есть инструменты, на которые просто можно положиться, которые с нами уже годами и которые мы хорошо знаем. Большие, крупные компании выбирают в качестве рабочих стандартов именно второй вариант – то есть Apache Maven. И тут все логично: он понятный, более контролируемый, проверен годами.

    Поэтому мой мастер-класс будет полезен тем людям, которым нужно посмотреть один язык сборки, чтобы работать в крупной компании и понимать, что происходит со сборкой. Но я думаю, что мы не удержимся и во второй половине мастер-класса заглянем и в Gradle в обзорном формате, поговорим о разнице.

    LT: А ты будешь рассказывать про какие-то базовые вещи или какие-то тонкости и секреты?

    БС: У нас есть достаточно времени, чтобы поговорить обо всем. Мы начнем с базовых вещей, чтобы закрыть все белые пятна, даже у тех, кто уже знаком с Apache Maven. И конечно поговорим о более продвинутых вещах: написание плагинов, профили конфигураций. Поэтому я надеюсь, что интересно будет всем: и тем, кто знаком с Apache Maven, на каком-то базовым уровне и тем, кто с ним никогда не работал.

    Мастер-класс Баруха Садогурского пройдет 8 сентября 2016 г. в Москве.
    Luxoft
    88,00
    think. create. accelerate.
    Поделиться публикацией

    Комментарии 18

      +3

      Errata:


      • Создатель Artifactory не я, a JFrog. А так же Bintray, Mission Control и Xray.
      • Duke Awards в 2011 и 2013, JavaOne Rock Star в 2014
      • "Git – как артефакт" — Git как source control system
      • "Scala как академический язык совершенно прекрасное творение для Enterprise-хардкора, чтобы гнать код в продакшн, но она сложна для разработчиков..." — Scala как академический язык совершенно прекрасное творение, но для Enterprise-хардкора, чтобы гнать код в продакшн он подходит, потому что сложен для разработчиков...
        0
        >подходит, потому что сложен для разработчиков
        это хорошо получилось )))
          0

          Ага, надо Еррату на Еррату. Но вы меня поняли :)

          +1
          Внесли правки! Большое спасибо за комментарии!
          +1
          Сам за еду пишу на Java, и в целом я считаю его отличным языком, ценю так же за развитую инфраструктуру(сообщество, библиотеки и т.п.), но.
          Я не большой специалист по Scala, я изучал и изучаю его(пока для личного развития), основной костяк языка осознать смог. По этому я думаю, на фоне обсуждения Scala, утверждение: «Мы видим революционный релиз Java 8» мне кажется чересчур притянутым. Звучит как Java 8 уже не так уж далек от Scala, что в реальности и близко не так. Scala это почти как параллельная вселенная на JVM внешне может быть похожа, но если присмотреться отличается уже в своих основах. Хотя бы, всё объект и все операции есть вызов методов, подобные фундаментальные отличия приводят к кардинально иным возможностям.
          Соглашусь для, большинства Scala слишком сложна. Многие и Java с трудом осваивают, на хорошем уровне и таких массовых работников очень много — реальность.
            0

            Я не сравнивал Java 8 и Скалу. Тот факт, что "лёд тронулся" в Джаве означает для многих компаний, что рано Джаву хоронить, и переход на следующий язык можно отложить. То есть умирать сейчас в Скалу не обязательно, можно, например, подождать пока Котлин прорелизится до стабильного состояния.

              0
              У Scala когда-то планируется релиз Dotty. Как вы думаете, это повлияет на популярность языка? То, что язык рано использовать в Enterprise — чистая правда, и дело скорее не в сложности, а в том, что очень быстро происходят изменения библиотек с запрещением методов и порождением новых подходов, а документация не успевает за этим, тем более люди. Примером можно считать Play 2.5, когда определились как делать DI и конфигурацию, а это повлияло на большое количество библиотек — они попросту отвалились. Однако же после Scala работа на Java с Optional и Stream API кажется не полной, но и на этом спасибо, потому что некоторые коллеги до сих пор не могут понять map на объектах, куда им там Scala.
                0

                Ну, я думаю, причин, почему Скалу не нужно использовать в Enterprise больше, чем одна. И конечно, совершенно бездумные изменения — не менее важная причина, чем сложность.

                +2
                Котлин позиционируется как простая Скала без «лишних» фич. Но судя по прогрессу Джавы (лямбды, автовывод типов и т.п.), она сама не прочь занять эту нишу. В этой связи странно советовать ждать Котлин, ведь проще будет проапгрейдить уже знакомую Джаву и получить тот же прирост продуктивности.

                На мой взгляд реальный выбор пока есть только между Джавой и Скалой, с понятными плюсами/минусами вариантов. Котлин как компромисс между ними может не успеть стабилизироваться к тому моменту, как джава его догонит и перегонит.
                  +1

                  Котлин это намного больше, чем просто Джава с лямбдами и автовыводами типов. Котлин это попытка взять лучшее как минимум у Джавы, Скалы и Груви. Это очень интересный эксперимент, и время покажет насколько он удачен. По-моему выглядит очень многообещающе, и поэтому я и советую то, что советую.

                    0
                    К сожалению, некоторые решения по сборке котлин-проектов пока вызывают отторжение. Причем грабли все теже, которые уже в груви проходили — так нет, надо наступить еще раз. Я о совместной компиляции, если что.
                      0

                      Да, там ад. Для Груви, кстати, есть интерн, который пишет новый кросс-компайлер для своей докторской.

                    +2

                    Java его не догонит принципиально и уж тем более не перегонит, из-за обратной совместимости. Не говоря о том, что с учетом темпов развития Java (даже нынешних) пришлось бы ждать этого лет двадцать.

                      0

                      Для Джавы таких целей нет. Но знать, что на движется хоть как-то уже достаточно для многих компаний, чтобы не искать альтернативы.

                +1

                Интересное интервью, жаль что короткое.


                По Kotlin согласен — язык еще пока очень сырой. 1.0 ознаменовал совместимость синтаксиса (хотя язык еще даже не специфицирован формально, поэтому есть ли гарантия совместимости семантики, мне не понятно), но весь тулинг, компилятор, иде, стандартная библиотека — это все еще полуфабрикаты.

                  0
                  Барух, аргументы про идеальную адаптацию Java для массовой разработки понятны, не понятно другое — почему ты считаешь, что массовая разработка будет рулить и в дальнейшем? Не постигнет ли разработку та же судьба, что происходит, например, в военном деле, где небольшие оснащённые и прекрасно обученные отряды спецназа способны эффективными ударами по болевым точкам поставить на колени огромную неповоротливую массовую армию? Почему ты считаешь, что рост эффективности многообразного инструментария с т.з. производительности труда (т.е. по сути постоянного увеличения масштабов эффективно решаемых задач) не перевесит уменьшение кол-ва разработчиков из-за повышения порога вхождения?
                    0

                    Это отличный вопрос, и я, безусловно, не имею на него ответа. Хотелось бы видеть такие изменения, но пока-что мы этого не наблюдаем вообще. Даже enterprise-ы, которые пробуют Скалу (то самое, якобы эффективное оружие для спецназа) немедленно начинают набирать армии закончивших трехмесячные курсы. Проблема только в том, что если на трехмесячных курсах по Джаве еще можно чему-то научить, то Скала...

                      0
                      Профессионалы зачастую предпочитают простые и эффективные инструменты сложным дорогим и капризным. Scala, конечно, интересный язык, но, IMHO, это просто Java без backward-compatibility, я же имел в виду скорее более радикальные подходы — в первую очередь Clojure и Rust. Первый по сути просто AST, что позволяет глубоко контролировать код большого проекта, не утопая в протекающих абстракциях. Второй — вообще по сути Си, элегантно решивший проблему утечек памяти без дорогих и хитрых сервисов вроде сборщика мусора (в 9-ке существенно перепилят JNI и его можно будет встраивать в байт-код существенно менее болезненно, чем Си-шный код сейчас). Массовыми языками они, конечно, не станут, из-за того самого порога, но, как ты думаешь — могут ли стать тем самым камушком в руке Давида?..

                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                  Самое читаемое