Мой предыдущий пост возымел определенный эффект – несколько человек посчитали его очень мотивирующим и попросили меня дать некоторые советы и рекомендации, с чего же начать карьеру разработчика. Очевидно, вопрос слишком широкий и не имеет ответа как такового, поэтому я поставлю его более узко: что должен знать молодой java-разработчик, пишущий back-end?
Этот пост не является курсом молодого бойца, а является лишь:
- Моей попыткой выбрать основные направления, в которых должен ориентироваться каждый начинающий java back-end разработчик.
- Небольшим собранием материалов к изучению.
- Описанием тестового проекта, который разработчик должен суметь реализовать с использованием указанных инструментов.
Цель:
- Осветить список основных инструментов экосистемы языка, которыми необходимо уметь пользоваться и понимать на базовом уровне. Я не ставлю целью дать глубокое понимание инструментов, так как это самое понимание можно приобрести лишь с опытом.
Как я уже говорил, я буду оперировать терминами экосистемы Java, хотя в целом это легко можно спроецировать на любую другую платформу.
Итак, есть человек, понимающий ООП и прочитавший хотя бы одну стоящую книгу по языку от авторитетного автора. Человека в дальнейшем будем называть “падаван”, и если падаван не читал книг – все же стоит это сделать. Это необходимо для того, чтобы понимать возможности языка и его основных библиотек, но закапываться тоже не стоит – для начала одной хорошей книги будет достаточно. Фанатичное чтение без практики никаких особых плюсов не дает, особенно на начальных порах.
Значит, что мы пока что имеем:
- Падаван – 1 единица.
- Имеется понимание ООП.
- Базовое понимание возможностей языка и знание основных его библиотек тоже в наличии.
Как можно применить имеющиеся пока знания? Никак. Для этого нужно погружаться в экосистему платформы. Для Java, по моему мнению, необходимо понимание следующих инструментов:
Collections Framework. Вообще говоря, это Core Java, то есть не часть экосистемы как таковой. Ориентироваться в структурах данных – обязательно. Необходимо четко понимать разницу между LinkedList и ArrayList. А также понимать, что такое Set и Map (а еще помнить, что Map – это не Collection). Хорошая статья про HashMap, например. Я бы даже рекомендовал еще посмотреть сюда.
Иерархия исключений: тут
Иерархию классов кстати тоже неплохо представлять в общих чертах. Хотя бы помнить, что все классы неявно наследуют от Object.
Spring. Это фреймворк, который сильно упрощает жизнь. Фреймворк этот слишком большой, поэтому для начала достаточно просто понимать, зачем он нужен.
Знать, как расшифровывается ORM и для чего это нужно. Я бы дал такую краткую и сильно упрощенную формулировку: ORM (ладно, Object-Relational Mapping) – это такая штука, которая позволяет преобразовывать записи (строки) базы данных в объекты языка. С этими объектами затем можно работать так же, как и с любыми другими – проверять или менять их состояние, вызывая те или иные методы. Соответственно, все изменения объекта отразятся в БД.
JDBC. Это то, что позволяет довольно сложно и непонятно работать с базой данных. Но знать полезно. Сюда же и отнесу базовое знание SQL.
Maven. Определенно необходим, так как эта штука помогает собрать проект из кусочков в один исполняемый файл (грубо говоря). Есть аналоги: Gradle, Ant. Последний, на мой взгляд, довольно сложен для начала, да и популярность его на сегодня довольно мала.
HTML на базовом уровне, то есть уметь красиво верстать ни к чему для начала.
- JUnit / TestNG, в общем – юнит-тестирование. Я не буду делать на этом акцент, а также не буду говорить про TDD или BDD – итак уже слишком много материалов для начала. Я бы даже сказал, что на начальных порах скорее более важно само понимание важности юнит-тестирования, а не непосредственно умение писать тесты.
Если я упустил какие-либо важные моменты, прошу меня поправить и дополнить.
Итак, в чем заключается суть тестового проекта: я предлагаю падавану сделать простейшую блог-платформу без регистрации и без красивых форм на bootstrap. Пусть это будет голый уродливый html без какой-либо динамики, а главная форма имеет лишь:
Поле ввода. Просто вбейте туда слова “Hello World”.
Кнопку “создать запись”. Нажимаете на нее, и слова “Hello World” уходят приложению на обработку, сохраняются в БД, а затем появляется на страничке. Динамики не нужно, пусть запись появится только после перезагрузки страницы.
- Список созданных ранее записей. Конечно, они будут подтягиваться из БД и отображаться на форме при каждом новом запуске приложения. Данные не будут теряться после завершения работы приложения.
Все! Это правда все. Это очень просто, но если вы только-только начинаете, то вам придется ознакомиться со множеством моментов.
Вроде кто-то когда-то говорил:
Java – это инструмент для преобразования больших xml-файлов в stack-трейсы.
В этом есть доля правды, поэтому я рекомендую сразу же избавиться от всей этой xml-конфигурации, используя Spring Boot – он оперирует аннотациями.
Я уже говорил, что это не курс молодого бойца, а лишь мои рассуждения. Так что ниже я дам лишь рекомендации о порядке выполнения этого проекта:
- Начать рекомендую с установки Java на компьютер, как ни странно. JDK8 можно скачать здесь;
- Поставить Maven;
- Создать первый Spring-boot проект. Здесь описано лишь как создать “Hello, World!”;
- Поставить БД (например, postgre, h2 или mysql);
- Создать классы моделей. Точнее, один простейший класс;
- Реализовать CRUD (create-read-update-delete, операции с данными);
- Создать простейшую jsp-форму;
- Связать форму с контроллером.
По поводу пунктов 5-8 можно почитать следующее:
- Здесь есть все, но вместо добавления простейших сообщений автор предлагает добавлять сотрудников.
- Эта статья больше ориентирована на создание API-приложения, так что все понимать в ней ни к чему. Но прочитать ее тоже будет весьма недурно.
И это все! Я верю, если падаван освоит указанные моменты и сумеет не просто склепать простейшую блог-платформу, но и поймет, для чего он делал каждое из действий, то этого будет достаточно для первого трудоустройства на позицию junior java-developer. Различные рассуждения и дополнения категорически приветствуются.
Комментарии (157)
avost
29.09.2016 03:57+2>Все задачи spring замечательно решаются на уровне самого JVM. Внешние тулзы не нужны
Конечно решаются. И даже хелло-ворлда из статьи на голом JVM всё ещё можно написать за время не очень сильно бОльшее, чем на спринге. Только это будет никому не нужный хелло-ворлд. Поскольку усилия по его расширению будут расти экспоненциально. Мало для кого это приемлимо.
Saffron
29.09.2016 04:40-1Экспоненциально они будут расти, только если вы не умеете в ООП программирование и декомпозицию. Вы ещё расскажите, что без AspectJ жизни нет.
avost
29.09.2016 06:39К чему слова? Напишите, пожалуйста, ваш вариант хелло-ворлда из статьи. Потом дополните его, ну, скажем, аутентификацией. Можно наколенной. А потом oauth…
Но сначала, хотя бы, этот хелло-ворд. Что-то мне подсказывает…Saffron
29.09.2016 06:53Посмотрел на hellow world. За аннотациями скрыты реальные библиотеки. Мне пока недосуг разбираться в спринге, какие именно библиотеки вызывает чёрная магия. Но те же самые библиотеки можно вызвать без аннотаций. Просто композицией.
avost
29.09.2016 08:12Какой ещё спринг? Вы на голой JVM обещали.
А в аннотациях нет магии, это просто сахар. Можно и явно всё дёргать, но зачем?
AndreyRubankov
29.09.2016 09:18+2Стоит отметить, что есть множество задач в java мире, где спринг избыточен. Если нужен IoC — Guice, если нужен REST — JAX-RS (Jersey), и первый и второй позволит создать легкое быстрое приложение, да гибкость будет не та, но иногда Спринговая гибкость не нужна.
Спринг — это замена «страшному» JavaEE с его ejb. У него много преимуществ, но так же много и недостатков. Один из основных недостатков в том, что это как наркотик, связавшись однажды со спрингом (в юном возрасте) на него подсаживаются и потом его пытаются затянуть в каждую щель, даже там где он не нужен. (Не стал лишний раз говорить про оверинженириг, вес, производительность и сложность в отладке)
tmn4jq
29.09.2016 09:33Вот если Вы перефразировали выражение «все задачи решаются на уровне JVM, внешние тулзы ни к чему», то в такой формулировке это звучит нормально :) Для каждой задачи свой инструмент.
taujavarob
29.09.2016 19:57+1Обычно проект разрастается и многие «ненужные фичи» Спринга становятся очень даже кстати.
Спринг большой — потому что он пытается сохранить совместимость. — Одни практики сменяются другими, новыми, но при этом можно использовать и старые практики Спринга (по разным причинам — не переписывать же УЖЕ написанного и успешно функционирующего годами кода).
AndreyRubankov
30.09.2016 11:40> Обычно проект разрастается и многие «ненужные фичи» Спринга становятся очень даже кстати.
Одна из хороших практик «Тебе это не потребуется!» (YAGNI). Тянуть что-то большое, только ради того, что может быть понадобится — не всегда хорошая идея. Будет нужно добавить — добавим.
Замечательная особенность кода, который пишется без использования спринга в том, что этот код максимально портируемый. Этот код потом будет легче перенести на спринг или на любой другой фреймворк.
В случае со спрингом, либо пишем чистый и красивый код под спринг, либо тратим много усилий на то, чтобы писать под спринг без завязки на спринг (и рано или поздно завязка на спринг все равно проникнет в бизнес логику). В результате этот код будет очень тяжело вынести за пределы спринга (трудно портировать куда-либо еще).tmn4jq
30.09.2016 12:03Не путайте принцип YAGNI с грамотной архитектурой приложения. Всегда нужно исходить из целей, а не из принципов.
taujavarob
30.09.2016 12:26>Всегда нужно исходить из целей, а не из принципов.
Вот! Когда известно(!) (или предугадано) что будет грузовик, то можно уже с самого начала поставить кузов грузовика, хотя вначале он и будет возить не более 200 кг.
Есть многие задачи — когда в общем-то ясно — что код будет расти и расти.
taujavarob
30.09.2016 12:32>В результате этот код будет очень тяжело вынести за пределы спринга (трудно портировать куда-либо еще).
Верно. Об этой «опасности» сказано в любой книги по Спрингу.
Но, хотя статистики общей у меня нет, но из своего опыта — ни один из проектов так и не «соскочил» со Спринга. Даже потуги не было куда-то с него «спрыгнуть». Проекты развиваются годами! Код растёт постоянно, обрастая всё новыми и новыми фичами и «хотелками заказчика». Фронтенд (фреймворки) меняется, но Спринг на бакенде стоит на смерть — незыблемо! ;-)
AndreyRubankov
30.09.2016 16:46> из своего опыта — ни один из проектов так и не «соскочил» со Спринга. Даже потуги не было куда-то с него «спрыгнуть».
Очевидно, это связано с тем, что вы участвуете в проектах, где Спринг всегда выбирают за основу.
У меня другой опыт, у меня практически все проекты без spring и его туда даже добавлять глупо.taujavarob
30.09.2016 18:28>Очевидно, это связано с тем, что вы участвуете в проектах, где Спринг всегда выбирают за основу. У меня другой опыт, у меня практически все проекты без spring и его туда даже добавлять глупо.
У меня были «обычные веб проекты» из серии — запрос(броузер) — контроллер(сервер) — поиск в базе(СУБД) — выдача клиенту JSP страницы. — Что в них может куда-то «спрыгивать со Спринга»? — я даже не придумаю.
tmn4jq
29.09.2016 09:06+2Вы по своему опыту говорите? Как по мне – использовать спринг это не цель, ведь цель – создать хороший продукт. А спринг как раз помогает упростить его создание и поддержку.
Взять например периодические задачи – в спринге я бы просто повесил cron-аннотацию на метод, а без него пришлось бы либо писать ScheduledExecutorService, либо подрубать quartz или другую библиотеку. Но это еще ладно.
А еще спринг помогает с юнит-тестами, когда вам просто нужно создать mock-бин и заинжектить его в компонент. Опять же, DI можно сделать и без спринга, но зачем изобретать велосипед?
Но мой любимый пример – это spring-data. Очень уж мне понравилась эта convention-over-configuration модель. Вам достаточно лишь создать интерфейс для базового CRUD, а более сложные операции, например фильтр, темплейты умеют создавать лишь по имени метода. Таким образом вы убираете шаблонный код.
Про MVC и RestController тоже грех не упомянуть – очень читабельные API-приложения получаются.
Так что еще раз – спринг это не цель, но он очень упрощает жизнь. Важно, чтобы код не просто работал, а был читабельным и легко расширяемым/модифицируемым.AndreyRubankov
29.09.2016 12:09Да, все эти «магические» свойства spring data (spring boot) очень заманчиво выглядят и позволяют максимально быстро сделать рабочий проект. Но играть с магией опасно.
Вот написал интерфейс с методом findById и в проекте никто его не имплементит и код как-то работает. А потом появляется бага и черт его знает, где откуда она вылезла (на практике не было, но скептицизм остается).
Но что хуже всего в спринге — подход к конфигурации. Когда все настраивается через xml — пойди разбери что откуда загрузилось и кто кого перетер. Через java конфиги в целом лучше, но не на много, все так же остается проблема «кто кого наследует и перетирает».
Отличный подход к конфигурированию можно увидеть у Guice, у него строго определен список конфигов, порядок их загрузки инжекта имплементаций. Без магии.
ps: этот коммент не относится к ветке обсуждения, а лишь к предыдущему комментарию.
pps: Spring хорош, но в нем сильно много магии.
gkislin
29.09.2016 04:39+1На мой взгляд не стоит начинат освоение Spring со spring-boot. Как он работает не сразу разберет даже хорошо знакомый со Spring разрабтчик. Т.е работать с ним, как черным ящиком какое-то время можно, но потом все равно придется spring-context/mvc/orm осваивать.
tmn4jq
29.09.2016 09:08Спасибо. А если сделать аналогичное задание, но на старом добром Spring MVC с web.xml – будет лучше для начала, как считаете?
avost
29.09.2016 10:08СтОит, стОит! Я с веб-разработки соскочил ещё до появления спринга, а теперь она впезапно ко мне вернулась и я как раз на этом пороге. Попробовал оба варианта.
Стандарнтный с плотным изучением спринга — для того, чтобы хотя бы сконфигурировать каркас ещё до написания хотя бы строчки полезного кода нужно месяц читать книги и доки.
С бутом — код пишется сразу, а магия постигается в процессе экспериментов. Конечно, придётся всю магию раскапывать как она на самом деле работает, никто и не обещал иного, но это и проще и быстрее!gkislin
29.09.2016 13:50Проще и быстрее- да, никто не спорит. Но сильно сомневаюсь, что вы поймете как устроен Spring, зная только boot. Еще security забыл в список добавить. Вот еще отправная точка для создания собственного проекта: https://github.com/spring-projects/spring-petclinic
gkislin
29.09.2016 14:04Добавка- в бранчах spring-petclinic есть версии springboot, angularjs, javaconfig и security
avost
29.09.2016 14:28>Но сильно сомневаюсь, что вы поймете как устроен Spring, зная только boot.
Почему? Понимать всё-равно надо, если не ограничивать себя их тестовыми примерами. boot избавляет от геморроя с конфигурацией, позволяя сконцентрироваться на том как всё работает. А когда дефолтная конфигурация перестанет удовлетворять, как раз можно к ней вернуться уже зная зачем туда лезть вообще и какие будут последствия. Постепенно, шаг за шагом.
«Стандартный» путь, по крайней мере, в тех книжках, что мне попадались — это можно поконфигурить так, а можно сяк, а можно разэдак, а можно и так и сяк, — и так пол-книжки. А до вопроса «а зачем это вообще конфигурить», читатель три раза засыпает. Может книжки плохие были…
>Вот еще отправная точка для создания собственного проекта: https://github.com/spring-projects/spring-petclinic
Угу. Я посмотрел на него незамутнёным взором, ужаснулся и больше не возвращался. Сорок бочек арестантов и все скопом :).
vlivyur
29.09.2016 09:33+3А, так это про web-разработчика на java…
tmn4jq
29.09.2016 09:38+2Если это сарказм (я плохо умею его определять), то что вас смущает? В примерах используются jsp, которые проще всего использовать для начала. Тот факт, что вы будете писать контроллеры, не делает вас «веб-разработчиком на джава», так? А за контроллерами скрывается много серверной логики.
TOBBOT
29.09.2016 09:41Есть множество рабочих мест, где вышеупомянтый Spring может и не пригодиться вовсе.
tmn4jq
29.09.2016 10:00+1А как бы Вы рекомендовали реализовать тестовый проект, имею в виду с каким стеком? Или, может быть, другой проект? Я согласен с тем, что спринг не везде и не всегда необходимо знать, и хочу услышать различные мнения по поводу проекта.
TOBBOT
29.09.2016 10:58Так в статье тестовый проект привязан к стеку мин. знаний. Вдруг, предприятие занимается созданием десктопных приложений для пользователей, тогда и опыт работы с GUI может оказаться более полезным.
Для решения задачи можно, например, воспользоваться легковесным спарком (sparkjava.com). Который вовсе не обязательно знать до постановки задачи, т.к. можно освоить в кратчайшие сроки за счет своей простоты.
gkislin
29.09.2016 13:51http://zeroturnaround.com/rebellabs/java-tools-and-technologies-landscape-2016/
Mugik
29.09.2016 10:31HTML на базовом уровне, то есть уметь красиво верстать ни к чему для начала.
До сих пор рад, что так и не пошел в java разработку, так и вижу как после высшего образования и изучения тонн спецификаций, парадигм и фреймворков сидишь и верстаешь красивые кнопочки и чекбоксы. А ведь в суровых реалиях будешь 20% рабочего времени копаться в гавнокоде-лапше от предыдущих девелоперов и 80% времени воевать с css.taujavarob
29.09.2016 20:03>До сих пор рад, что так и не пошел в java разработку
Зря не пошли. Если бы пошли то мы не увидели бы этого вашего текста. ;-)
AlexPu
29.09.2016 11:10>>используя Spring Boot – он оперирует аннотациями.
Почему только Spring Boot? Необязательно использовать Spring Boot чтобы использовать Spring аннотации… Более того — это вообще никак не связанные вещи — Spring Boot это не «та штука, которая позволяет заменить xml аннотациями» а «так штука которая автоматически (или полуавтоматически, если вам этого по какой-то причине захочется) создает конфигурацию Spring приложения» — как именно создает это предмет углубленного изучения Spring Boot.
Что-же касается code based Spring configuration (именно так оно обычно называется), то оное доступно начиная с четвертой версии фреймворка (точную версию я не помню, но частичная поддержка была доступна в каких — то поздних третих версиях)
tmn4jq
29.09.2016 11:29А автоматическая конфигурация Spring приложения – это не замена ручной xml-конфигурации?
Боюсь, если бы я ваш коммент озвучил где-то в статье, то она бы получилась уже более запутанной. Не думаю, что новичку нужно так глубоко вникать с самого началаAlexPu
29.09.2016 12:29Из текста статьи следует, что Spring Boot следует использовать для того, чтобы заменить XML аннотациями. Это утверждение неверно — вы бодете использовать Spring аннотации и без использования Spring Boot
Из вашего комментария следует, что вы плохо себе педставляете что такое Spring вообще и Spring Boot в частности.
Что касается того, чтего вы боитесь, то здесь рецепт простой — бояться не нужно, нужно во первых изучить вопрос чуть глубже перед тем как его описывать. В данном случае, вам не нужно было поминать конфигурации вообще (ибо выполняются они одинаково с использованием Spring Boot или без оного), а Spring Boot рекомендовать к использованию не потому, что он позволяет использовать аннотации, а потому, что он позволяет опустить стадию конфигурирования Spring вообще (до тех пор, пока это действительно не понадобится)
В целом всю статью можно заменить на следующий текст:
«парни, хотите легко и быстро научиться создавать приложения на java с использованием Spring Boot? идите по этой ссылке и все у вас получится: http://spring-projects.ru/guides/spring-boot/»tmn4jq
29.09.2016 12:44+1А я где-то сказал, что Spring не оперирует аннотациями? К чему вы придрались? Из вашего комментария я не могу сделать вывод о вашем знании спринга, но могу сказать, что вы не особо стараетесь понять, что вам говорят и только стараетесь блеснуть своими познаниями.
Вся идея – boot позволяет избавиться от нудной xml-конфигурации, которая только потопит в самом начале. Boot позволит сразу приступить к коду. Я нарочно привел цитату про xml и stackstrace, но вы даже так не поняли, о чем речь.AlexPu
29.09.2016 12:50Еще раз попробую повторить:
НУДНОЙ XML КОНФИГУРАЦИИ В SPRING FRAMEWORK НЕТ! Вы МОЖЕТЕ использовать XML для конфигурирования Spring приложения ЕСЛИ ЗАХОТИТЕ. Если не захотите, то избавляться не от чего — т.е «Вся идея – boot позволяет избавиться от нудной xml-конфигурации» это просто ложный изначально посыл, но вы даже не поняли о чем речьtmn4jq
29.09.2016 12:58Можно ли Spring MVC приложение сконфигурировать без web.xml?
voopr
29.09.2016 14:50Можно.
Только причем здесь web.xml, он не имеет прямого отношения к Spring.AlexPu
29.09.2016 19:35Тоже не понял при чем тут web.xml но да — spring приложение с легкостью конфигурируется без использования xml файлов конфигурации. И без web.xml тоже (хотя всетаки стоит помнить, что web.xml к spring framework отношения не имеет и вы вполне можете написаит веб приложение без spring и без web.xml )
tmn4jq
29.09.2016 15:17Стоит отметить, что речь шла о Configuration и Bean аннотациях, и я действительно не сразу понял, о чем речь. Да, необязательно использовать Boot, чтобы избавиться от аннотаций.
AlexPu
29.09.2016 19:36Spring boot в любом случае использует аннотации… господи — ну и каша у вас в голове…
AlexPu
29.09.2016 11:13+1>>так что ниже я дам лишь рекомендации о порядке выполнения этого проекта
Это рекомендации по ОДНОМУ КОНКРЕТНОМУ ТИПУ проектов… Увы и ах, но типов проектов множество, а начинать тренировку именно с такого типа проектов имеет смысл только когда начинающий раработчик имеет шансу найти оплачиваемую работу именно в таких проектах (но которые при этом сложнее на много порядков, что снижает самооценку начинающего разработчика — сам много раз видел)
tmn4jq
29.09.2016 11:35Этот один кокнретный тип включает работу с бд, со спрингом, базовое овервью mvc. Освещает основы создания CRUD. Если вы уйдете в глубокий бэк – просто меньше будете работать с mvc, а весь CRUD останется.
начинать тренировку именно с такого типа проектов имеет смысл только когда начинающий раработчик имеет шансу найти оплачиваемую работу именно в таких проектах
Ну вот если вы просто хотите попробовать java, вы первым делом пойдете на hh.ru и посмотрите, какие именно джависты у вас в городе требуются, или пойдете в гугл для того, чтобы в принципе пощупать современный стек? Если падаван освоит указанные в статье инструменты, то (я верю) этого будет достаточно, чтобы устроиться на позицию junior java-dev на любой тип проекта. А глубокие знания по каждому конкретному типу проектов придут со временем и с опытомAndreyRubankov
29.09.2016 14:56+1Spring Boot плохой вариант для понимания CRUD. Снова магия! Спрятавшись за Spring Data начинающий даже понятия не будет иметь как это все работает, для него это будет «я ему ИД, он мне Объект», такой начинающий на первом же собеседовании завалится. Когда начинающий учит sping он учит только spring (ну и xml), он не представляет себе жизни за приделами этой экосистемы. Да, можно получить позицию и потом доучить, но это менее качественный путь развития, т.к. «потом» почти никогда не наступает.
Если строить курс обучения, то лучше взять что-то менее магическое, тот же Guice, Gson, JAX-RS, html + js c ajax запросами. Это будет немного сложнее, чтобы освоить джаву, но на много полезнее для развития как профессионала.tmn4jq
29.09.2016 20:57А что особо понимать в CRUD? Внутренности того же Hibernate могут смутить на первых порах. В одном из пунктов я написал, что считаю необходимыми базовые знания SQL. Если это в наличии, то слова create-read-update-delete не должны вызывать ступора. Ну а пример того, как легко Spring позволяет реализовать этот CRUD должен был вызвать вах-эффект :) Понятно, что магия и некая интроспектива, но так можно «скатиться» к изучению матчасти до очень глубокого уровня, так никогда и не получив работу :)
tmn4jq
29.09.2016 20:58Поправка – конечно, я не хочу сказать, что надо лишь получить работу, ничего особо не раскопав. Но идеальный вариант, как я его вижу – это получить первую работу, а там уже учить-учить-учить и закрывать пробелы.
AndreyRubankov
30.09.2016 11:21На работе подымать матчасть почти никогда нету времени. Половина работы девелопера — поддержка. Тяжело даже представить что идет не так, когда не понимаешь как оно работает. Обычно такие люди просто сидят в дебаггере и построчно пытаются проходить свой код в попытках что-то найти.
Hibernate — тоже не лучший вариант, да и последнее время, слышны отзывы, что это уже плохая практика. По-моему, хороший и правильный опыт — изучение jdbc (ну или хотя бы Spring jdbc Template).
Моя позиция, что нужно учить снизу вверх (где-то так с середины). Изучение самых верхних абстракций не дает опыта разработки.tmn4jq
30.09.2016 12:05Хорошие разработчики поднимают матчасть в свободное и личное время. Всегда же хочется быть профессионалом в том, чем занимаешься :)
AndreyRubankov
30.09.2016 12:46Несомненно, так оно и есть, так оно и будет.
Вот только если разработчик работает и не знает основ, он на работе будет говняшить и писать плохой код, а дома учиться. В результате он будет набивать шишки прямо на продакшн проекте. Ему хорошо, а команде и заказчику — не очень.
Но это мы скатываемся в холивар «курица или яйцо».taujavarob
30.09.2016 12:54>он на работе будет говняшить и писать плохой код… команде и заказчику — не очень.
Заказчику обычно как-то до фонаря качество код. У него иные цели.
Если команда пишет хуже вас — то и команде до фонаря.
Если команда пишет лучше вас — то только тогда команде больно.
;-)
tmn4jq
30.09.2016 13:11А где еще набивать шишки, как не на продакшен проекте? Дома чтоль? Для этого и придуманы менторы и тим-лиды, а еще такие штуки, как код-ревью. В бою только и можно отточить свои навыки.
deadlynadder
29.09.2016 12:45У меня только один вопрос: ну и где моя работа? Я подготовлен вот четко на этот уровень знаний (описанный в стать). Где моя работа? Что я делаю не так? :(
Но список хороший, поможет новичкам понять что им нужно.AlexPu
29.09.2016 12:52Вы делаете не так практически все… начиная с того, что вы не так ищите работу… Но это дело поправимое (в принципе)
IlyaLesh
29.09.2016 14:56А как нужно искать работу?
AlexPu
29.09.2016 19:37-1Очевидно не так как вы это делаете!
IlyaLesh
29.09.2016 21:07+1Конструктивные ответы — ваше всё.
AlexPu
30.09.2016 08:30Как скажете… А давайте сравним ваши ответы и мои? Вот вам вопрос: склдбко ангелов помещается на кончике иглы?
Жду от вас конструктива!IlyaLesh
05.10.2016 15:04Вы делаете не так практически все… начиная с того, что вы не так ищите работу… Но это дело поправимое (в принципе)
Этот комментарий действительно заинтересовал меня, у меня действительно нет работы, я пока учусь, и только начинаю рассылать свои резюме. У меня еще не было нормальной работы, и я предпологаю что действительно могу что-то делать не так.
А как нужно искать работу?
Это не было попыткой на вас наехать.
Но к моему сожалению вы отвечаете на любознательность — агрессией. Мне не понятно почему.
Если вы собираетесь продолжать вести эту треш-болтовню, то пожалуйста, не втягивайте меня в это, ибо как у меня есть чем заняться помимо словоблудия.
P.S. Бога нет -> ангелов нет -> на кончик иглы может поместиться бесконечность ангелов.taujavarob
05.10.2016 15:39IlyaLesh >Но к моему сожалению вы отвечаете на любознательность — агрессией. Мне не понятно почему.
AlexPu просто развлекается так тут.
https://habrahabr.ru/post/311272/#comment_9841464
Почему он выбрал именно эту «площадку» для своего развлечения я не знаю.
>P.S. Бога нет -> ангелов нет ->
С такими утверждениями категорическими надо поосторожней. Теологию ведь ещё не изучают в универах, кроме МИФИ. ;-)AlexPu
06.10.2016 17:38>>Почему он выбрал именно эту «площадку» для своего развлечения я не знаю.
А вам очень-очень нужно это знать?
AlexPu
06.10.2016 17:38Увы — после долгих размышлений, конструктива у вас не получилось — получился набор их трех бездоказательных утверждений, между которыми вы волевым усилием и директивно установили причинно-следственную связь.
Так что ваша конструктивность от моей не отличается ничем… А причина проста — на неконструктивный вопрос можно дать только неконструктивный ответ…
И именно такой ответ и был дан мною на неконструктивный вопрос «А как нужно искать работу?» — Или используя приятную вам нотацию «неконструктивный вопрос» -> «Неконструктивный ответ»… И никакой философии вроде моих предполагаемых размышлений на тему «а не было ли это попыткой наехать» тут нет и не могло быть в принципе (если вам нужен более определенный ответ — наезжайте на меня сколько ваше дуще угодно — мне все равно)
taujavarob
29.09.2016 20:15+1Я нашёл случайно.
На один из форумов (около-компьютерной местной тусовки), где с десяток человек поносили Штаты, зашёл человек, вступился за Штаты, а в конце дня оставил свой email и спросил — не желает ли кто поработать java программистом?
Потом личная встреча с ним, телефонное собеседование по java и я стал работать.
Но это было давненько, — сейчас ищут работу как-то иначе. ;-)
tmn4jq
29.09.2016 12:54Это не таблетка, нужно самому подстраиваться под ситуации и стремиться к цели :)
Invader-Zim
29.09.2016 20:42Точно. Знаю гораздо больше описанного минимума. Причем давно.
Написать такой CRUD/JSP могу чуть ли не с закрытыми глазами, а потом апгрейднуть его, добавив Spring, Jquery/Ajax и Hibernate c любой реляционной БД.
И вот как дальше использовать эти знания?
Размещение резюме ничего не дает.
А согласие поработать бесплатно наоборот даже отпугивает.
Создалось впечатление, что нынешний новичок — это совсем не новичок, а человек с опытом коммерческой разработки.tmn4jq
29.09.2016 20:46Так не надо размещать резюме, надо самому активно откликаться на вакансии. В каком городе проживат изволите? Хорошо ли там с ИТ?
taujavarob
29.09.2016 20:59>Размещение резюме ничего не дает.
Хм. В Киеве нет спроса на java программистов вашего уровня?
Тогда в Минск -> https://jobs.dev.by/?search-jobs%5Bcity%5D=4429&search-jobs%5Btech%5D=java
Или в Винницу, есть там фирмы пишущие на java! ;-)tmn4jq
29.09.2016 21:02Точно, Киев же. Да, думаю, нужно быть просто более активным, погулять по собеседованиям и набрать тестовых заданий.
Invader-Zim
29.09.2016 22:26У вас по ссылке множество вакансий для Java разработчика. Сплошные Лиды и Синьйоры. Такая же ситуация везде. Какой смысл откликаться на эти предложения? Надо сначала эти Синьором стать.
taujavarob
29.09.2016 22:41Вот вам Миды: https://jobs.dev.by/?search-jobs%5Bcity%5D=4429&search-jobs%5Btech%5D=java&search-jobs%5Buser_level%5D=2
;-)
А вот и одного года достаточно:
https://jobs.dev.by/82681
https://jobs.dev.by/82669Invader-Zim
30.09.2016 02:28Спасибо за участие, но у меня 0 опыта, а не год. Я не мид и даже не джуниор. Просто умею делать, то что написал. Поэтому и спросил, что делать если умеешь гораздо больше минимума указанного автором, но не имеешь опыта коммерческой разработки. Резюме с нулем опыта даже не рассматривают. А врать как-то не по-мне :(
taujavarob
30.09.2016 09:40>А врать как-то не по-мне :(
Врать не надо. Но за самоуверенность могут просто пожурить. :-)
В настоящее(!) время юниоров берут так (в большие(!) фирмы) — с 3-4 курса универа(и т.п.) часто летом, проводят типа стажировки — на несколько месяцев — в это время, читают им лекции, практические занятия — в конце студенты делаю свои проекты. Смотрят — кто и как из них справляется — потом отбор — до половины(!) отбирают, по результатам, например с прикладной математики БГУ.
В вашем случае трудно конкретно рекомендовать (хотя я сам без практического(!) опыта на java сразу стал тим-лидом — но это было давненько, тогда Java-программисты были вообще дефицит).
Что «подкупило» моих работодателей — я тогда(!) писал в инете статьи по Java (рассматривал конкретные детали технологии, задачки всякие давал интересные — не тривиальные). Этим их и «подкупил». ;-)
В вашем случае — заведите себе несколько проектов в инете.
Вот в резюме их и указывайте (с описанием, что используется, что делает, как проверить демо).
HR будет достаточно глянуть на то, что такие проекты у вас есть.
Технари же сразу смогут глянуть — что вы используете и на ваш код. (Раньше для этого приносили на собеседование на Java игрушки, например, на дискетах (да, не на флешках — так давно это было), но сейчас СВОЙ проект(или несколько) в интернете — с возможностью посмотреть ваш код — это, наверняка, продвинет вас в поисках ПЕРВОНАЧАЛЬНОЙ работы).
Удачи!
Invader-Zim
30.09.2016 15:55Да. Наверное вы правы. Парочка проектов на Гитхабе спасут отца русской демократии.
taujavarob
30.09.2016 16:23>Парочка проектов на Гитхабе спасут отца русской демократии.
И напихайте туда всего побольше (всех технологий). :-)
tmn4jq
30.09.2016 10:51В вакансиях обычно описывают какого-то чудо-девелопера, и редко, очень редко бывает, когда кандидат знает все описанное. Так что не нужно стесняться, если больше чем половина слов вам знакомы – смело отправляйте резюме. А там они уже решат, звать ли вас на собеседование.
taujavarob
30.09.2016 11:05>В вакансиях обычно описывают какого-то чудо-девелопера
Вообще-то любой программист и есть «чудо-девелопер» или просто «чудо». ;-)
Но вы верный дали совет. :-)
sshikov
30.09.2016 09:11+1Вообще для получения работы нужно еще много чего. Кроме java, в смысле. Скажем, уверенное владение чем-то типа Git. Или умение работать в команде — т.е. понимать коллег и излагать свои мысли/вопросы.
Не исключено, что вам не хватает именно их. Но сказать это наверняка очень сложно.
Saffron
30.09.2016 09:18Тут была недавно статья, почему девушки-программисты устраиваются на работу хуже чем парни. Наглости им не хватает.
sshikov
30.09.2016 09:36+1Ну, возможно в том числе и наглости. Тут ведь наверняка замешаны интервью — и это совсем отдельная история. Где нужно скорее не сами знания — а умение их достать из головы в процессе беседы, в стрессовой некоторым образом ситуации.
Т.е. ответить на интервью на вопрос не напрямую, а скажем как-то так: "Я ответ не знаю, но можно я тут порассуждаю на тему..." — это ведь хороший ответ, в большинстве случаев, но далеко не все так могут. Я вот и сам не всегда могу, потому что интервью это одно, а повседневная работа — совсем другое. Можно назвать это наглостью, можно — уверенностью в себе, суть от этого мало поменяется. Это свойства личности, не связанные непосредственно со знаниями java, но сильно влияющие на получение работы.
Alexeyslav
30.09.2016 10:31Оу, я так экзамен по физике сдавал… начал рассуждать и даже не договорил — давай зачетку, отл., свободен не задерживай очередь.
taujavarob
30.09.2016 10:45>я так экзамен по физике сдавал… начал рассуждать и даже не договорил
Рассуждать? — Хм, это точно по физике, а не по философии экзамен то был?vlivyur
30.09.2016 11:07А вы точно не гуманитарий?
taujavarob
30.09.2016 11:25> А вы точно не гуманитарий?
Однокурсник, SQL-программист, начальник отдела в банке, при встрече выпускников сказал мне — ни слова о базах данных, будем говорить о поэзии. ;-)
И я подумал — что может быть скучнее годами писать SQL-код!? ;-)
vlivyur
03.10.2016 13:12Я к тому, что уж в физике всё довольно логично и взаимосвязано, и если что-то забыл, то это можно вывести из других законов или даже переложив в другую область. Мы в универе подходили консультироваться с нестандартными задачами к преподавателю по вакуумным приборам. Она, будучи не совсем в теме, могла вывести закономерности и рассказать что в задаче и зачем. Дальше нам оставалось лишь найти формулы и подставить цифры.
taujavarob
03.10.2016 15:09-2vlivyur > Мы в универе подходили консультироваться с нестандартными задачами к преподавателю по вакуумным приборам… Дальше нам оставалось лишь найти формулы и подставить цифры.
Отлично. Но если бы вы её спросили — почему именно такие формулы? — то этим поставили бы её в тупик.
Потому что именно такие формулы есть в учебнике — вот её ответ был бы вам. ;-)
Alexeyslav
30.09.2016 11:55+1Заучивать учебник по физике вообще плохая идея.
Многие кстати не знают смысл закона ома, хотя заучили его на отлично… а куда его, зачем он и где применяется — в учебнике такого нет, значит и в голове не должно быть (с)один отличник.taujavarob
30.09.2016 12:38>Многие кстати не знают смысл закона ома, хотя заучили его на отлично… а куда его, зачем он и где применяется — в учебнике такого нет, значит и в голове не должно быть (с)один отличник.
Если на практике вы умеете решать задачи, то зачем вам знать, к примеру, «смысл»?
Вот интересный тред был недавно об этом:
https://geektimes.ru/company/scione/blog/279474/#comment_9555518
(Там о «Принципе наименьшего взаимодействия»)Alexeyslav
30.09.2016 14:46+2Не зная смысла приходится держать в голове решения для каждой возможной задачи, а если попадётся какая-то нестандартная то всё — ступор.
Из хороших решателей задачек получаются хорошие исполнители, а разработчки — никогда.
К сожалению, обучаемые не всегда правильно понимают смысл задач — они не являются конечной точкой обучения(как им это кажется) а лишь контрольной точкой для дальнейшего развития. И к ещё большему сожалению этого не понимают многие преподаватели.taujavarob
30.09.2016 15:35>К сожалению, обучаемые не всегда правильно понимают смысл задач — они не являются конечной точкой обучения(как им это кажется) а лишь контрольной точкой для дальнейшего развития. И к ещё большему сожалению этого не понимают многие преподаватели.
Вы крутой!
taujavarob
30.09.2016 10:38>Это свойства личности, не связанные непосредственно со знаниями java, но сильно влияющие на получение работы.
Это верно. Я однажды на интервью спутал Struts со Spring! (Не зная ни того ни другого практически — просто почитал с пол-часа перед собеседованием, в голове названия и перепутались — они же оба на «S») :-)
Меня интервьюер аж переспросил, точно ли я говорю о Struts?
Точно! — уверенно ответил я, и продолжил. ;-)
Кстати, бают в Штатах надо уверенно «заливать» что знаешь всё что интересуется работодателя:
— Я вёл проекты с использованием Java, Spring…
— А как у вас с С#?
— Запросто могу реализовать любую задачу и на С# (пара дней тренировки то...)
— А с Javascript у вас как? — У нас есть куски кода в проекте на нём.
— Лично знаком с создателем, неоднократно писал портлеты на Javascript, знаю React.
— У нас используется Angular.
— Какая версия?
— Я точно не знаю, это надо спросить у программиста.
— Да, это всё равно, писал на обеих версиях (в глаза не видел, но слышал что есть две версии).
— Отлично, когда можете приступить к работе?
— Могу прямо сейчас!
— Вы приняты.
;-)
fly_style
30.09.2016 15:36За статью спасибо, но хотелось бы отметить, что с джунов сейчас спрашивают больше, чем написано в статье.
AlexPu
01.10.2016 14:17с «джунов» то что описано в статье вообще не спрашивают — нелепо это спрашивать… Но опыт приветствуется… впрочем приветствуется почти любой опыт
tmn4jq
01.10.2016 14:57В смысле не спрашивают? Такие базовые вещи, как Collections Framework и иерархию исключений с джунов только и спрашивают.
fly_style
02.10.2016 09:12Расскажу, что спрашивали меня. Из опыта — полгода на плюсах + куча лаб на Java + Spring / Play.
0. ООП
1. Коллекции и дженерики
2. Иерархия классов
3. Spring MVC + Core
4. Немного по JS поспрашивали
5. Лямбды и стримы
Что странно, про БД и ORM вообще не спросили.AlexPu
02.10.2016 10:42Надо полагать, что вы заявили о себе определенным образом… Другой вариант — не блистали в «основах» (интервьюер как правило станается найти хоть что-то в чем действително разбирается кандидат. особенно это касается начинающих разработчиков)
fly_style
02.10.2016 13:07Думаю, первый вариант. С БД начал знакомство до того, как начал учить Java. Хотя, неведома мне логика того интервьювера :)
AlexPu
02.10.2016 18:55Ну… Логику интервьюера понимать не надо — это бессмысленное занятие.
Но идею вы вероятно ухватили верно — если вы заявляете о себе, что вы крутой (но скромный) спец по спрингу, то велик шанс, что интервьюер начнет именно со спринга… И если все будет в порядке, то очемб можеь быть, что на нем-же и закончат… Что-же до ORM, то это в подавляющем большинстве случаев не является сколь ниюудбь важным при собеседованиях, за исключением случаем, когда инревьюер кроме ORM ни в чем толком не разбирается…
Скажу по секрету — у меня уже давно никто не пытается узнать уровень владения теми или иными технологиями… У меня уже и образцы кода заготовлены — на разных технологических стеках… и на собеседованиях я говорю «готов выполнить тестовое задание, но если вам лень его сочинать, можете ознакомиться с моим кодом»… хоть бы одна зараза посмотрела… или там свое задание дали бы… Да фиг с ним — можно было бы расспросить… ну там про тот-же спринг… или там ангуляр… все вопросы только из серии «а вот с этой хренью знаком?», «а как давно? А что делал?», «А вот эту херню пробовал?», «Нет? А почему?»… Некоторое оживленире на вопросах типа «А вот как бы ты решил вот такую задачу» — но очень недолгое, ибо ничего революционного я предлагать не готов (я вообще противник любых революций)… Вот обидно знаете ли… На старости лет готов со всей беспощадностью демонстрировать свои знания, а оно нахрен никому не надо…taujavarob
03.10.2016 15:16AlexPu > все вопросы только из серии «а вот с этой хренью знаком?», «а как давно? А что делал?», «А вот эту херню пробовал?», «Нет? А почему?»
Это ясно. Из имеющегося набора претендентов они хотят выбрать НЕ того, кто теоретически подкован ли или «готов учиться новому», — а того, кто УЖЕ использовал ту или иную технологию на практике(!).
Так что отвечать надо как в Штатах — да, использовал. Да напишу. Да, знаком. (на все вопросы, если… хотите получить у них работу). ;-)AlexPu
03.10.2016 17:10Возможно вам так и надо поступать… А я лично уже давно могу себе позволить быть честным и самокритичным…
А писал я про другое — про то, что довольно обидно будучи вполне способным продемонстрировать свои профессинальные качества обнаружить, что никто в этой демонстрации не нуждается — всем вполне достаточто устного утверждения…taujavarob
03.10.2016 17:30AlexPu > обидно будучи вполне способным продемонстрировать свои профессинальные качества обнаружить, что никто в этой демонстрации не нуждается — всем вполне достаточто устного утверждения…
Возможно вы производите вид честного человека. — Попробуйте как-то изменить ваш имидж, чтобы вам… не верили на слово. И тогда — вас начнут… пытать по полной на собеседованиях. :-)AlexPu
03.10.2016 18:09Возможно и так… но возможно и другое — люди которые интервьюируют не являются такими уж идиотами, как вы о них думаете…
taujavarob
03.10.2016 19:07AlexPu > люди которые интервьюируют не являются такими уж идиотами, как вы о них думаете…
Люди разные. Это уж вы отрицать не будете. Я думаю.
Есть такие, что просто читают чужие мысли через экран монитора — как вы читаете мои и воображаете себе (из моего нейтрального текста), что я думаю о людях которые интервьюируют.
А я вам, без ваших воображений, отвечу просто — я думаю о людях которые интервьюируют, что им очень трудно. Особенно с вами. Имхо.AlexPu
04.10.2016 11:22>>Есть такие, что просто читают чужие мысли через экран монитора — как вы читаете мои и воображаете себе (из моего нейтрального текста), что я думаю о людях которые интервьюируют.
Но вы же тоже поступаете именно так? Или вам лично так можно?taujavarob
04.10.2016 14:20AlexPu > Но вы же тоже поступаете именно так?
Отмотал вверх:
Вы обиделись на «Возможно вы производите вид честного человека.»?
Хм, никогда бы не подумал, что на это можно обидеться!
К теме:
У меня знакомый один — когда его на собеседовании начинает кто-то спрашивать про технологии или задачки задавать — типа напишите сортировку и т.п. — он обычно говорит — Я кандидат физ-мат наук. У меня тема диссертации была связана с марковскими цепями. Я могу любую вашу технологию за пару дней выучить — что вы мне тут детские вопросы задаёте то?
AlexPu
04.10.2016 16:51Вот видите — здесь вы опять делаете пытаетесь «читать мысли через экран монитора», обвиняя в этом меня… а я всего лишь передразниваю вас не более того…
Что касается обид… если вам интересно я вам опишу вам часть своих свох взглядов на мир… вот представьте вы идете лесом, и вдруг какое-то дерево о вас что-то «подумало»… или даже «сказало» — вы что обититесь? На дерево? Вот и вы для меня просто набор букв…
Saffron
> Spring. Это фреймворк, который сильно упрощает жизнь. Фреймворк этот слишком большой, поэтому для начала достаточно просто понимать, зачем он нужен.
Все задачи spring замечательно решаются на уровне самого JVM. Внешние тулзы не нужны.
Так что имхо, надо выбирать: либо ты знаешь и умеешь ООП, и тогда спринг не нужен. Либо ты из ООП только страшные слова выучил, а сути не понимаешь, и тогда без костылей тебе никуда.
OnYourLips
Конечно можно и на уровне «самого JVM», только с рядом условий:
— команда максимум из одного человека;
— неограниченные сроки и бюджет;
— «проект в стол», с около-нулевым жизненным циклом.
Я могу назвать единственную сферу, где все эти условия выполняются: изучение основ языка и сопутствующих технологий. Вы, наверное, дальше просто не заходили.
bigfatbrowncat
Для новичка, конечно, не применимо. Но представьте себе, что есть проект на C++ с ООП, несколькими десятками (под сотню) классов, командой из 5-10 человек и вполне себе серьезным жизненным циклом.
И представьте себе, что разработчик из этой команды переходит в Java-проект.
Зачем ему Spring?
Мой лично опыт Java Enterprise (длиной примерно в полгода) свелся к тому, что я пытался (увы, тщетно) внедрить в сознание некоторых моих товарищей, что объекты бывают не только объектами-модулями, но и объектами-типами данных (которые передаются между объектами-модулями и инкапсулируют некоторый набор базовых вещей) — товарищи упорно не хотели слышать о передаче чего бы то ни было сложнее, чем String. А причиной было то, что они были убеждены — в настоящей программе с IoC НЕЛЬЗЯ (вообще никогда) писать «new» и потом название пользовательского класса.
Вот такой вот, простите, «спринг головного мозга».
Повторю риторический вопрос: зачем человеку, действительно знающему ООП (и мыслящему категориями более низкоуровневыми, чем «шаблоны проектирования») использовать Spring? Единственная причина — наличие в команде людей, у которых уровень понимания ООП сводится к «не создавай объекты сам, а то ай-ай-ай!»
OnYourLips
> несколькими десятками (под сотню) классов, командой из 5-10 человек и вполне себе серьезным жизненным циклом
У вас числа не сходятся. Под сотню классов — это небольшой проектик на 1-2 человека со временем жизни в полгода. Или вы в классах пишете код с процедурным подходом по 10000 строк?
> Зачем ему Spring?
Чтобы эффективно, надёжно, быстро и дёшево решать задачу, для которой он применяет Java, а не технологию, с которой привык работать до этого.
> в настоящей программе с IoC НЕЛЬЗЯ (вообще никогда) писать «new»
Крайне сомневаюсь, что это звучало именно так. В любом случае, фанатизм не доводит до добра.
> Повторю риторический вопрос
Чтобы выполнить проект, если заданы ограничения по срокам, бюджету и длительности поддержки. Потому что без Spring или аналогов, со своим велосипедом, вы не уложитесь в эти требования.
bigfatbrowncat
У меня всё прикрасно сходится. Далеко не все классы не содержат в себе мозгов и имеют сложность уровня Vector3D, который задавали в институте как упражнение по C++. Классы в программе, которая что-то делает, помимо тупого CRUD, имеют часто длину в пару сотен строк. И, да, разрабатывать на C++ сложнее, Java проще сама по себе.
> Крайне сомневаюсь, что это звучало именно так.
Разумеется, будем отрицать любой аргумент, который не укладывается в ваше представление о прекрасных мудрых Spring-разработчиках. Повторюсь — люди именно что боялись создавать объекты сами. Их пугала страшная ответственность. Поэтому они предпочли передавать структуру внутри String-а, а методы, которые этой структурой оперируют, вынести в Tool-класс. Разумеется, это всё к Спрингу не относится.
> Чтобы выполнить проект, если заданы ограничения по срокам, бюджету и длительности поддержки
Вы убеждены, что Spring упрощает жизнь. Я попробую показать вам, где он ее усложняет.
Например, ошиблись вы по неопытности (или по опечатке) в xml-конфигурации какой-нибудь фигни (а xml этих там десяток). Как отлаживать будете? Мне шайтан-система в этой ситуации выдавала стектрейс из неоткуда вникуда. Ну то есть откуда-то из недр парсера конфигурации, который я впервые видел.
Если бы я даже писал этот парсер лично, сам (хотя, есть куча готовых удобных DOM-парсеров), я бы получил стек более понятного вида.
Главный критерий удобства сложной системы — это отлаживаемость. Потому что на дебаг хрен-знает-откуда-непонятной-ошибки уходит 80% времени. Именно поэтому я не люблю IoC. Отлаживать ошибки в его конфигурации не более приятно, чем любимую ошибку с забытым амперсандом в C++
Но главная проблема не в этом. Нравится вам Spring — на здоровье, пользуйтесь. Но ради всего святого, не нужно выпускников вузов начинать учить спрингу. Дайте людям сперва натренировать голову на простых собственных решениях. Пусть они придут к неизбежности этого Спринга (или, напротив, придумают что-то свое, лучше). Что? Нет денег? Надо херачить код и быстрее-быстрее, а рук не хватает? Ну тогда получите людей, у которых вместо мозгов IoC, распишитесь.
taujavarob
bigfatbrowncat > Пусть они придут к неизбежности этого Спринга (или, напротив, придумают что-то свое, лучше).
Spring это уже стандарт. А вот стандарт Java2EE — уже ничто.
Spring типа (аналогично) как Node.js на сервере (а лет 5-ть назад там было с 5-к конкурентов Node).
Всё. В мире Java наступила стабильность. Java типа Кобола сейчас.
Так что надо учить Spring, как обязательную данность — всё остальное для джунера не имеет значения.
Вот такая философия текущего дня.
AndreyRubankov
> Всё. В мире Java наступила стабильность. Java типа Кобола сейчас.
Что? Вы серьезно? В плохом мире вы живете.
Java 8 сильно меняет игру. Java 9 — это будет полный переворот в мире java, немного осталось.
taujavarob
AndreyRubankov > Что? Вы серьезно? В плохом мире вы живете.
Нормальный мир. Тем более я переметнулся на Javascript — вот где бурление жизни! ;-)
AndreyRubankov > Java 8 сильно меняет игру.
Точнее пытается хоть как-то следовать моде. Полностью что-то значительное в Java произошло только в Java 1.5
AndreyRubankov > Java 9 — это будет полный переворот в мире java, немного осталось.
Ну, это когда будет то — мы же помним постоянные отсрочки выхода новой версии и переноса новых фич на следующий релиз.
Иначе говоря — по сравнению с миром JavaScript, мир Java — это сонный мир в летнюю ночь. ;-)
Единственно, скандалы с Java2EE и Оракл vs Гугл хоть как-то оживляют мир Java.
«Няма таго, што раньш было...» (С)
taujavarob
@ AndreyRubankov > Java 9 — это будет полный переворот в мире java, немного осталось.
Релиз Java 9 отложен. Новый срок GA — июль 2017.
AndreyRubankov
По-моему, это не много, учитывая на сколько грандиозное изменение будет представлено!
Java 9 — это лучший поинт отказаться от легаси (apache, guava, spring, hibernate, OSGi) и начать писать правильно. Начать пилить хороший и быстрый код, а не энтерпрайзы.
taujavarob
>По-моему, это не много
Наверное. А там ещё отложат и ещё. Знаем, плавали. ;-)
Saffron
> Наверное. А там ещё отложат и ещё. Знаем, плавали. ;-)
И кто, по-вашему, в конце-концов купит Оракл?
taujavarob
>И кто, по-вашему, в конце-концов купит Оракл?
Хм, — Оракл его знает кто.
(каламбурчик) ;-)
Кроме Гугла Java никому СЕЙЧАС не нужна — ведь так?
tmn4jq
Рассуждать в стиле «вот был опытный программист С++, и перешел на Java, зачем ему топовые Java-фреймвоки/библиотеки». Надо использовать то, что язык и экосистема позволяют. Зачем тянуть все особенности старого языка в новый? (под старым подразумеваю тот, на котором писал раньше)
bigfatbrowncat
Я, наверно, рассуждаю поверхностно. Просто, полгода общения со Spring не убедили меня в том, что в проекте, который мы на нем создавали (весьма большом) он был необходим. Выглядело это часто так, что люди попроще — да — писали код, не задумываясь, а вот люди поопытнее часто решали проблемы с самим фреймворком (которые генерили менее опытные товарищи). То есть слабые получали преимущество за счет сильных, которые воевали с косяками (или непонятками) в самом фреймворке.
У меня (находившегося тогда где-то между теми и другими) возникло стойкое чувство, что если бы мы его бережно взяли и выкинули, а людей, которые что-то не умели, научили жить без него, никто бы не пострадал. И проект — в первую очередь.
taujavarob
bigfatbrowncat > У меня (находившегося тогда где-то между теми и другими) возникло стойкое чувство, что если бы мы его бережно взяли и выкинули, а людей, которые что-то не умели, научили жить без него, никто бы не пострадал. И проект — в первую очередь.
Шанс ошибиться и породить «свой велосипед», который со временем никто не захочет «тащить» дальше своими силами — очень велик.
Так что Спринг! Имхо.
taujavarob
> в настоящей программе с IoC НЕЛЬЗЯ (вообще никогда) писать «new» и потом название пользовательского класса.
Ребята просто думали о том, как потом протестировать этот код, когда в нём есть new!
Как в этот код передать мок этого объекта, который в коде то new?
Zeitung
Ситуации могут быть разные. Допустим мне надо вернуть список некоторого тупого Domain объекта (у которого нет своих методов кроме гет\сет), который не используется в DataStorage, но удобен для передачи набора параметров в другой модуль или, допустим, фабрику, которая как-то обработает эти параметры\объекты. Т.е. объект просто конвенция, которая ещё может наследовать интерфейс. Нет, можно конечно пойти JS путём и передавать всё в виде Map, но не будем вдаваться в крайности. Вот и вопрос, а зачем мне делать DI\IoC для такой операции? Создать мок можно из того-же Domain через new… Какая разница, если объект всё равно тупой как пробка, а навешивать логику на get\set я бы сказал очень не правильно т.к. это не очевидно + она должна выполняться в моделе, которая создала такой объект.
Другой пример лежит в плоскости не понимания зачем нужен DI. Если проект пишется под использование конкретной библиотеки, с своими СОБСТВЕННЫМИ интерфесами\конвенциями, с sealed\final классами\методами (т.е. переписать поведение нельзя да и не предусматривается), то зачем мне перекладывать манипуляцию с объектами библиотеки на DI\IoC? Переход на другую библиотеку лежит в плоскости переписывания самой библиотеки самому…
bigfatbrowncat
new делался в слое контроллера, который был выше бизнес-логики. Передать Mock — никакой проблемы нет. Главный аргумент был «зачем тебе непонятный класс, используй стринг». Я им говорил «ребята, к этому стрингу надо приложить парсер, генератор из нескольких полей в этот стринг, и несколько функций». Они отвечали: «ну так положим эти функции статиками в утилитный класс». Как говорится, «занавес».
r00tGER
Без ORM тоже можно обходиться, чистый JDBC… и.т.д.
Фреймворки — это инструменты, которые упрощают процесс разработки.
Throwable
Фреймворк — это набор готовых шаблонов для решения определенного круга задач, который как правило базируется на определенной архитектурной парадигме (DI + IoC, Actors, Reactive, FP, etc...). Фреймворк позволяет девелоперу среднего уровня быстро бутстрапить типовые приложения без вникания в суть дела, просто копипастив код из примеров, а также предотвращает появление в коде слишком бурной фантазии новичка.
Упрощает ли фреймворк разработку — вопрос неоднозначный. Да, если Вы досконально его изучили, умеете им пользоваться, понимаете как он работает внутри, знаете все его ограничения, и грамотно обходите возможные грабли. Однозначно нет, если Вы находитесь в процессе его изучения, параллельно используя его в своем проекте. В этом случае разработка превращается в постоянное гугление и вопросы на форумах "как сделать как мне надо при помощи этого фреймворка".
tmn4jq
В этом-то и беда. А именно в таком понимании всей пользы фреймворков.
Позвольте перефразировать – фреймворки просто предоставляют вам уже готовые и проверенные велосипеды. Чтобы копипастить, фреймворк не нужен.
taujavarob
>Позвольте перефразировать – фреймворки просто предоставляют вам уже готовые и проверенные велосипеды.
Более точно: фреймворки просто предоставляют вам уже готовые и проверенные практики!
taujavarob
>Без ORM тоже можно обходиться, чистый JDBC… и.т.д.
В 2016 году то? Хм.
UnixMaster
Думаю, зависит от проекта. Если есть утвержденная БД для проекта, то чистый SQL писать гораздо «выгоднее» как для разработчика (изучит, если не знает, все тонкости SQL и БД c которой работает), так и для повышения производительности приложения. К сожалению не существует идеальной прослойки между БД и объектами, которая позволяла бы так же манипулировать запросами к БД и добиваться максимальной эффективности.
UnixMaster
UPD
Хотя могу и ошибаться, мы начали писать запросы на SQL и не пожалели, в отличие от знакомых, которые поимели кучу гемороя с hibernate, связанную с утечкой памяти, бессмысленым перемылванием кучи информации, вместо того, чтобы вытащить из БД то, что нужно. Возможно ребята не умели готовить hibernate, и в итоге им пришлось писать костыли для очистки памяти и прочих проблем, с которыми они не справились средствами hibernate.
tmn4jq
Все сводится к кокретным задачам. Нет смысла юзать Hibernate там, где нужно просто достать значение столбца и работать с ним. Проще сразу через JDBC выбрать строку и столбец, чем забирать всю строку и создавать на ее основе объект (это еще если lazy init).
taujavarob
Дело в том, что при изменении структуры объектов вам надо будет тогда найти всюду ваш, «независимый голый SQL код» и поправить его.
То есть вам нужно будет всегда об этом думать и всегда заниматься синхронизацией вашего «голого SQL кода» с изменением java кода ваших объектов.
При этом, ваш «голый SQL код» будет работать и вполне возможно не выдавая ошибку, но логически УЖЕ не верно. А вот код генерируемый, завязанный на java объекты — будет работать так как вы и задумали.
Я видел много проектов, где начинали писать обращения к базе БЕЗ «голого SQL кода», потом, (наверное появлялся БД мастер в проекте) — переходили в запросах на «голый SQL код» (Hibernate это позволяет, конечно), а проблему синхронизации (выше описал) решали методом — когда будем что-то менять, то ВСПОМНИМ и просмотрим все эти «голые SQL коды» и поменяем.
Печально это. Имхо.
tmn4jq
Тут уже можно сместить мысль в сторону unit-тестирования. Вставки «голого sql» должны быть покрыты по-максимуму.
taujavarob
> Тут уже можно сместить мысль в сторону unit-тестирования. Вставки «голого sql» должны быть покрыты по-максимуму.
unit-тесты могут и не сломаться. Но рано или поздно что-то пойдёт не так — так как «голый SQL» требует фактически ручной(!) синхронизации с java-кодом.
Одно дело — добавил в java-код — SQL код автоматом НОВЫЙ создался — всё окей. Или же ошибка вылетела — поправил.
А вот когда после правки тишина и надо вспомнить про тонны «голого SQL», который надо вручную просмотреть не на предмет программной ошибки, а на предмет логики (логической ошибки — да хоть новое поле вставить в список выбираемых полей!) — вот тогда — АААААААААААААААААААААААААААААА!
;-)
tmn4jq
Ну добро пожаловать в сервер-сайд разработку, тут всегда нужно все контролировать. Голый sql может быть продуктивней, чем ORM, хоть и сложнее в обращении и поддержке.
taujavarob
>Голый sql может быть продуктивней, чем ORM, хоть и сложнее в обращении и поддержке.
Вот. С этим и только с этим соглашусь с вами! ;-)
AndreyRubankov
А как же DAO/DAL? Тот кто правит этот уровень — должен быть внимательным и думать про базу. А остальные уже пользуются java кодом. Нужно в базу — на тебе в базу, нужно на веб-сервис — на тебе веб-сервис, нужно мок — на тебе мок.
Да, хибернейт и спринг дата решают эту проблема, НО! Если есть требование написать действительно производительное и предсказуемое приложение — это только jdbc.
Ребята которые пилят под Spring обычно говорят «плевать на производительность, если нужно докупят серверов; время разработчика — дороже», отчасти они правы, но не всегда применим этот подход.
Saffron
> Фреймворки — это инструменты, которые упрощают процесс разработки.
Фреймворки лишь переусложняют его. Тебе нужно сделать одну простую задачу, а фреймворк несёт с собой груз инструментов и абстракций, которых хватит на полсотни таких задач. Особенно такие тяжеловесные, как спринг или JavaEE. Зачем тебе автоконфигурация на 100500 опций, да ещё в XML конфиге, если у тебя реально меняется в работе только 5? Если тебе нужно взаимодействовать с базой данных — ты подключаешь библиотеку для работы с ней. Если нужно сериализовать в JSON — опять же берёшь библиотеку. Одну конкретную, а не абстракцию над абстракцией.
Причём все эти абстракции имеют смысл только в реально большой задаче, где их можно переиспользовать 100500 раз. Зачем DI в новичковом проекте? Та же самая задача распаривания компонентов решается ООП: заводим класс/интерфейс Context, методы getX, getY, getZ. Если разных типов сущностей становится слишком много для одного класса — используем вложенные контексты.
Вы боитесь, что без ORM не сможете легко адаптировать код к изменениям схемы базы данных? Да что вам мешает завести словарик соответствия того, что ждёт программа и как оно сейчас называется в базе данных? Один слой косвенности вместо двух-трёх.
ORM — это просто сахар, DI — хитрозапрятанная кодогенерация. Они не делают ничего нового, что в десяток строчек нельзя сделать без них. Но они предлагают приятную опцию экономию строк, особенно приятную для столь многословного языка как джава. Но всё это нужно профессионалам, которые в день по сотне подобных объявлений делают и экономят значительную часть своих сил. Для новичка это яд. Он не знает, как это работает внутри. Он никогда не пробовал написать на голой явы без аннотаций и специальных класслодеров, не сможет повторить эти эффекты и конструкции самостоятельно, ведь это магия для него. А если ему потребуется перейти на другой фреймворк? Он просто не сможет перенести опыт с одного на другой, потому что видит там магию, а не работающий механизм. Советовать DI новичку — это испортить его как программиста.
Вспомните, как вы обучались на трудах. Разве вам давали в руки сразу сложные станки? Нет, сначала ручной труд. Потом нехитрые электроинструменты. И только в самом конце — станки с ЧПУ. Да и в квартире у вас лежит электродрель, а не целый сверлильный станок. Ручная дрель — это аналог ручной обработки всех запросов, электродрель — это уже готовая библиотека, которая уменьшает объём ручного труда.
А фреймворк — это сверлильный станок. И если тебе надо повесить полочки, ты не сможешь приставить его к стене, тебе придётся пользоваться заложенной в станок возможностью чуток подвигать стены вверх-вниз (да, стены, а не станок — мы же любим Inversion) и достать роборуку для позиционирования сверла с микронной точностью. Для наклонных поверхностей, кстати, есть другая рука, там вообще в поставке штук 30 их лежит — на все случаи жизни. Место такому агрегату — в цехе, а не у тебя дома, и не в учебной комнате.
taujavarob
>А фреймворк — это сверлильный станок…
Понимаете — сейчас просто никому (ладно, редко, очень редко) не нужно умение складывать числа в столбик.
Saffron
Тем не менее, в ВУЗах его почему-то изучают. Например, когда рассматривают модуль многочленов. Потому что на простых знаниях основываются более сложные. И вот они уже нужны непосредственно.
Alexeyslav
В столбик и правда неудобно, а вот уметь в уме перемножать числа используя всевозможные «хаки» очень даже пригождается. Когда умножаешь в уме быстрее чем открываешь калькулятор и набираешь…
А ежели «калькулятор» выдаст что синус равен двум и человек не заподозрит неладное только потому что у него не было такой практики и он не знает какой результат должна вернуть функция… ну да, в справочнике где-то написано, но его надо найти и вообще знать что надо это искать ведь программа не выдаёт ошибку!