Я сейчас как раз ищу себе новую работу, и работодатели жутко бесят этими своими "у нас гибрид, 3 дня в неделю можно работать из дома". Культура у них такая, видите ли. Я таких сразу нафиг посылаю. Я работу работаю? Да. Задачи закрываю? Да. Ну тогда и все, как, где и в какой форме я это делаю, не должно никого волновать. Во-первых, я хочу не сидеть в городе, а иметь возможность уехать куда-нибудь, хоть в другой город, хоть на дачу, хоть в другую страну. Во-вторых, у меня дома шикарное рабочее место, такое, как удобно лично мне, и ни один офис не сумеет предоставить такое же качество. В-третьих, в течении дня у меня есть возможность заняться какими-то своими делами, чего я не могу сделать, посещая офис. Ну и да, просыпаться раньше и тратить время на дорогу до офиса утром и на дорогу домой вечером мне тоже как-то не вперлось. К сожалению, многие работодатели страдают желанием контролировать все на свете, ну да и пофиг, нормальные тоже существуют, просто придётся поискать чуть дольше
ну, то есть мы пришли к тому, с чего начинали, что есть люди, которые плохо умеют делать свою работу, что-то не знают/не умеют, и не умеют в те инструменты, которые даже им дали. Не то чтобы очень сложная мысль. "Чистый код"-то в чем в этом случае виноват, что есть люди, которые не умеют нормально в программирвание?
ну, то есть мы сошлись на том, что идеи там разумные, так получается? В таком случае я повторю свой вопрос ранее: лучше все-таки показывать разумные идеи джунам, пусть даже имплементация может и хромать (может, а не хромает обязательно), или если мы не согласились с какими-то отдельными моментами в книге, то отбрасываем вообще все и пускай джуны исключительно на своих ошибках учатся?
нет, не лучше. Я не знаю, какой у тебя опыт работы на разных проектах, но мне вот довелось поработать на галерах с разными людьми на разных проектах, и вот там даже тимлиды были сами себе художники. Худших проектов в моей жизни не было, хотя некоторые проекты создавались с нуля и были маленькими и простыми по сути, но даже так они умудрялись быть хуже и менее поддерживаемыми, чем некоторые 10-летние легаси
да елки-палки. Какая разница, как программирует сам Мартин? Мы оцениваем аргументы/мнение/позицию/etc., а не человека за ними. Вот ты уперся в эти функции по 5 строк, ты ситх, что ли? Либо функция в 5 строк и никак иначе, либо выкидываем "Чистый код" в помойку, так, что ли? Или мы все-таки согласимся, что короткие функции с явно определенной целью, без побочных эффектов, с говорящим названием и так далее - это хорошо?
Мой пойнт состоит в том, что советы и рекомендации в "Чистом коде" крайне здоровые и полезные. Да - не все одинаково полезные, некоторые, как минимум в той форме, в которой предложены, спорны. Но считать из-за этого, что вся книжка целиком бесполезна - это глупо и вредно. Дилемма, может, и надумання, и вообще как писали классики "при безальтернативном выборе из двух взаимоисключающих вариантов оба обязательно будут представлять из себя несусветную хрень", и, тем не менее, она позволяет в какой-то мере протестировать все эти советы в воображении. Я вот предпочту функции по 5 строк, чем полотна кода (а я видел такое)
Если выбирать из двух крайностей: полное отсутствие каких-либо советов и рекомендаций, как писать код, и пусть каждый будет сам себе художник, либо фанатичное следование советам "чистого кода" всеми программистами, то ты в какой из этих двух реальностей хотел бы жить?
Только вот кроме самопревозглашенных умений пользоваться чем-либо, что вызывает изрядную долю скепсиса у многих читателей статьи, ты не приводишь никаких иных аргументов
А, царь-батюшка, нижайше прошу простить холопа, не соизволите ли ВЫ все-таки уделить минуту своего времени и прочитать простыню? А то как-то странно получается, кидаться какашками в оппонента у ВАС время находится, а вести диалог по существу нет
Но я не в мегафон ночью орал, а отвечал вот на этот облыжный тезис: «маловероятно, что у него была возможность практически оценить полезность общепринятых в ООП подходов к разработке».
Ну так то предположение одновременно сделано несколькими людьми на основе той информации, что ты даешь в статье. Ты же не только не доказываешь обратное, ты зачем-то приводишь в принципе невалидные аргументы
И инкапсулировать классами ничуть не лучше, чем функциями. Поэтому, в принципе, я и говорил, что мапа ничем не хуже инстанса класса.
Я не работал с функциональными языками. Мне знакомы принципы и подходы, и тем не менее, опыта работы именно с языками у меня нет. Могу допустить, что там есть какие-то свои best practises и все такое, но в оопешном мире выносить логику из класса, где она должна быть, в отдельные функции - это плохо. Ну а про чем мапа хуже класса мне по существу добавить нечего к той дискуссии, на которую есть ссылка выше. Если тебе нравится ловить runtime exception-ы в проде вместо того, что твой код просто не скомпилится, то кто я такой, чтобы ограничивать тебя в твоих развлечениях
Мой тезис заключается в том, что в «оопешности кода» нет ровным счетом никаких преимуществ
Если не уметь пользоваться инструментом, то его эффективность и применимость будут сомнительные, я согласен
То, что это очень показательная характеристика как раз инфоцыган - голословно что-то утверждать, в качестве аргументов в лучшем случае приводить какой-нибудь черипикинг, а когда ты задаёшь неудобный для них вопрос, вместо ответа получаешь агрессию. Не, если целью всей статьи и комментариев потом является маркетинговая прокачка своей онлайн-активности, то стратегия довольно успешная. Однако с точки зрения обсуждения вопроса, поднятого в статье, получается какая-то фигня
Неумение пользоваться инструментом не является виной инструмента, но больше всего и чаще всего на инструмент ругаются как раз те люди, которые не умеют им пользоваться
11 слов агрессии вместо одного простого ответа по существу "да" или "нет". Делаю вывод, что по существу ответить нечего, и с вопросом я попал в самую суть
Я больше десяти лет работал в энтерпрайзах от КОБОЛа и С++ до джавы.
А каким образом опыт работы в энтерпрайзе является аргументом в пользу умения и понимания ООП? И причём тут вообще кобол - язык, на секундочку, вообще изобретенный до появления ООП?
Как же ваши любимые паттерны, а именно — инкапсуляция?
Ну так в том-то и дело, что если у нас логика работы с данными инкапсулирована, то это и есть то одно место, где следует вносить изменения, а не вычитывать весь проект, выискивая все те места, которые вместо объекта с инкапсулированной логикой используют объект исключительно как fancy-версию мапы
Ну и вообще, я много раз говорил ранее и повторю сейчас - даже если обмазать код ключевыми словами ооп-синтаксиса типа "класс", "интерфейс" и так далее, то само по себе это не делает код оопешным. Вполне может получиться обычная процедурщина, только с ооп-синтаксисом, и уж точно не вина инструмента в том, что им не умеют пользоваться
А вот мне стало интересно, автор, ты когда-нибудь работал на одном и том же проекте длительное время? Не так чтобы полгода задачи с борда закрывать, а вот прям дизайнить архитектуру, писать код, релизить, саппорить, исправлять свои же косяки, etc. А то, поработав на разных проектах с разными людьми, в том числе с фрилансерами, а также на разного рода галерах, где на одном проекте люди постоянно меняются, у меня начинает складываться впечатление, что именно такие люди максимально наплевательски относятся к качеству кода, и пишут лишь бы работало, совершенно не заботясь о читаемости, поддерживаемости, расширяемости и т.д.
Теперь давай по пунктам пройдемся:
1) "Чистый код экономит время в долгосрочной перспективе" - да, это так. Потому что сложность имеет тенденцию со временем увеличиваться. И если что-то сейчас сделать тяп-ляп, лишь бы работало, а потом это не исправить, а оставить как есть, то через время это тяп-ляп имеет возможность превратиться в такой снежный ком неподдерживаемого переплетенного хтонического ужаса, что трогать будет уже просто страшно (особенно если нет тестов, но о них мы позже поговорим). Разумеется, каждому из нас приходилось писать костыли, потому что фикс нужен срочно, но на мой взгляд достаточно очевидно, что такой костыль следует исправить ASAP как будет возможность, а не копить тех долг где-то в бэклоге
2) "Названия должны быть самодокументирующими" - да, это так. Твой пример с UserAccountManagerFactoryBuilderSingleton тут не подходит, так как это пример плохого и не говорящего названия, слепленного из дженерик терминов. В идеале названия должны быть лаконичными и говорящими. Не всегда получается, разумеется, достичь идеала, но это не повод ведь теперь все бросить и начать называть переменные и методы абы как, верно? А если переимнование чего-либо ведет к тому, что это ломает не то что половину проекта, а хоть что-то, то... я даже хз, что надо было делать предварительно в этом проекте, чтобы ренейминг что-либо ломал. Расскажи, что ли, мне действительно интересно
3) "Функции должны быть короткими" - ну, тут соглашусь. Гнаться за коротковизной как самоцелью - так себе идея, в жизни всякое бывает, в том числе сложная логика. Тем не менее, лучше короткие функции с явно выраженной целью, понятным образом трансформирующие какие-то входные аргументы на какой-то результат, которые можно протестировать, чем полотна кода на несколько экранов
4) "Комментарии — признак плохого кода" - комментарии бывают разные. Пояснять какие-то решения - это нормально. Например, Javadoc - это тоже комментарии, и предполагается, что это высокоуровневые комментарии, которые поясняют, для чего нужен класс или метод в целом. Если же код нуждается в комментариях, чтобы понять каждую отдельную строку этого кода - то таки да, это плохой код и плохие комментарии
5) "Don’t Repeat Yourself" - да, это так. Не знаю уж как ты, автор, а я заколебался на разных проектах ковырять одну и ту же логику в разных местах, потому что программист, который ее писал, просто шлепал код как есть, не думая вообще про вынесение в общие методы. А потом еще обнаруживается, что этот человек даже с копипастой справиться нормально не сумел, поэтому в разных местах есть расхождения (и не потому, что они реально должны быть), и саппорт, дебаг и исправление ошибок превращается в натуральную пытку
6) "Тесты делают код чище" - ДА, ДА, ДА. Опять же, я готов понять, если человек пришел на проект на пару месяцев, и ему вообще пофигу как на качество кода, так и на будущий саппорт проекта. Но я вообще не понимаю, как можно настолько себя не любить, что если ты сам работаешь на проекте, и ты же развиваешь этот код, и ты же его саппортишь, чтобы не писать тесты. Тесты как минимум позволяют безопасно делать рефакторинг в будущем, как максимум - защищают от багов в проде, с которыми к тебе же и придут, чтобы ты разбирался и чинил. Работал я как-то с одним придурковатым тимлидом, который код проверял мануально, а потом запрещал трогать что-либо, потому что никаких гарантий, что изменения ничего не сломают, у него не было. Разумеется, тесты не панацея и не защитят на 100%, но это не повод от них отказываться
7) "SOLID принципы решают все проблемы" - никогда ранее не слышал подобных утверждений. SOLID - это набор рекомендаций, как писать правильный ООП-код. Рекомендаций, а не строгих правил, и разумеется их можно нарушать, но для начала неплохо бы все-таки понимать эти принципы, чтобы как раз понимать, что и когда уместно нарушать, а что лучше нет
Вообще, ни одно правило "чистого кода" не стоит воспринимать абслютно. Как вообще ни одно правильно не следует воспринимать. Все они придуманы для решения или недопускания определенных проблем. Квалификация программиста заключается в том числе в том, чтобы понимать, с какими проблемами он имеет дело в данный момент, и согласно ситуации выбирать и абстракции, и конкретные решения
Да нет. Пиши так и столько, как и сколько хочется. Я в такой задаче не строгая учительница, которая линейкой по пальцам бьёт за ошибки, я лишь наблюдаю за мыслительным процессом, и если он состоит в итеративном приближении к ответу, то и ладно, мне норм. Процесс завершится либо когда будет заявлено, что готово, либо когда кандидат сдастся, ну либо могу прервать досрочно, если время будет кончаться
Если какие-то другие интервьюеры косплеят училок, то, ну, пусть идут в баню
Это набор ничего не значащих вопросов, ответы на которые прекрасно даёт chatgpt. Для чего в этом процессе нужен собеседуемый? Чтобы косплеить прокси? У интервьюера vpn не работает и он сам в ai не может вопрос написать?
Имхо, если в компании есть принятый стек технологий, то знать и уметь работать надо именно с этим стеком, и совершенно нет никакой разницы, что там ещё нового в мире придумали. И проверять надо не теоретическое знание каких-то технологий и версий, а в целом умение человека думать, анализировать и т.д. (что - сюрприз - гораздо лучше видно на решении задач, а не на отвечании на вопросы). Я вот встречал людей, которые вызубрили какие-то определенные технологии или фреймворки, но ни шага за их пределами не умеют. Условно, метод findById в spring data они умеют писать, а отбери у них spring, и простое "select * from ... where id=..." они не в состоянии. И толку мне от такого разработчика, пусть даже он офигенно шарит в самых новых версиях spring data?
А для меня необходимый обряд - это просто пройти пару собесов для разминки, и в целом уметь отвечать на фундаментальные вопросы, и по моему личному опыту мои знакомые делают именно так. Ну так и чей личный опыт более опытный?
Это отличная задача для лайф кодинга. У меня, кстати, была именно такая на последнем собесе, я с огромным удовольствием с ней поигрался на интервью
1) подготовить пустой проект с нужными зависимостями - это в худшем случае вопрос примерно 5 минут. К тому же его можно подготовить перед самим собесом
2) для такой задачи не нужны никакие миграции, нужен функционал, который можно дернуть условным Postman и посмотреть на ответ
3) навскидку нужны примерно 5 классов: контроллер, сервис, репозиторий, класс-dto и класс-entity (если мы в мире java). Этого уже достаточно, чтобы понять, понимает ли человек, что он делает, и как планировать архитектуру. Если очень хочется выпендпиться, то можно добавить mapstruct маппер, но это уже прямо роскошный максимум
4) да пофиг, если даже проект не запустится. Опять же, по одному только процессу создания и обсуждения всего вышеперечисленного уже понятно, что человек знает и умеет
Где-то примерно полчаса, наверное, такое и займёт. Отличная задача, в общем
Я сейчас как раз ищу себе новую работу, и работодатели жутко бесят этими своими "у нас гибрид, 3 дня в неделю можно работать из дома". Культура у них такая, видите ли. Я таких сразу нафиг посылаю. Я работу работаю? Да. Задачи закрываю? Да. Ну тогда и все, как, где и в какой форме я это делаю, не должно никого волновать. Во-первых, я хочу не сидеть в городе, а иметь возможность уехать куда-нибудь, хоть в другой город, хоть на дачу, хоть в другую страну. Во-вторых, у меня дома шикарное рабочее место, такое, как удобно лично мне, и ни один офис не сумеет предоставить такое же качество. В-третьих, в течении дня у меня есть возможность заняться какими-то своими делами, чего я не могу сделать, посещая офис. Ну и да, просыпаться раньше и тратить время на дорогу до офиса утром и на дорогу домой вечером мне тоже как-то не вперлось. К сожалению, многие работодатели страдают желанием контролировать все на свете, ну да и пофиг, нормальные тоже существуют, просто придётся поискать чуть дольше
ну, то есть мы пришли к тому, с чего начинали, что есть люди, которые плохо умеют делать свою работу, что-то не знают/не умеют, и не умеют в те инструменты, которые даже им дали. Не то чтобы очень сложная мысль. "Чистый код"-то в чем в этом случае виноват, что есть люди, которые не умеют нормально в программирвание?
ну, то есть мы сошлись на том, что идеи там разумные, так получается? В таком случае я повторю свой вопрос ранее: лучше все-таки показывать разумные идеи джунам, пусть даже имплементация может и хромать (может, а не хромает обязательно), или если мы не согласились с какими-то отдельными моментами в книге, то отбрасываем вообще все и пускай джуны исключительно на своих ошибках учатся?
нет, не лучше. Я не знаю, какой у тебя опыт работы на разных проектах, но мне вот довелось поработать на галерах с разными людьми на разных проектах, и вот там даже тимлиды были сами себе художники. Худших проектов в моей жизни не было, хотя некоторые проекты создавались с нуля и были маленькими и простыми по сути, но даже так они умудрялись быть хуже и менее поддерживаемыми, чем некоторые 10-летние легаси
да елки-палки. Какая разница, как программирует сам Мартин? Мы оцениваем аргументы/мнение/позицию/etc., а не человека за ними. Вот ты уперся в эти функции по 5 строк, ты ситх, что ли? Либо функция в 5 строк и никак иначе, либо выкидываем "Чистый код" в помойку, так, что ли? Или мы все-таки согласимся, что короткие функции с явно определенной целью, без побочных эффектов, с говорящим названием и так далее - это хорошо?
Мой пойнт состоит в том, что советы и рекомендации в "Чистом коде" крайне здоровые и полезные. Да - не все одинаково полезные, некоторые, как минимум в той форме, в которой предложены, спорны. Но считать из-за этого, что вся книжка целиком бесполезна - это глупо и вредно. Дилемма, может, и надумання, и вообще как писали классики "при безальтернативном выборе из двух взаимоисключающих вариантов оба обязательно будут представлять из себя несусветную хрень", и, тем не менее, она позволяет в какой-то мере протестировать все эти советы в воображении. Я вот предпочту функции по 5 строк, чем полотна кода (а я видел такое)
Если выбирать из двух крайностей: полное отсутствие каких-либо советов и рекомендаций, как писать код, и пусть каждый будет сам себе художник, либо фанатичное следование советам "чистого кода" всеми программистами, то ты в какой из этих двух реальностей хотел бы жить?
Только вот кроме самопревозглашенных умений пользоваться чем-либо, что вызывает изрядную долю скепсиса у многих читателей статьи, ты не приводишь никаких иных аргументов
Ну, то есть по всем моим аргументам выше, 100% попадание в инфоцыгана :)
А, царь-батюшка, нижайше прошу простить холопа, не соизволите ли ВЫ все-таки уделить минуту своего времени и прочитать простыню? А то как-то странно получается, кидаться какашками в оппонента у ВАС время находится, а вести диалог по существу нет
Ну так то предположение одновременно сделано несколькими людьми на основе той информации, что ты даешь в статье. Ты же не только не доказываешь обратное, ты зачем-то приводишь в принципе невалидные аргументы
Я не работал с функциональными языками. Мне знакомы принципы и подходы, и тем не менее, опыта работы именно с языками у меня нет. Могу допустить, что там есть какие-то свои best practises и все такое, но в оопешном мире выносить логику из класса, где она должна быть, в отдельные функции - это плохо. Ну а про чем мапа хуже класса мне по существу добавить нечего к той дискуссии, на которую есть ссылка выше. Если тебе нравится ловить runtime exception-ы в проде вместо того, что твой код просто не скомпилится, то кто я такой, чтобы ограничивать тебя в твоих развлечениях
Если не уметь пользоваться инструментом, то его эффективность и применимость будут сомнительные, я согласен
То, что это очень показательная характеристика как раз инфоцыган - голословно что-то утверждать, в качестве аргументов в лучшем случае приводить какой-нибудь черипикинг, а когда ты задаёшь неудобный для них вопрос, вместо ответа получаешь агрессию. Не, если целью всей статьи и комментариев потом является маркетинговая прокачка своей онлайн-активности, то стратегия довольно успешная. Однако с точки зрения обсуждения вопроса, поднятого в статье, получается какая-то фигня
Неумение пользоваться инструментом не является виной инструмента, но больше всего и чаще всего на инструмент ругаются как раз те люди, которые не умеют им пользоваться
11 слов агрессии вместо одного простого ответа по существу "да" или "нет". Делаю вывод, что по существу ответить нечего, и с вопросом я попал в самую суть
А каким образом опыт работы в энтерпрайзе является аргументом в пользу умения и понимания ООП? И причём тут вообще кобол - язык, на секундочку, вообще изобретенный до появления ООП?
Ну так в том-то и дело, что если у нас логика работы с данными инкапсулирована, то это и есть то одно место, где следует вносить изменения, а не вычитывать весь проект, выискивая все те места, которые вместо объекта с инкапсулированной логикой используют объект исключительно как fancy-версию мапы
Ну и вообще, я много раз говорил ранее и повторю сейчас - даже если обмазать код ключевыми словами ооп-синтаксиса типа "класс", "интерфейс" и так далее, то само по себе это не делает код оопешным. Вполне может получиться обычная процедурщина, только с ооп-синтаксисом, и уж точно не вина инструмента в том, что им не умеют пользоваться
Спасибо за ссылку, прочитал я ту дискуссию, довольно занятно. Удивляюсь выдержке по 100 раз отвечать на странные вопросы, я бы так не сумел
А вот мне стало интересно, автор, ты когда-нибудь работал на одном и том же проекте длительное время? Не так чтобы полгода задачи с борда закрывать, а вот прям дизайнить архитектуру, писать код, релизить, саппорить, исправлять свои же косяки, etc. А то, поработав на разных проектах с разными людьми, в том числе с фрилансерами, а также на разного рода галерах, где на одном проекте люди постоянно меняются, у меня начинает складываться впечатление, что именно такие люди максимально наплевательски относятся к качеству кода, и пишут лишь бы работало, совершенно не заботясь о читаемости, поддерживаемости, расширяемости и т.д.
Теперь давай по пунктам пройдемся:
1) "Чистый код экономит время в долгосрочной перспективе" - да, это так. Потому что сложность имеет тенденцию со временем увеличиваться. И если что-то сейчас сделать тяп-ляп, лишь бы работало, а потом это не исправить, а оставить как есть, то через время это тяп-ляп имеет возможность превратиться в такой снежный ком неподдерживаемого переплетенного хтонического ужаса, что трогать будет уже просто страшно (особенно если нет тестов, но о них мы позже поговорим). Разумеется, каждому из нас приходилось писать костыли, потому что фикс нужен срочно, но на мой взгляд достаточно очевидно, что такой костыль следует исправить ASAP как будет возможность, а не копить тех долг где-то в бэклоге
2) "Названия должны быть самодокументирующими" - да, это так. Твой пример с
UserAccountManagerFactoryBuilderSingletonтут не подходит, так как это пример плохого и не говорящего названия, слепленного из дженерик терминов. В идеале названия должны быть лаконичными и говорящими. Не всегда получается, разумеется, достичь идеала, но это не повод ведь теперь все бросить и начать называть переменные и методы абы как, верно? А если переимнование чего-либо ведет к тому, что это ломает не то что половину проекта, а хоть что-то, то... я даже хз, что надо было делать предварительно в этом проекте, чтобы ренейминг что-либо ломал. Расскажи, что ли, мне действительно интересно3) "Функции должны быть короткими" - ну, тут соглашусь. Гнаться за коротковизной как самоцелью - так себе идея, в жизни всякое бывает, в том числе сложная логика. Тем не менее, лучше короткие функции с явно выраженной целью, понятным образом трансформирующие какие-то входные аргументы на какой-то результат, которые можно протестировать, чем полотна кода на несколько экранов
4) "Комментарии — признак плохого кода" - комментарии бывают разные. Пояснять какие-то решения - это нормально. Например, Javadoc - это тоже комментарии, и предполагается, что это высокоуровневые комментарии, которые поясняют, для чего нужен класс или метод в целом. Если же код нуждается в комментариях, чтобы понять каждую отдельную строку этого кода - то таки да, это плохой код и плохие комментарии
5) "Don’t Repeat Yourself" - да, это так. Не знаю уж как ты, автор, а я заколебался на разных проектах ковырять одну и ту же логику в разных местах, потому что программист, который ее писал, просто шлепал код как есть, не думая вообще про вынесение в общие методы. А потом еще обнаруживается, что этот человек даже с копипастой справиться нормально не сумел, поэтому в разных местах есть расхождения (и не потому, что они реально должны быть), и саппорт, дебаг и исправление ошибок превращается в натуральную пытку
6) "Тесты делают код чище" - ДА, ДА, ДА. Опять же, я готов понять, если человек пришел на проект на пару месяцев, и ему вообще пофигу как на качество кода, так и на будущий саппорт проекта. Но я вообще не понимаю, как можно настолько себя не любить, что если ты сам работаешь на проекте, и ты же развиваешь этот код, и ты же его саппортишь, чтобы не писать тесты. Тесты как минимум позволяют безопасно делать рефакторинг в будущем, как максимум - защищают от багов в проде, с которыми к тебе же и придут, чтобы ты разбирался и чинил. Работал я как-то с одним придурковатым тимлидом, который код проверял мануально, а потом запрещал трогать что-либо, потому что никаких гарантий, что изменения ничего не сломают, у него не было. Разумеется, тесты не панацея и не защитят на 100%, но это не повод от них отказываться
7) "SOLID принципы решают все проблемы" - никогда ранее не слышал подобных утверждений. SOLID - это набор рекомендаций, как писать правильный ООП-код. Рекомендаций, а не строгих правил, и разумеется их можно нарушать, но для начала неплохо бы все-таки понимать эти принципы, чтобы как раз понимать, что и когда уместно нарушать, а что лучше нет
Вообще, ни одно правило "чистого кода" не стоит воспринимать абслютно. Как вообще ни одно правильно не следует воспринимать. Все они придуманы для решения или недопускания определенных проблем. Квалификация программиста заключается в том числе в том, чтобы понимать, с какими проблемами он имеет дело в данный момент, и согласно ситуации выбирать и абстракции, и конкретные решения
Да нет. Пиши так и столько, как и сколько хочется. Я в такой задаче не строгая учительница, которая линейкой по пальцам бьёт за ошибки, я лишь наблюдаю за мыслительным процессом, и если он состоит в итеративном приближении к ответу, то и ладно, мне норм. Процесс завершится либо когда будет заявлено, что готово, либо когда кандидат сдастся, ну либо могу прервать досрочно, если время будет кончаться
Если какие-то другие интервьюеры косплеят училок, то, ну, пусть идут в баню
Это набор ничего не значащих вопросов, ответы на которые прекрасно даёт chatgpt. Для чего в этом процессе нужен собеседуемый? Чтобы косплеить прокси? У интервьюера vpn не работает и он сам в ai не может вопрос написать?
Имхо, если в компании есть принятый стек технологий, то знать и уметь работать надо именно с этим стеком, и совершенно нет никакой разницы, что там ещё нового в мире придумали. И проверять надо не теоретическое знание каких-то технологий и версий, а в целом умение человека думать, анализировать и т.д. (что - сюрприз - гораздо лучше видно на решении задач, а не на отвечании на вопросы). Я вот встречал людей, которые вызубрили какие-то определенные технологии или фреймворки, но ни шага за их пределами не умеют. Условно, метод findById в spring data они умеют писать, а отбери у них spring, и простое "select * from ... where id=..." они не в состоянии. И толку мне от такого разработчика, пусть даже он офигенно шарит в самых новых версиях spring data?
А для меня необходимый обряд - это просто пройти пару собесов для разминки, и в целом уметь отвечать на фундаментальные вопросы, и по моему личному опыту мои знакомые делают именно так. Ну так и чей личный опыт более опытный?
Это отличная задача для лайф кодинга. У меня, кстати, была именно такая на последнем собесе, я с огромным удовольствием с ней поигрался на интервью
1) подготовить пустой проект с нужными зависимостями - это в худшем случае вопрос примерно 5 минут. К тому же его можно подготовить перед самим собесом
2) для такой задачи не нужны никакие миграции, нужен функционал, который можно дернуть условным Postman и посмотреть на ответ
3) навскидку нужны примерно 5 классов: контроллер, сервис, репозиторий, класс-dto и класс-entity (если мы в мире java). Этого уже достаточно, чтобы понять, понимает ли человек, что он делает, и как планировать архитектуру. Если очень хочется выпендпиться, то можно добавить mapstruct маппер, но это уже прямо роскошный максимум
4) да пофиг, если даже проект не запустится. Опять же, по одному только процессу создания и обсуждения всего вышеперечисленного уже понятно, что человек знает и умеет
Где-то примерно полчаса, наверное, такое и займёт. Отличная задача, в общем