Я абсолютно уверен, что человек, пишущий коммерческий код на одном из чисто ООП-шных языков более 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 получится прикрутить все необходимое, либо дописать плагины, дело времени.
У меня глаза кровоточат от исходников. Чувак, ну почитай уже книги чистый или совершенный код. Как этим пользоваться? Почему не camelCase в стилях? Твой пример $Mail->send_to(....) — тут переменная с большой буквы, а имя метода почему-то с маленькой. Пакеты иду идут с маленькой буквы, потом уякс — с большой. методы почти везде по 40+ строк, рефакторь, разделяй логику. Удали нафиг .idea из репы, зачем она там? Ты уверен в смысле фразы … fast… framework? Пишешь здесь в примере на одной строчке в одинарных кавычках, а в следующей в двойных, которые заведомо медленнее в силу специфики обработки.
Залез в первый случайный файл /core/traits/Permission/Any.php — чувак, это п**здец. Потерял зрения сразу от встроенного SQL запроса. Все, дальше не выносимо смотреть. Со скоростью уверен там будут большие проблемы.
В общем вердикт — изучай глубже язык, оптимизируй структуры, обязательна к прочтению книга «Чистый Код» Мартин Р., обязательно больше читать про архитектуру проектов, слабую связанность компонентов.. Больше практики на простых проектах, а не замахиваться на то, в чем слабое понимание.
Если так хочется сделать фрэймворк, то сделай проще, но с какой-то супер идеей, то, что очень нужно и просто реализуется, но мало где есть или вообще пока такого не сделали, в общем какой-то креатив нужен и тогда народ потянется.
И принимай во внимание местные комменты, они в 99% говорят чего реально не хватает или нужно переделать, и не нужно спорить. Если нет реальных аргументов, то переделай — будет больше пользы.
Такие высказывания, как я считаю, полная ерунда и признак джунов или начинающих мидлов, которые цепляются за конкретный язык или технологию (особенно когда только что прочитали умную книгу или статью), и пытаются убедить всех, что все остальное это плохо, а вот это вот просто грааль и нужно использовать везде. Как раз таки признак крутого инженера с богатым опытом в том, что он в первую очередь решает задачи, а во вторую разбирается с языком (выбирает наиболее подходящий под задачу и с учетом опыта и компетенций инженеров в компании), т.к. зачастую мы попадаем в проект где уже все используется до нас и нам нужно продолжить работу, и если там для меня новый язык, то я пойду разбираться с ним, а не скажу заказчику, что его выбор плохой и нужно все переписать на моем любимом языке, затратив много месяцев и денег. Так в продуктовой разработке не работает. Крутой спец будет разбираться с тем, что досталось и не искать 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 получится прикрутить все необходимое, либо дописать плагины, дело времени.
Залез в первый случайный файл /core/traits/Permission/Any.php — чувак, это п**здец. Потерял зрения сразу от встроенного SQL запроса. Все, дальше не выносимо смотреть. Со скоростью уверен там будут большие проблемы.
В общем вердикт — изучай глубже язык, оптимизируй структуры, обязательна к прочтению книга «Чистый Код» Мартин Р., обязательно больше читать про архитектуру проектов, слабую связанность компонентов.. Больше практики на простых проектах, а не замахиваться на то, в чем слабое понимание.
Если так хочется сделать фрэймворк, то сделай проще, но с какой-то супер идеей, то, что очень нужно и просто реализуется, но мало где есть или вообще пока такого не сделали, в общем какой-то креатив нужен и тогда народ потянется.
И принимай во внимание местные комменты, они в 99% говорят чего реально не хватает или нужно переделать, и не нужно спорить. Если нет реальных аргументов, то переделай — будет больше пользы.