То, с чего началось: «Не надо писать в резюме опыт работы с базой XYZ, если весь ваш опыт заключается в CRUD через ORM. Приводит к неловкости на собеседовании».
Если прищурить глаз, что такое ORM? Слой абстракции, который позволяет вам работать с объектами вашей предметной области, не задумываясь особо о том, как они хранятся, как выбираются и т.д. Собственно, потому ORM’ы и появились — разработчики тратили мегатонну ресурса на то, чтобы даже простой CRUD сделать — схему напиши, модель напиши, методы напиши, result set в объект разбери, объект в тот же INSERT расчлени… И так на каждую писюльку. Пальцы устают.
Заодно сбоку появились механизмы миграции, больше декларативщины и т.д. Откройте мануалы к Hibernate или Django, там всё есть.
Вроде бы круто, не? Круто. Только теперь разработчик умеет работать с ORM, не умея работать с базой данных. Иначе говоря, ORM’ы и сделаны для того, чтобы тебе не надо было уметь, а ты человек, потому не умеешь и не хочешь уметь то, что не применяешь прям каждый день.
Первый пример. Фигня в том, что ORM бывают не оптимальны. И баги там бывают. И вообще всякое бывает. Написали вы код, красивый, умный. Выкатили на тестинг. Работает. Выкатили на прод. Работает. Проходит неделя. Работает на 5% медленнее. Проходит месяц. Бывают провалы на 20% деградации. Почему?
Включается дебаг запросов. Вытаскивается результат ORM-генерации. По нему смотрится план выполнения. Находятся проблемные участки. Осмысляется причина проблемности. Устраняется.
Другой пример. На фронте страничка. На страничке график за пять лет. По сути надо вывести результат серии агрегированных запросов по двадцати таблицам и 20M строк, размазанных по этим таблицам. Задача за рамками CRUD, очевидно. Тем более, отработать должно не дольше 500ms. Надо заметить, что в современных ORM часть подобных задач вполне решаема, но только часть. В ряде случаев вы получите прямолинейный JOIN на всё поле данных, от чего база будет кряхтеть, а пользователь минуту смотреть на спиннер. Ваши действия?
Написать в итоге правильный оптимальный запрос на SQL, после чего либо перенести его в ORM с сохранением характеристик, либо из ORM сырым и дёргать, бывает. Некоторую часть таких запросов оптимальными можно сделать только со знанием конкретной базы данных.
Третий пример. Вы наплодили тысячу классов в модели. ORM пожал плечами и создал тысячу таблиц. Он ведь инструмент, а не заменяющая мозг штука. Молоток не отпихивает неправильный гвоздь, лупит куда сказали. Бац, всё просело. Ну вот просто адово медленно работает. И?
Схему базы данных тоже надо проектировать. И делать это с учётом множества факторов. Просто набросать кучу классов и надеяться, что прокатит, получается не всегда. И снова ORM тут не помощник, скорее, добавляет дополнительные факторы для учёта.
Фактически каждая задача в области хранения данных в базах сводится к набору из трёх переменных: { фреймворк, язык[и] запросов, база данных }. Например, { Hibernate, SQL, PostgreSQL }. Или { Spring Data, MongoDB QL / JavaScript, MongoDB }. Если значение (требуемый уровень знаний) переменной превышает ваш уровень, задачу в оптимальный с внешней точки оценки срок вы сделать не можете.
Отмечу: не оцениваю эту тему с позиции хорошо / плохо знать / не знать. Каждый сам задаёт себе границы полезности. Проблема в другом.
Предположим, у вас в резюме в опыте работы указаны «Московский метрополитен» и «вагоны Еж-3 и Еж-6 последние два года». Что думать читающему резюме? Какой опыт от вас ожидать и какие вопросы для проверки задавать? Вот, что я подумаю (простите дурака с уникальным ходом мысли): о, этот боец разбирается в вагонах! Ура.
Приходит боец. Многолетний опыт спуска по эскалатору, знает названия станций, знает особенности первых и последних вагонов некоторых линий. Начинаю разминку о вагонах. За 15..30 минут собеседования выясняется, что опыт заключается в том, что вагоны этих моделей перемещали человека от A до B. Человек заходит. Некоторое время ждёт. Выходит. Всё.
Так. Хорошо. Зачем в резюме указал? Формально говоря, опыт есть без сомнения. Только это опосредованный опыт, да ещё такого объёма, что совершенно бесполезен в употреблении другими людьми. Ровно так же звучат рядом стоящие Hibernate и MySQL, если MySQL для вас тот же вагон метро из аналогии выше. Почему бы тогда не указать в опыте, скажем, ПНО 63-12-8? Рязанский завод ЖБИ №2 выпускает плиты перекрытия, по которым вы ходите в домах. На плитах слой бетона, слой заливки, гидроизоляция, паркет. Кое-где штробили проводку. Всё это не вы, впрочем. Весь ваш «опыт» — вы по ним ходите. Эдак десятки страниц резюме можно забить.
Почему-то знание лишь одной трети от набора заменяет в голове знание всей триады. О, если я знаю ORM, я знаю SQL и базы данных. Да нет, конечно же.
Хочу ещё пройтись по мнению «это специальные знания, требования к которым надо особо указывать в вакансии». Возможно. Правда, я пока не готов с этим согласиться. Бекендер — разработчик, часто имеющий дело с базами данных. Вы можете смотреть на мир через любую любимую призму, но вот я открыл HeadHunter, вбил [Java backend] и нажал Enter. Читаем (попутно умиляясь подмесу совсем не Java) первые десять вакансий (цитирую прям копипастой подряд из каждой):
- Опыт работы с базами данных: SQL, MySQL, JDBC, Oracle и т.д.
- Понимание SQL, NoSQL, реляционных, объектных БД, blob и других решений для хранения данных.
- Понимать, во что выливаются операции с ActiveRecord, оценивать эффективность получающегося SQL.
- Знание принципов работы баз данных и опыт работы с MySQL/PostgreSQL, умение писать сложные SQL запросы.
- реляционные СУБД, понимание принципов проектирования БД, отличное знание SQL
- опыт использования NoSQL баз данных (Cassandra, Hazelcast).
- Уверенное знание SQL (Транзакции, оптимизация запросов, планировщик запросов и т.д.) .. Знание PostgreSQL(9.x), .. Hibernate.
- Опыт работы с базами данным .. SQL, .. MongoDB, Spring Data Reactive.
- Опыт работы с БД SQL .. с MS SQL
- Разработка с использованием одной из следующих БД: PostgreSQL, MySQL, AWS DynamoDB, Amazon Aurora; Опыт оптимизации БД и запросов к БД (SQL или NoSQL).
Скажите, вот по вашему ощущению объективной реальности… слова «знание», «опыт», «использование» и «понимание» означают «я работал с базой только через ORM»? Есть ли у вас ощущение, что от бекендеров ожидается незнание SQL и баз данных? Как всё-таки будет понимать ваше резюме читатель, если это резюме бекендера и в нём упоминается «опыт с MySQL»?
Пролистал следующие десять вакансий подряд. Картина точно такая же. Более того, вакансия «Специалист по тестированию» включает в себя «знание SQL» даже не в дополнительных требованиях. Переведу: индустрия не ожидает от бекендера раздельного знания одной из трёх переменных выше. Если ты позиционируешь себя бекендером, ты должен знать фреймворк (да хоть JDBC) AND язык (SQL) AND базу данных (XxxSQL). Не OR из мечт о лёгкой работе. Именно AND.
Вернусь к началу и доведу до абсурда. 2018 год. Россия. Вакансия, состоящая лишь из слов «Java, middle+, backend». Резюме, состоящее лишь из слов «Java, backend, MySQL». Скажите (таки полистав HeadHunter), сколько всё-таки человек из нанимающих будут трактовать это как приглашение не знать базы данных и не знать SQL? Сколько всё-таки человек из нанимающихся на позицию middle+ будут под словом «MySQL»подразумевать незнание SQL и MySQL? Да, не ноль. Иначе бы не было этого эссе. Но и даже не один из десяти, что радует.