...ради 10 мс и экономии времени на чтение документации к ORM, готов писать не поддерживаемые запросы,...
проблема не в 10мс экономии. Проблема, когда вместо 10мс, запрос выполняется 15с (такой "фокус" был буквально на прошлой неделе). И разработчик не понимает, что происходит и как это починить, т.к. воспринимает всё что происходит в БД как магию.
"sql продолжит работать ибо стандарт" Увы, возьмём к примеру ms sql и postgresql - разница в синтаксисе существенная, особенно касательно встроенных функций. Это не считая всяких приколов "под капотом" типа вакуума, особенностей реализации временных объектов и т.д. и т.п. - об которые надо будет обязательно удариться головой.
"...вот вам запрос, выполняйте программисты мамкины... " А дальше появляется следующий забавный эффект: в коде появляется "магическое заклинание" от ДБА, которое команда разработки не понимает как и работает, и которое трогать без волшебника страшно. А потом ещё и ещё,...
"ORM автоматически подхватывает изменения в объектах и запросах." Тут есть знатный способ выстрелить себе в ногу. В некоторых БД из-за специфики организации данных на больших таблицах смена, к примеру, типа поля может быть очень ресурсоёмкой. В орм вы поменяете, на тесте, который "сильно урезан" по размерам, тоже будет всё ОК, а в проде в момент миграции всё ляжет.
Это очень критично, когда работаешь с нагруженной системой. Если ты пишешь на sql тебе надо знать, как то что ты делаешь будет, мапиться на планы запросов (конкретной СУБД, т.к. у каждой свои нюансы). Если ты работаешь с орм, когнитивная нагрузка резко повышается: ты должен сначала осознавать как то, что ты пишешь, будет мапиться в запрос, который потом будет мапиться в план запроса.
Усложнение приводит к тому, что разработчики с недостаточной квалификацией начинают воспринимать происходящее в БД слое как "магию": "Я вот жахнул и вот такое получилось. позовите ДБА, пусть сделает индекс какой".
Откуда взялись дополнительные 4 месяца? Из страха. Из ментальных ограничений. Команда добавила "буфер на всякий случай", потому что "с этим модулем всегда что-то идет не так".
0.Страх "чего"? Страх того, что не выполнишь задачу в срок и на ближайшем "перфоманс ревью" тебя этим будут бить больно по голове? :) Поэтому, когда в задаче много неизвестного, повышать сроки это логично.
В последние 6 месяцев команда отклонила амбициозные идеи со словами "это слишком сложно" до детального анализа...
1.Обычно на детальный анализ "сложного легаси" нужно много времени наиболее квалифицированного разработчика (а то и не одного, если задача масштабная), который и так перегружен. Если даже банально выделить их время на серьёзное исследование сложно, тогда при вносе в команду "амбициозной задачи" команда будет завышать сроки. А технический руководитель будет кивать прогнозу команды, т.к. если линейных разрабов "пожурят и лишат премии", то техруку снимут голову. Ещё рапространённый вариант, команде просто не дают время на ресёч: "амбициозную идею" притаскивают под занавес периода планирования со словами "сегодня, край завтра скажите сроки реализации" (ну и закоммитьтесь под этот срок, естественно). Результат - см. п.0
Реальный пример из финтеха: Джуниор инженер случайно удалил индекс в production базе. Боясь увольнения, он потратил 6 часов, пытаясь восстановить его втайне.
Что это за "финтех", если не секрет, в котором джун может лазать в админском режиме грязными руками в продовой базе? При чём "тайно".
Хотелось бы знать, чтобы случайно не воспользоваться "услугами" этой организации.
"Но при этом хочется сказать, что во всех компаниях есть испытательный срок, и обман достаточно легко вскрывается,"
Не надо надеяться на испытательный срок. Вы как нанимающий менеджер пропускаете время на адаптацию этого чела. положим это месяц. Дальше вам нужно тратить своё время, чтобы доказать что чел некомпетентен - если контора белая, а чел "опытный" - тот ещё гемор. Ну и потом вам надо начинать подбор заново - это время. В общем с квартальным планом завязаным на эту ставку пролетаем. оно надо? :)
В моем мировоззрении работодателю не нужен никакой высокопроизводительный качественный код от сеньора, а нужно стабильное решение бизнесовых проблем до финальной точки. А уж решается это через высокопроизводительный код или через подметание полов - это дело десятое.
Если мы говорим не полуподвальной конторе, где разработчик это автомотовелофототелерадиомонтёр, то между ним и бизнесом есть: продакт, аналитик, тимлид в конце концов. И они на вход выдают ему ТЗ на разработку. Если этого нет и разработчик получает на вход "нарисуй мне кунгуру" или "придумай чтобы на складе было чисто", это лишь говорит о качестве процессов разработки в конкретной организации. Конечно, он может съездить в поля, чтобы посмотреть что там вообще происходит или рассказать свой опыт на тему бизнеса, это только плюс для него. Но это прежде всего РАЗРАБОТЧИК. И он должен в первую очередь качественно выполнять свою основную функцию. Если он классно "трещит" с бизнесом, но для того чтобы закодить задачу ему надо изучать азы техстека компании, то он не на своём месте как разработчик.
"...Недавно я сходил на с десяток собеседований, и они меня очень сильно разочаровали...Максимум он специально для собеседования повторил..."
Очень странно, что человек проходил десяток собеседований и не обратил внимание, что требует текущий рынок труда. Тут сразу возникнут вопросы, а как он может "выяснить требования у бизнеса", если есть такие проблемы с коммуникацией? Уже если не после первого, так после второго собеса должен сформироваться список "что хочет рынок, что надо подтянуть".
"...И потом всё это реализовать на ЛЮБОМ языке программирования...Да, загуглит он, как создавать функции, классы и т.д. ..."
Штука в том, что "загуглит" - это как раз про джуна, тут работодатель не ожидает, что чел быстро войдёт в проект и обычно делает скидку на то что чел не сильно бьётся по техстеку. А вот сеньёр должен максимально быстро войти в проект и сразу писать высокопроизводительный качественный код на техстеке работодателя, а не гуглить "что такое бин в спринге". Исключение это обычно, когда работодатель понимает, что с рынка на свой экзотичный техстек никого не возьмёт.
"А ведь хорошая идея - попросить программиста написать бинарный поиск."
бинарный поиск это не КМП. А вот показать что ты не имея в памяти решения в общем то не самой сложной задачи можешь написать кодик - это большой плюс для соискателя.
"Но обычно бывает совершенно другая ситуация: приходишь на работу и слышишь: "Смотри, у нас тут есть табличка в БД, её надо вывести в CRM"."
А потом (реальный случай):
--У нас всё тормозит, нужен срочно ДБА. Х, сделай, чтонить, индекс там какой или типа того!
--Какой индекс, когда у вас тут все запросы вида "селект звёздочка фром табличка" и вся работа влючая фильтрацию на бэке?
"допиливать под довольно типовые задачи энтерпрайза" если у вас большая корпорация типа СберАвитоЗона, то все паттерны и типовые задачи с высокой степенью вероятностью за вас уже сделаны разработчиками "платформы". А вот избыточная вариативность скорее вредит: чем проще и "стандартнее" код, тем проще засунуть "на весло" новичка, чтобы он загребал жсоны в кафку.
PS есть опыт разгребания "разного" на c#, java, go - в общем гошный код читать легче, даже если он написан "наркоманами".
ИМХО, тут дело не только в классике "чем нам плох орм". В моей картине мира тимлид/сеньёр должен уметь "покрутить", поанализировать базейку запросами. Как свою, так и витринку в olap по своему домену. А они могут быть нетривиальными.
"...Вообще с чистым SQL в современном энтерпрайзе работают мало и редко... По моим ощущениям, им этот ответ не понравился, и в целом мне показалось, что оценили мои навыки в этой части низко..." Насколько я знаю, в озоне пользоваться ормами запрещено за исключением узкого круга ненагруженных админок. Так что "фи" на эту тему достаточно предсказуемо.
"Дистрибутив и библиотеки языка Hare полностью помещается на трёхдюймовой дискете" - Не уверен, что нонче большая часть разработчиков понимают, что такое "трехдюймовая дискета" и зачем она нужна. Так себе "киллерфича".
а как же "МАКС"? :)
проблема не в 10мс экономии. Проблема, когда вместо 10мс, запрос выполняется 15с (такой "фокус" был буквально на прошлой неделе). И разработчик не понимает, что происходит и как это починить, т.к. воспринимает всё что происходит в БД как магию.
вы часто заглядываете в стандарт что функционал функционал sql, который вы используете соответствует стандарту?
Готовы ли вы отказаться от частей языка, не соответствующих стандарту, чтобы гипотетически иметь возможность сменить субд?
"sql продолжит работать ибо стандарт"
Увы, возьмём к примеру ms sql и postgresql - разница в синтаксисе существенная, особенно касательно встроенных функций. Это не считая всяких приколов "под капотом" типа вакуума, особенностей реализации временных объектов и т.д. и т.п. - об которые надо будет обязательно удариться головой.
"...вот вам запрос, выполняйте программисты мамкины... "
А дальше появляется следующий забавный эффект: в коде появляется "магическое заклинание" от ДБА, которое команда разработки не понимает как и работает, и которое трогать без волшебника страшно. А потом ещё и ещё,...
"ORM автоматически подхватывает изменения в объектах и запросах." Тут есть знатный способ выстрелить себе в ногу. В некоторых БД из-за специфики организации данных на больших таблицах смена, к примеру, типа поля может быть очень ресурсоёмкой. В орм вы поменяете, на тесте, который "сильно урезан" по размерам, тоже будет всё ОК, а в проде в момент миграции всё ляжет.
Вот это самое прекрасное. В результате получаем кашу из orm и сырого sql. => и следующие плюшки "орм" сразу идут в топку:
возможность малотрудозатратной смены БД
парой кликов меняем тип/название поля
Это очень критично, когда работаешь с нагруженной системой. Если ты пишешь на sql тебе надо знать, как то что ты делаешь будет, мапиться на планы запросов (конкретной СУБД, т.к. у каждой свои нюансы).
Если ты работаешь с орм, когнитивная нагрузка резко повышается: ты должен сначала осознавать как то, что ты пишешь, будет мапиться в запрос, который потом будет мапиться в план запроса.
Усложнение приводит к тому, что разработчики с недостаточной квалификацией начинают воспринимать происходящее в БД слое как "магию": "Я вот жахнул и вот такое получилось. позовите ДБА, пусть сделает индекс какой".
0.Страх "чего"? Страх того, что не выполнишь задачу в срок и на ближайшем "перфоманс ревью" тебя этим будут бить больно по голове? :) Поэтому, когда в задаче много неизвестного, повышать сроки это логично.
1.Обычно на детальный анализ "сложного легаси" нужно много времени наиболее квалифицированного разработчика (а то и не одного, если задача масштабная), который и так перегружен. Если даже банально выделить их время на серьёзное исследование сложно, тогда при вносе в команду "амбициозной задачи" команда будет завышать сроки. А технический руководитель будет кивать прогнозу команды, т.к. если линейных разрабов "пожурят и лишат премии", то техруку снимут голову.
Ещё рапространённый вариант, команде просто не дают время на ресёч: "амбициозную идею" притаскивают под занавес периода планирования со словами "сегодня, край завтра скажите сроки реализации" (ну и закоммитьтесь под этот срок, естественно). Результат - см. п.0
Что это за "финтех", если не секрет, в котором джун может лазать в админском режиме грязными руками в продовой базе? При чём "тайно".
Хотелось бы знать, чтобы случайно не воспользоваться "услугами" этой организации.
авторский анекдот на эту тему:
-- почему так и не сделают до сих пор российский "национальный порновидеохостинг"?
-- в процессе. Сложности с интеграцией с: роскомнадзором, госуслугами и СОРМом.
"Но при этом хочется сказать, что во всех компаниях есть испытательный срок, и обман достаточно легко вскрывается,"
Не надо надеяться на испытательный срок. Вы как нанимающий менеджер пропускаете время на адаптацию этого чела. положим это месяц. Дальше вам нужно тратить своё время, чтобы доказать что чел некомпетентен - если контора белая, а чел "опытный" - тот ещё гемор. Ну и потом вам надо начинать подбор заново - это время. В общем с квартальным планом завязаным на эту ставку пролетаем. оно надо? :)
Если мы говорим не полуподвальной конторе, где разработчик это автомотовелофототелерадиомонтёр, то между ним и бизнесом есть: продакт, аналитик, тимлид в конце концов. И они на вход выдают ему ТЗ на разработку. Если этого нет и разработчик получает на вход "нарисуй мне кунгуру" или "придумай чтобы на складе было чисто", это лишь говорит о качестве процессов разработки в конкретной организации. Конечно, он может съездить в поля, чтобы посмотреть что там вообще происходит или рассказать свой опыт на тему бизнеса, это только плюс для него. Но это прежде всего РАЗРАБОТЧИК. И он должен в первую очередь качественно выполнять свою основную функцию. Если он классно "трещит" с бизнесом, но для того чтобы закодить задачу ему надо изучать азы техстека компании, то он не на своём месте как разработчик.
Очень странно, что человек проходил десяток собеседований и не обратил внимание, что требует текущий рынок труда. Тут сразу возникнут вопросы, а как он может "выяснить требования у бизнеса", если есть такие проблемы с коммуникацией? Уже если не после первого, так после второго собеса должен сформироваться список "что хочет рынок, что надо подтянуть".
Штука в том, что "загуглит" - это как раз про джуна, тут работодатель не ожидает, что чел быстро войдёт в проект и обычно делает скидку на то что чел не сильно бьётся по техстеку. А вот сеньёр должен максимально быстро войти в проект и сразу писать высокопроизводительный качественный код на техстеке работодателя, а не гуглить "что такое бин в спринге". Исключение это обычно, когда работодатель понимает, что с рынка на свой экзотичный техстек никого не возьмёт.
бинарный поиск это не КМП. А вот показать что ты не имея в памяти решения в общем то не самой сложной задачи можешь написать кодик - это большой плюс для соискателя.
А потом (реальный случай):
--У нас всё тормозит, нужен срочно ДБА. Х, сделай, чтонить, индекс там какой или типа того!
--Какой индекс, когда у вас тут все запросы вида "селект звёздочка фром табличка" и вся работа влючая фильтрацию на бэке?
"допиливать под довольно типовые задачи энтерпрайза" если у вас большая корпорация типа СберАвитоЗона, то все паттерны и типовые задачи с высокой степенью вероятностью за вас уже сделаны разработчиками "платформы". А вот избыточная вариативность скорее вредит: чем проще и "стандартнее" код, тем проще засунуть "на весло" новичка, чтобы он загребал жсоны в кафку.
PS есть опыт разгребания "разного" на c#, java, go - в общем гошный код читать легче, даже если он написан "наркоманами".
ИМХО, тут дело не только в классике "чем нам плох орм". В моей картине мира тимлид/сеньёр должен уметь "покрутить", поанализировать базейку запросами. Как свою, так и витринку в olap по своему домену. А они могут быть нетривиальными.
"...Вообще с чистым SQL в современном энтерпрайзе работают мало и редко... По моим ощущениям, им этот ответ не понравился, и в целом мне показалось, что оценили мои навыки в этой части низко..."
Насколько я знаю, в озоне пользоваться ормами запрещено за исключением узкого круга ненагруженных админок. Так что "фи" на эту тему достаточно предсказуемо.
Хороший повод не давать жене карточку "на реснички". Давно ждали такой закон.
PS Интересно как будут обходить "опа, да я ж потерял карточку! спасибо что нашли! Люблю родную милицию!"
"Дистрибутив и библиотеки языка Hare полностью помещается на трёхдюймовой дискете" - Не уверен, что нонче большая часть разработчиков понимают, что такое "трехдюймовая дискета" и зачем она нужна. Так себе "киллерфича".