Post #249

Я уже тут как-то ссылался на Григория Добрякова, архитектора и ИТ-менеджера, очень люблю его посты про индустрию. Вот и опять: Такая боль у кандидатов с моделированием данных, вы бы знали! Даже не знаю у кого больнее: у системных аналитиков или у разработчиков. Я на собесах тупо начинаю с одной простой задачи: допустим, делаем микросервис, заказчик хочет в него положить данные о людях (ФИО) и городах (название), а также данные о том кто в каком городе родился, в каком учился, женился, работал, и так далее. И зачастую мы даже это смоделировать не можем. Disclaimer: сразу обозначу, что мы сначала уделяем много времени смолл-толку, разбалтываем кандидата, и я всегда вежливо уточняю «будет ли тебе комфортно сейчас поговорить о...» Но тем не менее! Половина кандидатов, даже с тимлидским опытом за плечами, вообще не слышат условий и начинают рассказ с выбора способа авторизации в админку. Что? А вот. Другие начинают рассказывать о том, что они сделают таблицу с заказами и положат туда информацию о покупках. Каких блин покупках?? А вот. Это же у нас покупатели, верно? Значит у них покупки... (никакие покупки в задаче не звучали) Абсолютное большинство в упор не может ответить на вопрос «давай всё же перечислим, какие у нас будут столбцы?».. Вести человека к варианту ответа «давайте для начала сделаем одну табличку на три столбца для фамилии, имени и отчества» приходится за ручку. И ради бога не стоит задавать вопрос «а как вы эту табличку назовёте». Я раньше задавал. На реляции с городами умирают все. За буквально годы задавания этой задачки я могу по пальцам перечислить людей, которые поставили посередине транзитивную таблицу из трёх столбцов «человек — город — тип отношения». Абсолютное большинство лепят дополнительные столбцы к табличке людей. И на мой следующий вопрос «хорошо, а теперь давайте сохраним информацию о том, в каком году человек там родился, в каком учился, в каком женился» — лепят ещё столбцы с годами. Не видя никаких проблем. Люди с 15 годами опыта Senior System Analyst. Люди с опытом тимлидства и проектирования архитектуры в резюме. Ноль сомнений. Последний раз я не выдержал и закруглил беседу, когда человек предложил положить информацию о городах в json в атрибуты человеков. Не как денормализованный кэш, а именно основные данные. А потом я их добиваю вопросом как к этому всему приделать REST API. Например, какие методы нужны для удаления информации о том, что некий Вася Пупкин жил в Москве с 2010 по 2012 год. Канонический REST, ага. Вы ж в резюме заявляли? — Ну это будет метод DELETE! — уверенно заявляет кандидат, но дальше вспоминает свою же структуру данных и начинает жалеть что вообще вписался в этот разговор. Нет, справедливости ради, встречаются жемчужины с которыми интересно разбирать нюансы и подсказывать куда можно копнуть. Но с остальными то что не так? В моей практике, изучение любого фреймворка в программировании всегда начиналось с ORM. Подробно разбиралось, как организовать данные, построить между ними реляции, открыть их во внешнее API с помощью контроллеров и предоставить элементарный CRUD-интерфейс. Да, можно критиковать ORM как инструмент, но в такой картине мира любой микросервис проектируется за пару чашек кофе. Логическую цепочку «Domain model — ERD — модели — реляции — ресурсы — CRUD API — унифицированные интеграции — низкие косты» не видит в принципе никто. Зато поп*здеть на тему REST vs GraphQL готов каждый второй, ага. Когда всё поломалось в этом мире? Что программируют эти программисты? Что проектируют эти блин системные аналитики? Ребята, а если у меня проект на 200+ классов предметной области (бывало), а мы тут с вами в двух путаемся, то что дальше будет? Что блин не так то?