Без конкретики это все больше на вброс похоже. Нужно привести альтернативы, например, если пагинация антипаттерн, то как тогда лучше получать лимитированное количество записей и не убить сервак если в бд десятки миллионов записей?
Мне, кажется, что 20 лет назад еще не было intellij idea и такого количества готовых библиотек, я даже не знаю в чем тогда писали, возможно и компилировали еще каждый класс отдельно. Сейчас инструментарий решает много в производительности и исследовать нужно современные реалии, а не прошлый век. Поэтому количество строк кода вообще не показатель. И jackson может прям из файла читать, не нужно много строк велосипеда писать, врядли кто-то сейчас вручную парсит json и csv файлы. Не понимаю зачем унижать какой-то язык - нравится питон, пожалуйста, пишите, это ваше дело. В продуктовом enterprise часто задача может согласовываться неделю или две, а потом в 20 строк кода решаться за 1 час и что на питоне, сто на java время написания будет одинаковым, а вот общее время выполнения задачи от языка мало будет зависеть.
Вообще не понял для чего эта статья и для чего это нужно. Избавиться от if/else на 3-5 строк, чтобы нагородить несколько объектов, интерфейсов, обмазаться optional, а впродакшен коде там тысячи ветвлений, это в простом коде тогда будут тысячи классов пустышек и интерфейсов. Как я часто пишу - страшное в таких статьях то, что джуны сейчас пойдут такое продвигать и использовать, и вот такое нельзя допускать.
Если делать такое чисто по фану, то нужен отдельный раздел на хабре для таких приколов.
Я абсолютно уверен, что человек, пишущий коммерческий код на одном из чисто ООП-шных языков более 3-4 лет, и который не заметил множество его проблем и не начал думать о переходе или переходить на ФП — не может считаться крутым инженером
Такие высказывания, как я считаю, полная ерунда и признак джунов или начинающих мидлов, которые цепляются за конкретный язык или технологию (особенно когда только что прочитали умную книгу или статью), и пытаются убедить всех, что все остальное это плохо, а вот это вот просто грааль и нужно использовать везде. Как раз таки признак крутого инженера с богатым опытом в том, что он в первую очередь решает задачи, а во вторую разбирается с языком (выбирает наиболее подходящий под задачу и с учетом опыта и компетенций инженеров в компании), т.к. зачастую мы попадаем в проект где уже все используется до нас и нам нужно продолжить работу, и если там для меня новый язык, то я пойду разбираться с ним, а не скажу заказчику, что его выбор плохой и нужно все переписать на моем любимом языке, затратив много месяцев и денег. Так в продуктовой разработке не работает. Крутой спец будет разбираться с тем, что досталось и не искать 100 минусов в ООП. Такие инженеры-фанаты яп опасны еще и тем, что могут появляться внутри компании в рамках одной команды специфичные языки/технологии, которые не используют другие команды и в будущем, когда проект перейдет другой команде, то начнутся большие проблемы. Очень показательны примеры поиска спецов на Scala в разных компаниях, на котором мало кто хочет писать и для рекрутеров это большая головная боль, зато себе в карме человек поставил галочку - протащил свой любимый яп. Мораль моего комментария - такие статьи очень опасны (особенно на хабре), т.к. молодые джуны и мидлы после прочтения уверуют эту идею, и будут потом всем доказывать, что ООП это зло, а ФП это круто и удобно.
Есть вопросы по сборке java - он просто jar’ку собирает и запаковывает? Тогда это не совсем правильный способ.
Жаль, что в статье очень много не затронутых важных вопросов, хотя бы про то, можно ли делать дополнительны кастомизации и как? И будет ли в этом случае реальный профит в сравнении с обычным dockerfile’ом.
А вот про ставить везде try/catch не понял - зачем это делать если кастомный ApiException наследуется от RuntimeException и в коде никак особо не выделяется, поэтому нет необходимости его везде специально ловить. А корневой exception также описывается в exception handler с общей ошибкой и своим кодом и опять же нигде не нужно его ловить специально или помнить, если только мы не пишем что-то отличное от rest service, но такого в реальной жизни процентов 5, наверное.
Я понял. Возможно у вас действительно очень специфичный кейс когда достаточно одной ошибки. Но у нас в реальной жизни в проекте мы выбрали как раз путь вложенных классов (на котлине очень просто и круто реализуется) и в exception handler’e прописали 1 корневой ApiExeption, в котором логика запаковки в json для ответа. Теперь не нужно больше ничего туда добавлять. А в коде вместо IllegalException и прочих кидаем свои с необходимым именем. Это дает возможность в методе кидать столько разных ошибок, сколько нужно и главное, что в коде по имени исключения понятно за что оно отвечает. Ну и на скорость не сильно влияет, нет лишних аспектов на каждом вызове. А чтобы не плодить коды и исключения - организовали их в группы. Очень читабельный код получается. Ну и поверх класса с кодами добавили генерацию html доки для саппорта и тестировщиков с описанием.
Кажется, я не совсем понял возможно ли в данном подходе отдавать разные коды ошибок внутри одного метода и как? В методе, например, может быть ошибка что, юзер не найден или подписка не найдена, аккаунт заблокирован или юзер заблокирован и т.д. К сожалению, в реальном мире почти невозможно плодить микрометоды под каждую ошибку отдельно или походы в другие микросервисы могут порождать разные ошибки.
Как раз цель была в красивости и удобстве (учитывая что за это платят деньги). Второе ограничение - это некоторые специальные библиотеки для проекта, доступные для JAVA. Банальное десктопное приложение можно писать на чем угодно - согласен, но обычно это не production-ready система, которую захотят покупать пользователи. Да и мне как JAVA разработчику гораздо удобней использовать язык который я хорошо знаю, а REACT я тоже немного знал и с ним все было просто. Опять же, почему REACT - я купил готовый HTML + REACT шаблон и получил красивый дизайн и набор всех компонентов из коробки, которые просто блоками копирую и вставляю какие нужны. Сэкономил месяцы времени только на UI и дизайне. Поэтому тут каждый выбирает инструменты под задачи. Достойных альтернатив нативной компиляции я пока не встречал.
Я, к сожалению, про RPS не могу сказать, т.к. профиль нагрузки это десктопное приложение с не большими вычислениями (сейчас под активной нагрузкой CPU от Java приложения не выходит за 70% от ядра) и я не измерял, но проверить под нагрузкой это хороший поинт. Будет время - проверю.
Спасибо за комментарий! К сожалению, с IOS не приходилось работать, но интересно звучит. Читал, что есть нативные возможности самого котлина для кроссплатформенной сборки под Android и IOS.
Прошу прощения, не наптсал, что мы разрабатываем коробочные решения, работающие на одной машине, таковы требования и речь здесь идет о сборке общего контейнера для эмуляции работы одной машины для разного рода тестов и некоторых других работ перед созданием готового образа системы. Конечно же такое нельзя использовать кроме как локальных действий. Каждый раз при запуске мы получаем готовую чистую среду — в этом основной профит. У кого-то еще может возникать подобная задача.
Да, с entrypoint пробовал разные варианты, но либо systemd корректно не стартовал, либо gitlab runner не мог в контейнер подцепиться. Возможно что-то делал не правильно, поэтому было бы интересно увидеть успешный опыт других.
Года 2-3 использую ломбок только для Dto и Entity (для остального скорей не нужно). Крутая вещь. Одной аннотацией избавляешься от некоторой кучи проблем, например, достаточно просто изменить название поля или тип и ничего не надо больше делать (перегенерить сеттеры, хэшкод и пр.). Проблем ни разу не было, Dto'шки довольно краткие и красивые, на перфоманс не влияет.
Единственный минус, как выше писали, с AspectJ не работает, думаю, до сих пор не подружили. Сейчас попался такой проект и прям сильно скучаю по ломбоку, приходится руками лишние движения производить.
Соглашусь. Я то же отношусь довольно серьезно к коду и без всяких плюшек уже тяжело, т.к. с кодом провожу много времени, а дебаг это уже другая тема, она скорей по готовому коду проходит или в процессе (не буду тут ни с кем спорить).
Keil заточен под контроллеры и имеет все необходимое на борту — с этим я даже не спорю, но как IDE очень не понравилась, в каких-то моментах тривиальные вещи в нем становятся не тривиальными, но это мой опыт и мое мнение.
Думаю в Clion получится прикрутить все необходимое, либо дописать плагины, дело времени.
Без конкретики это все больше на вброс похоже. Нужно привести альтернативы, например, если пагинация антипаттерн, то как тогда лучше получать лимитированное количество записей и не убить сервак если в бд десятки миллионов записей?
Мне, кажется, что 20 лет назад еще не было intellij idea и такого количества готовых библиотек, я даже не знаю в чем тогда писали, возможно и компилировали еще каждый класс отдельно. Сейчас инструментарий решает много в производительности и исследовать нужно современные реалии, а не прошлый век. Поэтому количество строк кода вообще не показатель. И jackson может прям из файла читать, не нужно много строк велосипеда писать, врядли кто-то сейчас вручную парсит json и csv файлы. Не понимаю зачем унижать какой-то язык - нравится питон, пожалуйста, пишите, это ваше дело. В продуктовом enterprise часто задача может согласовываться неделю или две, а потом в 20 строк кода решаться за 1 час и что на питоне, сто на java время написания будет одинаковым, а вот общее время выполнения задачи от языка мало будет зависеть.
Вообще не понял для чего эта статья и для чего это нужно. Избавиться от if/else на 3-5 строк, чтобы нагородить несколько объектов, интерфейсов, обмазаться optional, а впродакшен коде там тысячи ветвлений, это в простом коде тогда будут тысячи классов пустышек и интерфейсов. Как я часто пишу - страшное в таких статьях то, что джуны сейчас пойдут такое продвигать и использовать, и вот такое нельзя допускать.
Если делать такое чисто по фану, то нужен отдельный раздел на хабре для таких приколов.
Такие высказывания, как я считаю, полная ерунда и признак джунов или начинающих мидлов, которые цепляются за конкретный язык или технологию (особенно когда только что прочитали умную книгу или статью), и пытаются убедить всех, что все остальное это плохо, а вот это вот просто грааль и нужно использовать везде. Как раз таки признак крутого инженера с богатым опытом в том, что он в первую очередь решает задачи, а во вторую разбирается с языком (выбирает наиболее подходящий под задачу и с учетом опыта и компетенций инженеров в компании), т.к. зачастую мы попадаем в проект где уже все используется до нас и нам нужно продолжить работу, и если там для меня новый язык, то я пойду разбираться с ним, а не скажу заказчику, что его выбор плохой и нужно все переписать на моем любимом языке, затратив много месяцев и денег. Так в продуктовой разработке не работает. Крутой спец будет разбираться с тем, что досталось и не искать 100 минусов в ООП.
Такие инженеры-фанаты яп опасны еще и тем, что могут появляться внутри компании в рамках одной команды специфичные языки/технологии, которые не используют другие команды и в будущем, когда проект перейдет другой команде, то начнутся большие проблемы. Очень показательны примеры поиска спецов на Scala в разных компаниях, на котором мало кто хочет писать и для рекрутеров это большая головная боль, зато себе в карме человек поставил галочку - протащил свой любимый яп.
Мораль моего комментария - такие статьи очень опасны (особенно на хабре), т.к. молодые джуны и мидлы после прочтения уверуют эту идею, и будут потом всем доказывать, что ООП это зло, а ФП это круто и удобно.
Есть вопросы по сборке java - он просто jar’ку собирает и запаковывает? Тогда это не совсем правильный способ.
Жаль, что в статье очень много не затронутых важных вопросов, хотя бы про то, можно ли делать дополнительны кастомизации и как? И будет ли в этом случае реальный профит в сравнении с обычным dockerfile’ом.
А вот про ставить везде try/catch не понял - зачем это делать если кастомный ApiException наследуется от RuntimeException и в коде никак особо не выделяется, поэтому нет необходимости его везде специально ловить. А корневой exception также описывается в exception handler с общей ошибкой и своим кодом и опять же нигде не нужно его ловить специально или помнить, если только мы не пишем что-то отличное от rest service, но такого в реальной жизни процентов 5, наверное.
Я понял. Возможно у вас действительно очень специфичный кейс когда достаточно одной ошибки. Но у нас в реальной жизни в проекте мы выбрали как раз путь вложенных классов (на котлине очень просто и круто реализуется) и в exception handler’e прописали 1 корневой ApiExeption, в котором логика запаковки в json для ответа. Теперь не нужно больше ничего туда добавлять. А в коде вместо IllegalException и прочих кидаем свои с необходимым именем. Это дает возможность в методе кидать столько разных ошибок, сколько нужно и главное, что в коде по имени исключения понятно за что оно отвечает. Ну и на скорость не сильно влияет, нет лишних аспектов на каждом вызове. А чтобы не плодить коды и исключения - организовали их в группы. Очень читабельный код получается. Ну и поверх класса с кодами добавили генерацию html доки для саппорта и тестировщиков с описанием.
Кажется, я не совсем понял возможно ли в данном подходе отдавать разные коды ошибок внутри одного метода и как? В методе, например, может быть ошибка что, юзер не найден или подписка не найдена, аккаунт заблокирован или юзер заблокирован и т.д. К сожалению, в реальном мире почти невозможно плодить микрометоды под каждую ошибку отдельно или походы в другие микросервисы могут порождать разные ошибки.
Как раз цель была в красивости и удобстве (учитывая что за это платят деньги). Второе ограничение - это некоторые специальные библиотеки для проекта, доступные для JAVA.
Банальное десктопное приложение можно писать на чем угодно - согласен, но обычно это не production-ready система, которую захотят покупать пользователи.
Да и мне как JAVA разработчику гораздо удобней использовать язык который я хорошо знаю, а REACT я тоже немного знал и с ним все было просто. Опять же, почему REACT - я купил готовый HTML + REACT шаблон и получил красивый дизайн и набор всех компонентов из коробки, которые просто блоками копирую и вставляю какие нужны. Сэкономил месяцы времени только на UI и дизайне.
Поэтому тут каждый выбирает инструменты под задачи. Достойных альтернатив нативной компиляции я пока не встречал.
Я, к сожалению, про RPS не могу сказать, т.к. профиль нагрузки это десктопное приложение с не большими вычислениями (сейчас под активной нагрузкой CPU от Java приложения не выходит за 70% от ядра) и я не измерял, но проверить под нагрузкой это хороший поинт. Будет время - проверю.
Спасибо за комментарий!
К сожалению, с IOS не приходилось работать, но интересно звучит. Читал, что есть нативные возможности самого котлина для кроссплатформенной сборки под Android и IOS.
В первом комментарии описал суть проблемы.
Прошу прощения, не наптсал, что мы разрабатываем коробочные решения, работающие на одной машине, таковы требования и речь здесь идет о сборке общего контейнера для эмуляции работы одной машины для разного рода тестов и некоторых других работ перед созданием готового образа системы. Конечно же такое нельзя использовать кроме как локальных действий. Каждый раз при запуске мы получаем готовую чистую среду — в этом основной профит. У кого-то еще может возникать подобная задача.
Да, с entrypoint пробовал разные варианты, но либо systemd корректно не стартовал, либо gitlab runner не мог в контейнер подцепиться. Возможно что-то делал не правильно, поэтому было бы интересно увидеть успешный опыт других.
Единственный минус, как выше писали, с AspectJ не работает, думаю, до сих пор не подружили. Сейчас попался такой проект и прям сильно скучаю по ломбоку, приходится руками лишние движения производить.
Keil заточен под контроллеры и имеет все необходимое на борту — с этим я даже не спорю, но как IDE очень не понравилась, в каких-то моментах тривиальные вещи в нем становятся не тривиальными, но это мой опыт и мое мнение.
Думаю в Clion получится прикрутить все необходимое, либо дописать плагины, дело времени.