Хороший вопрос :) На мой взгляд, интерфейсы WebCrypto API - это не оверинжиниринг, а скорее отражение специфики криптографии как области: здесь важна четкая типизация, строгая спецификация и безопасность. Архитектура может казаться "перегруженной" по сравнению с повседневным кодом, но это обосновано
Оверинжиниринг - это скорее когда абстракции не решают реальных задач, а только усложняют чтение и поддержку кода. В WebCrypto API почти каждый слой, насколько я видел, обоснован конкретными требованиями: безопасностью, платформенной независимостью, поддержкой разных алгоритмов и ключевых хранилищ
Добрый день!Благодарю за комментарий и дельные замечания.
В статье постарался дать "точку старта" - наиболее актуальные и востребованные технологии на рынке, чтобы сэкономить время новичкам на этапе выбора. Конечно, стек в каждой компании свой, и это требует последующей адаптации, без этого никуда) Перечислить все технологии все равно не получится, что-то придется ресерчить самому
По поводу ChatGPT - полностью поддерживаю. Это отличный инструмент, который могжет сильно ускорить обучение новичкам. Да и будем честны, каким бы крутым инженером ты не был, рутину скинуть на ChatGPT и AI ассистентов никогда не помешает
Да, согласен - assertEqual или матчеры дают более наглядный вывод. В Python для юнитов используют unittest.TestCase.assertEqual или либу hamcrest, которая позволяет писать тесты с читаемыми проверками
В статье показан самый базовый пример с обычным assert, но для реальных проектов возможно стоит задуматься о каком-то централизованном решении сразу.
У вас отличное воображение, особенно про "автор сам бы не справился" :)
Вопросы из статьи - это не "ширма", а реально базовые вещи, с которыми сталкивается любой, кто пишет на Python дольше пары недель. Да, они концептуальные, а не практико-ориентированные в стиле "напиши API за 5 минут", но цель статьи как раз показать разрыв между заявленным опытом и знанием основ.
Минусы в основном от людей, которых такие вопросы на собеседованиях когда-то ставили в тупик, и сейчас они воспринимают это как личное нападение. Многие просто привыкли к собесам "за жизнь" и очень не любят проверки базовых знаний.
Вы абсолютно правы - раньше многие шли в профессию именно через понимание языка и постепенное накопление опыта.
Сейчас часто встречается обратный подход: "хочу сразу работать и получать высокий доход", а разбираться в фундаментальных вещах начинают уже "по ходу". При этом никто не против фреймворков или готовых решений, но важно иметь базу - это снижает количество ошибок и делает работу быстрее и надежнее.
Ваш подход, честно говоря, оставляет желать лучшего :) Это как заучивать ответы к каждому квадратному уравнению, вместо того чтобы понять, как они решаются.
Смысл таких вопросов не в том, чтобы встречать их "в боевом коде", а в том, чтобы проверить понимание механики языка - чтобы в реальной работе человек не делал неожиданных ошибок из‑за неверных предположений.
Кажется, вы сильно гиперболизируете и додумываете за автора :) Это не код из продакшена и не образец стиля - это проверка базовых конструкций языка, которые встречаются практически в любом учебнике по Python. И да, хорошая практика - уметь объяснить, что делает даже "плохой" код. Потому что в реальности на ревью или при поддержке legacy приходится разбираться и с более жёсткими примерами. А потом их переписывать, на что-то нормальное
Но задачи из статьи как раз максимально простые и близкие к практике: comprehension, аргументы по умолчанию, базовое наследование. Если это уже считается "жабогадюкингом", то, видимо, Python действительно сильно изменился за последние годы.
Вы сильно гиперболизируете и многое додумываете :)
Откуда вы знаете, какой код я пишу и какая атмосфера в команде? В статье речь не про стиль написания кода в продакшене, а про базовые знания языка и умение их применять
Джунам всегда было сложно, это вечная тема для обсуждений. И неадекватные требования работодателей также отдельная боль, писал про это в другой статье https://habr.com/ru/articles/886552/
Благодарю за ваш комментарий! Тема с компаниями и их неадекватными требованиями это отдельная боль, писал про это в другой статье https://habr.com/ru/articles/886552/
Спасибо всем, кто высказался - и тем, кто согласен, и тем, кто не согласен. Судя по реакции, статья задела за живое, и это нормально :)
Да, задачи в статье - базовые, но сама форма "что выведет код" вызывает у многих ощущение "подвоха" и ассоциируется с собесами, которые больше напоминают проверку на память, чем оценку инженерных навыков. Возможно, это и стало основной причиной негатива.
Цель текста была не "разоблачить кандидатов" и не "похвастаться сложными вопросами", а показать, как накрученный опыт легко вскрывается на простых примерах. Понимаю, что заголовок и подача получились провокационными и могли усилить эффект.
Спасибо за обратную связь - она помогает увидеть статью глазами других и понять, какие темы особенно триггерят сообщество.
Олимпиадные задачи как раз проверяют "извилины" и умение искать нестандартные решения :)
А вот "вопросы за жизнь" чаще показывают только опыт разговоров и терминов, услышанных где-то в коридоре, но не обязательно реальное понимание сути. Поэтому и нужны простые вопросы на базу - чтобы понять, есть ли фундаментальное понимание, а не только набор красивых слов.
Хороший вопрос :) На мой взгляд, интерфейсы WebCrypto API - это не оверинжиниринг, а скорее отражение специфики криптографии как области: здесь важна четкая типизация, строгая спецификация и безопасность. Архитектура может казаться "перегруженной" по сравнению с повседневным кодом, но это обосновано
Оверинжиниринг - это скорее когда абстракции не решают реальных задач, а только усложняют чтение и поддержку кода. В WebCrypto API почти каждый слой, насколько я видел, обоснован конкретными требованиями: безопасностью, платформенной независимостью, поддержкой разных алгоритмов и ключевых хранилищ
Добрый день! Благодарю за комментарий и дельные замечания.
В статье постарался дать "точку старта" - наиболее актуальные и востребованные технологии на рынке, чтобы сэкономить время новичкам на этапе выбора. Конечно, стек в каждой компании свой, и это требует последующей адаптации, без этого никуда) Перечислить все технологии все равно не получится, что-то придется ресерчить самому
По поводу ChatGPT - полностью поддерживаю. Это отличный инструмент, который могжет сильно ускорить обучение новичкам. Да и будем честны, каким бы крутым инженером ты не был, рутину скинуть на ChatGPT и AI ассистентов никогда не помешает
Благодарю за комментарий и за то, что поделились своим опытом!
Да, согласен -
assertEqualили матчеры дают более наглядный вывод. В Python для юнитов используютunittest.TestCase.assertEqualили либу hamcrest, которая позволяет писать тесты с читаемыми проверкамиВ статье показан самый базовый пример с обычным
assert, но для реальных проектов возможно стоит задуматься о каком-то централизованном решении сразу.Кажется, вы больше оцениваете не статью, а свои эмоции к ее стилю :)
У вас отличное воображение, особенно про "автор сам бы не справился" :)
Вопросы из статьи - это не "ширма", а реально базовые вещи, с которыми сталкивается любой, кто пишет на Python дольше пары недель. Да, они концептуальные, а не практико-ориентированные в стиле "напиши API за 5 минут", но цель статьи как раз показать разрыв между заявленным опытом и знанием основ.
Согласен, ваш комментарий действительно по делу!
Минусы в основном от людей, которых такие вопросы на собеседованиях когда-то ставили в тупик, и сейчас они воспринимают это как личное нападение. Многие просто привыкли к собесам "за жизнь" и очень не любят проверки базовых знаний.
Спасибо за конструктивный комментарий!
Вы абсолютно правы - раньше многие шли в профессию именно через понимание языка и постепенное накопление опыта.
Сейчас часто встречается обратный подход: "хочу сразу работать и получать высокий доход", а разбираться в фундаментальных вещах начинают уже "по ходу". При этом никто не против фреймворков или готовых решений, но важно иметь базу - это снижает количество ошибок и делает работу быстрее и надежнее.
Ваш подход, честно говоря, оставляет желать лучшего :) Это как заучивать ответы к каждому квадратному уравнению, вместо того чтобы понять, как они решаются.
Смысл таких вопросов не в том, чтобы встречать их "в боевом коде", а в том, чтобы проверить понимание механики языка - чтобы в реальной работе человек не делал неожиданных ошибок из‑за неверных предположений.
Кажется, вы сильно гиперболизируете и додумываете за автора :) Это не код из продакшена и не образец стиля - это проверка базовых конструкций языка, которые встречаются практически в любом учебнике по Python. И да, хорошая практика - уметь объяснить, что делает даже "плохой" код. Потому что в реальности на ревью или при поддержке legacy приходится разбираться и с более жёсткими примерами. А потом их переписывать, на что-то нормальное
"Жабогадюкинг" - это сильно :)
Но задачи из статьи как раз максимально простые и близкие к практике: comprehension, аргументы по умолчанию, базовое наследование. Если это уже считается "жабогадюкингом", то, видимо, Python действительно сильно изменился за последние годы.
LLM говнокодит на любом существующем ЯП
Вы сильно гиперболизируете и многое додумываете :)
Откуда вы знаете, какой код я пишу и какая атмосфера в команде? В статье речь не про стиль написания кода в продакшене, а про базовые знания языка и умение их применять
Благодарю за ваш комментарий!
Джунам всегда было сложно, это вечная тема для обсуждений. И неадекватные требования работодателей также отдельная боль, писал про это в другой статье https://habr.com/ru/articles/886552/
Это ведь не примеры из реального продакшн-кода :) Для этого есть другие секции собеса
Это именно проверка на понимание основ синтаксиса и поведения языка, чтобы убедиться, что человек уверенно работает с Python.
Благодарю за ваш комментарий! Тема с компаниями и их неадекватными требованиями это отдельная боль, писал про это в другой статье https://habr.com/ru/articles/886552/
Ооо, вы еще настоящие олимпиадные задачки не видели :)
Где-то возможно спрашивают, почему бы и нет? :)
Спасибо всем, кто высказался - и тем, кто согласен, и тем, кто не согласен. Судя по реакции, статья задела за живое, и это нормально :)
Да, задачи в статье - базовые, но сама форма "что выведет код" вызывает у многих ощущение "подвоха" и ассоциируется с собесами, которые больше напоминают проверку на память, чем оценку инженерных навыков. Возможно, это и стало основной причиной негатива.
Цель текста была не "разоблачить кандидатов" и не "похвастаться сложными вопросами", а показать, как накрученный опыт легко вскрывается на простых примерах. Понимаю, что заголовок и подача получились провокационными и могли усилить эффект.
Спасибо за обратную связь - она помогает увидеть статью глазами других и понять, какие темы особенно триггерят сообщество.
Олимпиадные задачи как раз проверяют "извилины" и умение искать нестандартные решения :)
А вот "вопросы за жизнь" чаще показывают только опыт разговоров и терминов, услышанных где-то в коридоре, но не обязательно реальное понимание сути. Поэтому и нужны простые вопросы на базу - чтобы понять, есть ли фундаментальное понимание, а не только набор красивых слов.