Зачем писать пет-проекты с устаревшими технологиями?



В технических заданиях проектов моего курса по Java (в его первой половине) местами используются устаревшие на сегодняшний день технологии и инструменты, например JSP и Java Servlets.



Зачем я включил их в ТЗ, и почему сразу не начинать писать на актуальном стеке?



Для освоения новых технологий есть универсальный рецепт:



1. Понять зачем она нужна, и какую проблему решает

2. Посмотреть на типовые кейсы её применения, представить, как это применить в контексте своих текущих проектов

3. Изучить теорию и применить на практике



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



Работа с более низкоуровневыми и простыми технологиями даёт:

• Способность оценить удобство современных инструментов

• Кругозор и навык решения проблем

• Лучшее понимание, какие проблемы решают новые инструменты



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



Можно выделить 4 основных таких "трека" из роадмапа.



Процедурное программирование → ООП → паттерны/MVC



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



Servlets → Spring Boot



Фреймворки скрывают под капотом много мелочей, которые полезно понимать для эффективной работы и решения проблем.



• Проекты 3, 4 дают возможность поработать руками с сериализацией, HTTP заголовками, формами.

• В проекте 5 нужно вручную поработать с сессиями и куками.



Написание проектов на сервлетах даёт возможность настрадаться с обработкой ошибок, валидацией. После этого пользоваться Spring - одно удовольствие.



JDBC → Hibernate → Spring Data



ORM стирает границу между Java объектами и записями в БД, позволяет не писать SQL вручную, уменьшает количество boilerplate кода по работе с SQL соединениями, запросами.



Написание проекта на SQL+JDBC даёт опыт, с которым можно будет сравнивать свои ощущения от использования лаконичных ORM, особенно Spring Data.



Деплой - WAR + Tomcat → Jar → Docker



В прошлом, делпой заключался в передаче собранного WAR артефакта на сервер и его запуск. С появлением Spring Boot необходимость в application server'ах (таких как Tomcat) отпала, но осталась необходимость устанавливать на серверах все необходимые зависимости для запуска приложения - нужную версию Java, базы данных.



Что если на одном сервере необходимо запустить приложение, требующие 2 разных версии Java? Почему локально работает, а на сервере - нет? Испытав эти проблемы на практике, понять идеи Docker'а станет проще.



---



Когда уместно пропустить устаревшие технологии и сразу перейти к актуальному стеку



Как я писал выше, курс написан под студента, для которого Spring - первый фреймворк. Если у вас уже есть опыт с аналогичными инструментами в других стеках (например, с Django в Python, ASP.NET в C#) - нет сильной необходимости опускаться на уровень ниже и писать проекты на сервлетах и JDBC.



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



Курс | YouTube | Менторство | Поддержать