Всем привет. Посоветуйте, пожалуйста, где можно посмотреть проекты с хорошим-правильным кодом на Java — Spring или Java EE или другое решение для веба. Нужны не примеры как сделать Х на фреймворке Y, а скорее большие проекты с архитектурой, слоями, интеграцией с разными сервисами и хранилищами и всем таким. Интересуюсь с целью повышения квалификации и кругозора. Пытался искать что-то подобное на гитхабе, но похожего ничего не обнаружил.
Автор, вы нашли в итоге эталонный проект на Спринг? :)
Мой проект лучше.
— spring-boot 2.1.1 (hibernate 5.3.7)
— java 11
— heroku ready (19 seconds start time)
— flyway
— unit + integration tests (code coverage 96%)
— travis + sonarcloud integration (1 min 36 secs full build with unit tests)
— facebook integration
— JavaScript frontend
С уважением, Валентин
Попробуй сгенерировать проект на JHipster. На данный момент это самое эталонное что есть
www.jhipster.tech
Также можно генерировать не чистый бекенд на Java, а ещё и с фронтом (Angular или React)
Java — узкоспециализированный язык для конвертации
конвертацииxml-файлов
уже аннотаций
Могу посоветовать мой проект на spring-boot.
Это heroku ready проект. Frontend тоже может быть интересным.
Перевёл его на spring-boot 2.1.1 и протестировал для java 11.
Olegek Bondar
Den Burda
Valentyn K
Anton Yakovenko
Alex Koshterek
Александр Шевченко
Valentyn K
Dmitry Bugay
public static Optional<UserGender> of(String gender) {
for (UserGender userGender : values()) {
if (userGender.gender.equals(gender)) {
return Optional.of(userGender);
}
}
return Optional.empty();
}
public static UserLevel of(int level) {
for (UserLevel userLevel : values()) {
if (userLevel.level == level) {
return userLevel;
}
}
return null;
}
Почему у вас два идентичных по семантике метода написаны по-разному? Один возвращает нулл, другой опшнал. Можно переделать первый метод, чтобы он тоже возвращал null.
Не могу сказать, что мой проект эталонный, но там достаточно и функционала, и технологий (в основном JavaEE). Плюс есть пояснения по каждому шагу, что и как делалось
Лінку на проект нам самим гуглити?
Автор книг «Разработка Java приложений», «Идеальный код» и «Основные ошибки Java программирования»
я думаю линк не совсем то что здесь понадобится
Вот здесь к каждой главе книге прикреплен архив проекта. it-simulator.com/#/article/1/3
Спасибо. Обязательно ознакомлюсь.
Враньё товарищ проект не доступен, ссылка битая, мы одесситы друг друга не обманываем)
Сорри, под Windows все норм, Сергей искренние извинения! Спасибо за ваш труд!
Spring или Java EE или другое решение для веба.
Можно нпопробовать взять grails.org . Правда это не джава, а груви, но зато «built on top of Spring Boot» и «Grails seamlessly and transparently integrates and interoperates with Java, the JVM, and existing Java EE containers.»
Нужны не примеры как сделать Х на фреймворке Y, а скорее большие проекты с архитектурой, слоями, интеграцией с разными сервисами и хранилищами и всем таким.
Обычно на офф. сайтах фреймворков, библиотек и т.д. пишут, какие известные компании и проекты этот фреймворк юзают — ну и найти где-нить исходники одного из таких проектов.
Спасибо за ответ. Да, я пытался идти этим путем, но быстро ничего толкового найти не удалось. Продолжу поиск.
Поищите что то в сторону java-ddd к примеру что ли
Спасибо, попытаюсь что-то найти в этом направлении.
такого нет
правильный код: java.lang, JCC
чтобы понять что нужно на спринге: Spring sources + кишки (www.youtube.com/watch?v=BmBr5diz8WA)
все остальные эталоны определяются: Accepted Conventions
правильный код: java.lang
Хаха.
Особливо всякі намбери з сотнями статичних методів і тисячами рядків коду.
я не говорил что он «хороший» ;) он официальный, соответственно «правильный» :)
Ага, сорці андроїд сдк теж «правильні»? ))) Вони ж «офіційні».
Для джавы — нет %)
А что в них не так? Даже нет ни одного .java файла, в котором было больше, чем 2^16 строчек кода.
хорошим-правильным кодом на Java — Spring или Java EE
Ліл. Взаємовиключні параграфи тут бачу я.
В чем именно? Впрочем, если вас смущает тот или иной фреймворк — то можно расширить вопрос, предложите, пожалуйста большой проект с хорошим кодом на Java. Если не подходит язык, извините — пока что мне интересна именно Java.
В спринге, дальше хелло-ворлд присутствуют костыли в экспонентциальном количестве. Естественно такой код «правильным» быть не может.
дальше хелло-ворлд присутствуют костыли в экспонентциальном количестве
У кого как. У нас — нет. Если у вас костыль-драйвен-девелопмент, то увы, это не вина спринга.
Если у кого-то идеальный код — он либо врет, либо идеальный разработчик. А идеальных разработчиков я не встречал.
Чего стоит один только @transactional
А что с ним не так?
Если у кого-то идеальный код — он либо врет, либо идеальный разработчик.
Найдите в моем посте слово, однокренное со словом «идеал».
Не нашли? Так на что вы тогда отвечаете? Еще раз, если у вас в коде костыли — поздравляю, вы пишите костыли. Но не вините в этом спринг.
Чего стоит один только @transactional
Походу вы считаете что @Transactional — верх магии, костылизма и т.д, так что ли? :)
нет, я имел ввиду что даже с такой популярной аннотацией проблем овер9000. А вот передергивать — не стоит
С ней нет проблем у тех, кто знает как оно работает. У нас вот например нет. В смысле вообще нет.
А так да, если знать спринг по видосикам и статейкам-пятиминуткам «how to ... with spring», то конечно, проблемы будут со всем вообще.
От того что я знаю как оно работает, проблем с ней меньше не становится. Костылей, когда приходится дописывать свои модули, тоже хватает. Говорю же, перестаньте передергивать.
От того что я знаю как оно работает, проблем с ней меньше не становится.
Значит, плохо знаете. Иначе бы не было проблем. Не вините инструмент в нехватке своей экспертизы по пользованию им, или то что вы, пользуясь им, хотите от него странного.
Не надо передергивать, а путать курицу с яйцом — тем более. Проблема что в ней много чего нет из того что должно быть, кастомные решения писать для одного проекта — изнурительно. Если на том же спринг-дата это не так заметно, то на большинстве «младших» библиотек впору самому джавадок писать.
И даже если я знаю как оно будет работать, как оно «должно» работать от этого не меняется. Многие вещи в нем есть по сути компромис. Это не я хочу странного, это спринг по странному сделал то что от него ожидалось.
если я знаю как оно будет работать, как оно «должно» работать от этого не меняется. Многие вещи в нем есть по сути компромис. Это не я хочу странного, это спринг по странному сделал то что от него ожидалось.
Т.е. все сводится к тому, что спринг реализован не так, как лично вам этого хочется? И поэтому спринг — костыль?
Не слишком ли большое чсв, чтобы объявлять свое имхо более приоритетным чем мнения огромного количества разработчиков центрального фреймворка джава-мира?
Ссылка на жиру, и?
Но я походу попал в точку.
Я все должен объяснять что-ли?
Допустим что разработчик А хочет фичу Б. Он ее находит, и думает что она будет работать как фича Б в его представлении. Но она работает как фича В. Он идет на джиру, чтобы узнать: почему? Или пофиксите или объясните. И ждет. Долго ждет.
Просто пройдитесь по тикетам, посмотрите время ожидания некоторых фич и сколько людей их поддерживает
т.е. код без костылей != не идеальный? что же вы там творите тогда?
код без костылей != не идеальный
Я чот не въехал в это булево выражение. Слишком много негаций.
Но если шо, то если приложение без костылей не означает, что код идеален.
окей, перефразирую идеальный в «Читабельный, поддерживаемый, выолненый по стандартам и лучшим практикам». Тогда, если не нужно писать костыли, что мешает писать этот самый «идеальный» код?
не означает. Вот только если не пишите костылей, а код не идеальный, то что выходит?
что мешает писать этот самый «идеальный» код?
Человеческий фактор. Человеческие ошибки. Нехватка экспертизы для наилучшего решения поставленной задачи. Нехватка времени на выработку идеальной экспертизы по теме Х, которая нужна для решения проблемы Y. Неспособность человека спрогнозировать все юзкейсы, удобные юзеру и неспособность спрогнозировать весь спектр «защиты от дурака». Связанные с этим возникающие проблемы.
При всем этом — код может быть читабельный, поддерживаемый, расширяемый, сравнительно стойкий к мисюзу апи, покрытый осознанными тестами.
При всем этом в нем можно не допускать наличия костылей, если не заниматься хуяк-хуяк-продакшном.
Тут проблема понятий, и что вкладывается в слово костыль.
Костыль — это исправление последствий проблемы, или попытка прикрыть последствия проблемы без исправления самой проблемы.
Или же например попытка создать новый функционал противоестественной комбинацией или неествественным использованием старого. Которая, в свою очередь приводит к первому абзацу.
Вы сейчас сами себе противоречите:
Нехватка экспертизы для наилучшего решения поставленной задачи
А если учесть что любое решение, которое не является лучшим, имеет проблемы (иначе бы оно было лучшим)
Костыль — это исправление последствий проблемы
т.е. проблемы вы не исправляете?
Вы сейчас сами себе противоречите:
Нет
А если учесть что любое решение, которое не является лучшим, имеет проблемы
Масштаб проблем разный. Есть проблемы разного уровня:
1) «работает нормально, поддерживать можно, но не слишком красиво реализовано, есть более елегантный способ»
2) «работать будет, но расширить мы это не сможем никак»
3) «ложит сервак нахер если дернуть ендпойнт».
1 вариант не является костылем, даже если гуру-рок-стар может написать красивее. 2 — является.
т.е. проблемы вы не исправляете?
Читайте внимательнее и до конца. Костыль — это когда врач лечит симпотмы вместо того чтобы лечить болезнь. Визуально пациент румян и полон енергии, но по сути скоро помрет.
ненене, «или» имеет очень древнюю спецификацию. одно либо другое либо оба.
Масштаб проблем разный. Есть проблемы разного уровня
1 вариант не является костылем, даже если гуру-рок-стар может написать красивее.
Так все-таки есть проблемы или нет? Или если проблема есть, а последствий нет — и так сойдет?
Я просто не могу понять чего вы добиваетесь. Хотите убедить меня что код без проблем, раз костылей нет? Или что есть проблемы. но костылями решать не будете?
Я отвечаю на ваш вопрос про то, как это когда код без костылей, но при этом я не назову его идеальным. Я разделяю понятия «неидеальность» и «костыль», а ваши вопросы сводятся к тому, что вы читаете мои ответы по диагонали. Тогда зачем переспрашивать?
Ну, ну, давайте вгадаю що у вас:
пакет entities для дбайливо змпаплених pojo з навішаними зверху jpa-анотаціями
пакет repositories з jpa-інтерфейсами для тих пожо що вище
пакет services де у вас в імперативно-процідурному порядку побудована вся бізнес-логіка. тут самий сок, сама краса, сама суть ентерпрайз кодінгу!!!
пакет controllers де у вас сидять @RestController в які інжектяться сервіси
пакет requests чи шось типу такого де у вас сидять pojo для типизації і конвертації jsonчиків що приходять та виходять з контролерів
в корені клас PerfectlyLayeredSpringBootApplication з наступними анотаціями:
@SpringBootApplication
@EnableDiscoveryClient
@EnableScheduling
@EnableAsync
@EnableConfigurationProperties
@PropertySource("errors/errorMapping.properties")
@EnableAutoConfiguration
@EnableFeignClients("ua.dou.goodapp")
@EnableRetry
@ComponentScan({"ua.dou.goodapp«, «ua.dou.common»})
Красивий код, грамотно розділений на шари, просто еталон!
+100 даже +200 — примерно такие проекты на спринге я встречал в основном на работе. Я понимаю и в чем-то согласен с вашим поинтом про спринг, но могли бы вы в таком случае привести пример проекта с хорошим кодом на джаве, который бы решал какую-то ентерпрайз задачу и не был бы просто пачкой круд контроллеров?
решал какую-то ентерпрайз задачу и не был бы просто пачкой круд контроллеров
бро, сорян, але весь ентерпрайз про круди і про конвертацію одного xml в інший.
могли бы вы в таком случае привести пример проекта с хорошим кодом на джаве
хороші проекти отут можете подивитися: www.yegor256.com/award.html
хороші проекти отут можете подивитися: www.yegor256.com/award.html
Каждому классу в этих проектах можно доверять. У каждого класса есть душа.
Ентерпрайзным разработчикам, использующим спринг не понять, что такое душа у обьекта, что такое настоящее ООП.
Ентерпрайзным разработчикам, использующим спринг не понять, что такое душа у обьекта, что такое настоящее ООП.
Я помітив що люди або розуміють концепцію EO або не розуміють. Більшість — не розуміють, хоч як ти їм не аргументуй. Не знаю, чому так.
Обознался. Возможно вы и не пишете мутабельных классов с геттерами и сеттерами.
я просто оставлю это здесь:
www.yegor256.com/...oriented-programming.html
Можешь раскрыть мысль. Егор говорит, что у (ООП есть проблемы, но если бы люди поняли концепцию души обьекта, то некоторые проблемы ООП можно было бы побороть), или я чего-то не понял?
ООП не идеал, а лишь инструмент. Когда он подходит для одних областей, он попросту не нужен в других. Если его пытаются всунуть везде где могут — получается большая проблема.
Ок. тогда в чем проблема?
ООП (В понимании Егора) не подходит для энтерпрайза. Не подходит для тех задач, на который принимается осознанное решение использовать джаву из-за библиотек написанных на джаве / с первокласными джава-апи.
ООП не идеал, а лишь инструмент.
Но это же аргуммент, который используют оппоненты Егора, когда говорят, что для своих задач они будут использовать иснтрументы, которые не дружат с ООП, вместо того, чтобы впустить в свой код душу.
Нет никакой проблемы, если не юзать ООП для всего подряд
А душа в коде совместима с кровавостью ентерпрайза? Или если впустить душу в кровавый код, получим АдЪ и Изгаиль?
который бы решал какую-то ентерпрайз задачу и не был бы просто пачкой круд контроллеров?
Является ли ваше приложение крудом, или нет, или насколько сложная модель вырастает потом из первой версии круда — решает требуемая заказчиком бизнес логика (а также ваши решения, как это логику реализовать), а не инструменты, которые вы используете. Спринг и контроллеры тут не при чем.
Если на работе вы работали с простыми крудами на спринге и контроллерах, это не значит, что спринг и контроллеры пригодны только для простых крудов, и что 100% проектов, которые используют спринг, являются элементарными крудами.
Первое. Угадали примерно половину :) Еще части вообще не назвали, но неважно.
Второе. И что? Где тут костыли? Если вы сейчас углубитесь в рассуждения о «спринг неправильное ооп», «в ооп нет души» и будете давать ссылки на Егора, то все заранее понятно :)
Тут надо сказать, что частично (но лишь частично), я согласен с закидами в адрес спринга, что парадигма pojo+repository+service, которую диктует спринг, не является идеалом красоты и дизайна.
Однако это лишь одна из крайностей.Те концепции, которые толкает Егор — это другая крайность.
В них, как и в любых противоположностях, есть минусы. Оптимум — гдето посередине, и мы его стараемся придерживаться.
Где тут костыли?
Для мене тут костилі в процідурках які оперують мішками з даними.
Якщо вам норм писати на трішки проапгрейдженому Паскалі, то все зрозуміло заздалегідь.
В целом ясно.
Вопрос чисто из праздного любопытства — а как надо-то? :)
Спринг и jpa выкинули, не труЪ, данными больше не оперируем, процідурки не пишем, а что делать-то будем? new App().begin(new BusinessProcess().process(new ClientRequest().calculate(new Plus().applyTo(new Int(1), new Int(2)))))))))))); ? :) Чистое и красивое ооп. Без спринга и процідурщіни.
Чистое и красивое ооп
Ви там нічого в конструктори не передаєте, це не ооп. ну і ясно, не всі можуть в Єгоровщину сходу.
как надо-то?
Я схиляюсь що наразі найкраще «як надо-то» це писати на чисто ФП мові в ФП стилі.
Щодо як надо ООП, Єгор готує третю частину книги де буде багато практичних прикладів.
Java занадто verbosive виходить для написання EO-коду, і виглядає воно не дуже.
Ви там нічого в конструктори не передаєте
Пфф, там можно что угодно куда угодно перекинуть. Суть комичности примера не изменится.
не всі можуть в Єгоровщину сходу.
як надо-то" це писати на чисто ФП мові в ФП стилі
Ммм, яснопонятно :)
Я схиляюсь що наразі найкраще «як надо-то» це писати на чисто ФП мові в ФП стилі.
Лучший код, написанный на Java — это код не написанный на java?
Звучит хорошо. Но отвечает на другой вопрос.
Есть инструмент J, который походит для решения задач A,B,C,D, а принимяется для задач A, B, C, D, E, F
И есть Егор, который предлагает решать задачи F используя инструмент J особым способом, а не так, как делает большинство. А так-же задачи A, B, C, D этим же способом.
И есть Włodzimierz, который говорит, что вместо J лучше бы использовать инструменты S, H, R, которые действительно подходят для задач E, F, С и кроме того еще и подходят для A, B, С лучше, чем то, что предлагает Егор.
Но тем не менее Włodzimierz рекомендует прислушатся к рекомендациям Егора, и не слушать тех, кто применяет J для задач A, B, C, D
Лучший код, написанный на Java — это код не написанный на java?
...а лучшее ООП — это отсутствие ООП + ФП! О как!
ей богу, странно слышать подобные претензии от чела, который индекс цикла пытается мутировать
Дивно чути подібні претензії від чєла, який би мав розуміти, що задачі на реалізацію алгоритмів вирішуються чистими процідурками без всіляких об’єктів.
это не имеет никакого отношения к объектам и мутации переменной цикла, и уж тем более фанат ФП должен относиться к мутабельным переменным как к фу-фу-фу
Spring как эталонный проект рекомендует Pet Clinic. projects.spring.io/spring-petclinic (github.com/...projects/spring-petclinic)
Спасибо за совет, однако, это не то что я ищу. Я уже видел этот проект и когда-то начинал изучение спринга именно с ним. К сожалению, он слишком маленький и состоит из крудов и не более. Мне же интересны проекты побольше. Из них я хотел бы почерпнуть знания о правильном выстраивании архитектуры на схожих проектах, о том как не писать монстров.
«Я ждал этот комментарий» ©
есть мнение что джава это такой набор костылей, что эталонного просто нет, но есть много удобных вариантов как писать определенные куски, из которых надо налепить своего монстра для страданий, поторый не будет уже удобным со всех сторон
Не обязательно эталонный в понимании идеальный) Хотя бы просто хороший проект с архитектурой чуть больше чем просто MVC.
Мне вот интересно, я признаю, да я начинающий разработчик, но если взять информацию из разных источников то можно сделать вывод, что любой язык является набором костылей который превращается, как вы сказали в «монстра для страданий», если проект выходит за рамки: Hello word!
В той или иной мере да, как по мне у джавы в этом топе 2е место
у кого топ-1?)
У кого же первое?)
А как по мне топ1 это дотнет. топ2 это джс.
С дотнентом не так дотнет.
понятненько... «хейчу потому что могу»
как по мне у джавы в этом топе 2е место
«хейчу потому что могу»
никого не интересовало почему я так считаю, к тому же я в других темах много раз говорил
Меня, например, тоже не интересует, почему вы так считаете. Достаточно того, что я так не считаю, а значит ваше мнение предвзятое. Причем, учитывая традиции ит, скорее всего просто потому, что вы
.NET Architect
и было бы гораздо удивительнее, если бы вы хорошо отзывались о джаве :)
в противовес скажу, что считаю что плюсы лучше дотнета
А как же PHP?) Я думал он в топах по костылям будет)
по-моему там все в порядке относительно джавы, то что на нем плохо пишут это совершенно другой вопрос, сам язык дает возможность пистаь хорошо и не страдать, насколько мне известно
Да, забыл. Скажем так, дотнет и пыха дерутся вместе на пъедестале лидерства :)
а типа .net не те же яйца в профиль
если сравнивать по синтаксису, то да, а вот если сравнивать используемые подходы, то пересечений толком и не будет
Sergiy Morenets
Włodzimierz Rożkow
Андрій Плотніков
Sergiy Morenets
S Romankov
minodvesP Vasya
Oleksii Samokhvalov
Андрій Плотніков
Platan
Włodzimierz Rożkow
Дмитро Сафронов
Alex Koshterek
Mykola Oliinyk
Konstantin Strukov
Valentin Nechayev
Vadim Kopanev
Valerii Khmelnytskyi
Vadim Kopanev
Oleh Onufryk
Andrey Komisarenko
minodvesP Vasya
103 коментарі
Додати коментар Підписатись на коментаріВідписатись від коментарів