С пивом все до боли просто. Храните 1-2 толстостенных бокала в морозильнике. Когда решили хлебнуть холодного пивка — просто достаете бокал и наливаете туда пиво.
Профит. Главное не простудиться.
Тогда ваша тактика имеет право на жизнь, но… Мне все же кажется, более применительно к более зрелым разработчикам а не к стажерам. Так как для этого все равно нужно скачать их код, либо готовую джарку и запустить, а это тоже время. А как я уже писал выше, задача не сложная. И рабочее решение присылает большая часть соискателей. И когда имеется 30 откликов с решениями на 5 мест, в первую очередь, выбираются те претенденты которые написали более читабельный код, что видно через код ревью прямо на гите. А уже от лучшего к худшему: загрузка кода, проверка работоспособности и тп, из неотсеянных.
Хорошо читабельный код, по моему мнению — имеет неоспоримое преимущество перед портянками.
вы не можете дать точный ответ на простой и краткий вопрос
Вопрос вообще не относится к теме. Не нужно путать оформление кода и структуру.
Где тут телепатия?
вы из тех кто пишет классы по 100500 строк которые все делают?
Так что с ответами?
Хотя, мне кажется, от вас такого ответа не дождусь, так как к java вы никакого отношения не имеете (java и javascript это разные вещи, если что). А вы, как я вижу, так чисто, пошлепать зашли.
ps не поленился заглянуть в профиль.
Предыдущий комментарий улетел немного не туда. Теперь подробно.
то пункты 1 и 2 противоречат друг другу в тех тестовых заданиях, где ТЗ неполное
Как может п1. где говорится что
приложение должно работать в соответствии с ТЗ
может противоречить п2. где говорится:
Кропотливо проверяйте выполненную задачу
Или вы не понимаете разницу между тем как делать, и как после этого тестировать свое консольное приложение? Как вообще могут противоречить советы по выполнению советам по проверке? По моему все достаточно четко. Сначала сделал, соответствуя спеке (п1), затем проверь, что все работает согласно ей же (п2). А ТЗ достаточно полное, четкое и простое до боли.
Там и не будет кучи пакетов. Чаще это репозиторий, комманд или экшены, валидаторы. На счет KISS и YAGNI — эти принципы, на мой взгляд, больше применимы при решении реальных задач и понять писал ли соискатель свой код в соответствии с этими принципами или просто не умеет лучше — распознать сложнее. Возможно следует добавить в ТЗ условие, что приложение должно быть легко расширяемым и масштабированным.
Я уже отвечал в других комментариях. На мой взгляд, если позволяет время, нужно писать максимально хорошо. Для java как для ООП языка есть такие принципы, как SOLID, в соответствии с которыми и пишутся хорошие приложения на этом языке. А некоторые из советов просто помогают их осознать. Да и я не вижу ни одного совета, который может быть плохо воспринят при проверке тестового задания в любой компании (для java). Единственное, там зацепились за массив/коллекцию, но я уже отвечал и на это замечание тоже.
например встречал мнение что на таких заданиях наоборот стоит максимально упрощать а не городить классы с пакетами, это же тестовое а не продакшен
Это задание достаточно легкое по логике, и задание для стажера. Поэтому, если стажер уже считает, что может не придерживаться основных принципов ООП при написании кода на java, о которых написано на каждом столбе… Ну не знаю даже, что еще тут сказать.
Следуя вашим суждениям в ТЗ должно быть написано: “приложение должно быть написано в стиле ООП и по принципам SOLID”. Однако… это же java. Плюс, это же самые распространенные вопросы на собеседовании и, на мой взгляд, это каждый разработчик должен понимать и писать код в соответствии с ними по умолчанию (и если он не вспомнит на собеседовании как какой принцип называется, ничего страшного в этом нет).
Хорошо, возможно пример с массивами и не очень удачен. И я, кстати, не писсимизирую соискателя, не считаю это ошибкой, если он использовал массив а не коллекцию. Но когда человек использует правильную коллекцию — это может дополнительно охарактеризовать его знания в этой области, только и всего. А область по работе с оптимизацией памяти мне кажется, на стажера наваливать просто рановато. У них и так в голове часто одна теория не закрепленная практикой.
Поверьте, я просматриваю все задания, просто не весь код сливаю и запускаю. Я пишу фидбеки всем, но когда я вижу, что все написано в спагетти — я уже не копаюсь в валидаторах и решениях и не пишу индивидуальный фидбек. Тут фибек уже будет общего плана. Что-то на вроде: «вам необходимо лучше разобраться в принципах ООП и SOLID».
Нет, быстро не способен — нет опыта. И это всего лишь знание java core, принципов ООП и SOLID. Ничего тут сверх естественного нет. И люди идут, быстро развиваются, получают знания и опыт и вливаются в работу.
Нет, про тесты ничего нет. Если их нет — это ни на что не влияет, но если они есть — мы видим, что человек просто их умеет писать. Для стажера будет небольшим плюсом.
Я способен быстро отличить кратко и емко написанный код, от спагетти кода. По поводу готовых решений, не нужно ставить опытного разработчика на одну ступеньку со стажерами.
Все равно намного лучше использовать что-то уже готовое, желательно использующееся повсеместно в компаниях. Гораздо лучше, если кандидат, например, знает про Bean Validation API
Да, лучше, но как показывает практика, это пока за гранью понимания стажеров.
Убрать трату времени на проверку работоспособности
Проверку работоспособности нужно еще заслужить. Зачем мне запускать спагетти, если рядом прислали хороший код?
В чем по-вашему выражается эффективность? Если вы не внимательно прочитали статью, то напомню: работающий код присылает большая часть соискателей. Или вы считаете эффективным написанный на коленке код, который потом будет тяжело поддерживать? Писать спагетти код может почти каждый, кто худо-бедно выучил стек. А вот писать код, который потом будет удобно поддерживать и легко читать — единицы. И не забывайте, что задание для стажеров/джуниоров. Они еще априори не умеют делать быстро и качественно.
Так что для нас, лучше взять человека, который понимает принципы SOLID не только теоретически. А руку на скорость он набьет, мы ему дадим такую возможность.
Сколько вы проверили тестовых заданий? Подозреваю, что ни одного.
Вас не смущает общая оценка статьи?
Нет, оценку ставят такие как вы, тролли.
А вас не смущает количество людей добавивших статью в закладки? Это начинающие разработчики, и они скорее всего просто не имеют права голосовать на Хабре, поэтому оценка и ушла вниз.
В статье я выложил вполне дельные советы начинающим разработчикам. Все, кто помнит, как то — джуном искать работу, статью оценят. Вам же, если вы вообще имеете опыт в Java порекомендую книгу Роберта Мартина «Чистый код», если ее не читали.
Профит. Главное не простудиться.
Хорошо читабельный код, по моему мнению — имеет неоспоримое преимущество перед портянками.
Так что с ответами?
Хотя, мне кажется, от вас такого ответа не дождусь, так как к java вы никакого отношения не имеете (java и javascript это разные вещи, если что). А вы, как я вижу, так чисто, пошлепать зашли.
ps не поленился заглянуть в профиль.
Как может п1. где говорится что может противоречить п2. где говорится:
Или вы не понимаете разницу между тем как делать, и как после этого тестировать свое консольное приложение? Как вообще могут противоречить советы по выполнению советам по проверке? По моему все достаточно четко. Сначала сделал, соответствуя спеке (п1), затем проверь, что все работает согласно ей же (п2). А ТЗ достаточно полное, четкое и простое до боли.
АПИ в консольном приложении? Серьезно?
Фидбек будет всем, но подробный, только с хорошим кодом.
Это задание достаточно легкое по логике, и задание для стажера. Поэтому, если стажер уже считает, что может не придерживаться основных принципов ООП при написании кода на java, о которых написано на каждом столбе… Ну не знаю даже, что еще тут сказать.
Да, лучше, но как показывает практика, это пока за гранью понимания стажеров.
Проверку работоспособности нужно еще заслужить. Зачем мне запускать спагетти, если рядом прислали хороший код?
А вы почитайте, думаю вам будет не лишним: принципы SOLID
Так что для нас, лучше взять человека, который понимает принципы SOLID не только теоретически. А руку на скорость он набьет, мы ему дадим такую возможность.
Нет, оценку ставят такие как вы, тролли.
А вас не смущает количество людей добавивших статью в закладки? Это начинающие разработчики, и они скорее всего просто не имеют права голосовать на Хабре, поэтому оценка и ушла вниз.
В статье я выложил вполне дельные советы начинающим разработчикам. Все, кто помнит, как то — джуном искать работу, статью оценят. Вам же, если вы вообще имеете опыт в Java порекомендую книгу Роберта Мартина «Чистый код», если ее не читали.