❓ Зачем писать пет-проекты с устаревшими технологиями?
В технических заданиях проектов моего курса по Java (в его первой половине) местами используются устаревшие на сегодняшний день технологии и инструменты, например JSP и Java Servlets.
Зачем я включил их в ТЗ, и почему сразу не начинать писать на актуальном стеке?
Для освоения новых технологий есть универсальный рецепт:
- Понять, зачем технология нужна и какую проблему решает.
- Посмотреть на типовые кейсы её применения, представить, как это применить в контексте своих текущих проектов.
- Изучить теорию и применить на практике.
Первый шаг принципиальный, и для него требуется опыт. Трудно начать эффективно пользоваться фреймворком, если непонятно, зачем он создан. Фреймворк - это набор решений для типовых задач, а не просто груда классов и аннотаций.
Работа с более низкоуровневыми и простыми технологиями даёт:
- Способность оценить удобство современных инструментов.
- Кругозор и навык решения проблем.
- Лучшее понимание, какие проблемы решают новые инструменты.
Курс написан под студента, для которого 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, базы данных.
Что если на одном сервере нужно запустить приложения, требующие две разные версии Java? Почему локально работает, а на сервере - нет? Испытав эти проблемы на практике, понять идеи Docker проще.
Когда уместно пропустить устаревшие технологии и сразу перейти к актуальному стеку
Курс написан под студента, для которого Spring - первый фреймворк. Если у вас уже есть опыт с аналогичными инструментами в других стеках (например, Django в Python или ASP.NET в C#), то нет сильной необходимости опускаться на уровень ниже и писать проекты на сервлетах и JDBC.
В остальных случаях, я придерживаюсь мнения, что попытки сэкономить время и сразу начать учить актуальный стек в итоге будут стоить вам потерянного времени, а не наоборот.