Комментарии 16
Страшный сон джуна
Особенно не используйте те технологии, которые вы не знаете, просто решив поупражняться на реальном проекте, который будут оцениваться
Делал в своей жизни пару тестовых заданий, и, если не было каких-то особых требований, обязательно затягивал какую-то незнакомую для себя штуку, типа Toothpick вместо Dagger. Чтобы раз уже трачу свое время непонятно на что, так хоть с пользой для себя.
Не было страха запутаться с новой технологией и не уложиться в срок?
Нет, по нескольким причинам.
Во-первых, я не так много делал тестовых 🙂 И за большие не брался, запас времени в несколько дней есть, тестовое даётся на дом же.
Во-вторых, я не брал какие-то сложные штуки с новыми концепциями (типа RxJava, не видя реактивщины до этого). А Toothpick после Dagger или Room после ORMLite не знаю, чем могут запутать.
Конечно, возьми я RxJava, не видя до этого реактивщины в лицо, мог бы и запутаться, наверное.
обязательно затягивал какую-то незнакомую для себя штуку
а потом получить в лоб вопрос про эту штуку в контексте 'во, во, а мы это юзаем, можете пояснить как вы в ней __такоето__ делали?'
или наоборот 'а вы знаете что в __этойштуке__ есть некие проблемы с многопоточностью (например) и как вы их решаете? (раз тут применили значит разбираетесь'?
можете пояснить как вы в ней __такоето__ делали?
А что мешает сказать: «__такое-то__ я на этой штуке не делал»?
раз тут применили значит разбираетесь
А из чего это исходит? Где-то есть правило, что я должен быть экспертом 5000+xp в каждой либе, которую использую в тестовом или любом другом проекте? Жалко, что вам попадались интервьюеры, цель которых была очевидно вас подловить.
Где-то есть правило, что я должен быть экспертом 5000+xp в каждой либе,
ну тоесть вы на работе, будете использовать первые попавшиеся либы тупо почитав что 'вроде подходит, фигзнает как и что там внутри'?
Жалко, что вам попадались интервьюеры, цель которых была очевидно вас подловить.
ну я лично, если приходилось, выбирал либы только те которые знал и те про которые мог чтото рассказать.
я несколько раз сталкивался лично с непреодолимыми проблемами в библиотеках которые затянули в проект люди с подобным подходом:
1) заюзать либу у который последний коммит на гитхабе более 5 лет назад
2) заюзать либу у который разработчик с альтернативным мышлением. типа 'я юзаю только python3.2 потому что спать не могу как не люблю более новые версии и не собираюсь ничего менять'
3) заюзать форк от основной либы где ктото пофиксил важную ошибку, и не описать это в документации и не продумать кто будет потом этот форк апдейтить в вашем проекте
А что мешает сказать: «__такое-то__ я на этой штуке не делал»?
и перейти на разговор в плане 'а почему вы вообще решили эту либу заюзать?'
тоесть вы на работе, будете использовать первые попавшиеся либы тупо почитав что 'вроде подходит, фигзнает как и что там внутри'?
ну я лично, если приходилось, выбирал либы только те которые знал и те про которые мог чтото рассказать.
Право, не стоит впадать в крайности :) Дают вам тестовое задание вида "что-то получить с апишки и показать несколько графиков" (без явного требования реализации их ручной отрисовки), и вы героически несколько ночей реализовываете отрисовку их вручную, потому что до этого с либами для графиков не сталкивались, а, значит, и сказать ничего не сможете?)
я несколько раз сталкивался лично с непреодолимыми проблемами в библиотеках которые затянули в проект люди с подобным подходом
Опять же ненужные крайности. Я в тестовые затягивал библиотеки не просто ради того, чтобы хоть что-то затянуть, а чтобы разобраться с чем-то новым, в чем нет времени ковыряться просто так (как уже писал выше, Toothpick и Room я впервые испытал именно в тестовых заданиях).
и перейти на разговор в плане 'а почему вы вообще решили эту либу заюзать?'
Ни разу мне не задавали такой вопрос, но если бы уж дошло обсуждение до этого, то так бы и сказал: «Вы не платите мне за тестовое, поэтому, чтобы не тратить свое время совсем зря, я заюзал эту либу, чтобы с ней поиграться, потому что другого времени для этого у меня не было еще». Ну, немного в более мягкой форме)
Но вообще ни разу, по-моему, выполнение мною тестового не приводило к найму. Не из-за того, что я их плохо делал, а потому что те компании, в которых я реально хотел работать, выдачей тестовых не страдали.
Не из-за того, что я их плохо делал, а потому что те компании, в которых я реально хотел работать, выдачей тестовых не страдали.
ну у меня аналогичная история, за всё время я делал только одно тестовое задание за всё время (которое гордо повесил на гитхабе чтобы показывать на собесах в стиле 'ну вот както так я делал микросервисы')
я уже в принципе, если человек всётаки делает какуюто задачу и использует какието инструменты — он должен делать это не назло (типа вы дураки нечего мое время тратить, вот запилю както так), а так как сделал бы это на работе.
так как сделал бы это на работе
А на работе новые либы никогда не надо затягивать?) Реальный плюс-минус кейс: работал я когда-то 2 года на проекте, где в качестве ORM была Greendao. Неплохо с этой штукой за 2 года успел разобраться, но также и узнал его проблемы (допустим, join-ы через id, который не long, приходилось костылить, потому что кодогенерация этого не умела). Плюс увидел, что на гитхабе год никаких коммитов, проблемы не исправляются.
И тут меняю работу, где надо заложить основу для нового проекта. Google тем временем уже представил Room. Ваш вариант, что следует затянуть в проект? Greendao, который я знаю, или Room, который, судя по всему, может решить известную мне боль, да и завтра не загнется, так как уже рекомендуется на d.android.com?
Если бы все юзали только библиотеки, которые они знают, мы бы до сих пор в андроиде сидели на асинктасках и контентпровайдерах.
А на работе новые либы никогда не надо затягивать?)
надо, но у меня затягивание новой либы всегда было — только после обсуждения с коллегами
Google тем временем уже представил Room. Ваш вариант, что следует затянуть в проект?
1) затягивать тот который вы знаете
2) гугл не единожды замечен в забрасывании проектов, либ и прочего. я бы вообще бы опасался его либы юзать, учитывая еще наплевательскую документацию… по этому новые только-выпущенные либы и решения гугла брать в прод не стоит, очень велика вероятность поиметь проблем через год-два.
только старые давно проверенные решения которым несколько лет и активное сообщество.
Если бы все юзали только библиотеки, которые они знают, мы бы до сих пор в андроиде сидели на асинктасках и контентпровайдерах.
Это двоякий вопрос, с одной стороны вы как разработчик правильно думаете (развитие важно), а с другой стороны это риски закопать кучу бабла с нулевым выхлопом… а потом еще кучу бабла чтобы всё починить.
причем аргумент для бизнеса 'ну потому что это модно, надо всё новое юзать' — очень фиговый аргумент, бизнес он про бизнес, а не про образование сотрудников
1) затягивать тот который вы знаете
гугл не единожды замечен в забрасывании проектов
И в выборе между уже заброшенной либой и либой, которую гипотетически могут забросить, вы предлагаете выбрать первое. Логично)
Ну и Android — проект гугла, тогда и под Android разрабатывать не стоит с такой логикой.
это риски закопать кучу бабла с нулевым выхлопом
Ну вот поэтому при возможность пощупать любу без необходимости затягивать в реальный проект я не упускаю :)
Ну и Android — проект гугла, тогда и под Android разрабатывать не стоит с такой логикой.
и у меня слов матерных не хватает… по поводу андройда
Я тут открыл свой проект 9 летней девности, он весь зачеркнут как depricated (меня еще больше забавляет что темплейты приложений в андройдстудии тоже наполовину с depricated кодом… типа лень заапдейтить… олимпиадники погромисты на такое не размениваются)
а их способ писать код с импортом compat библотек когда например 'базовая библиотека у нас, например layout… но если хотите в совместимость юзайте layoutcompat'… тоесть всегда надо юзать compat и при смене версии compat перелопачивать весь код… а версии они меняют с завидной регулярностью
…
а уж сколько они технологий успели родить и закопать...instant apps вроде год чтоли продержались?
Это, конечно, уже совсем другая тема, но
проект 9 летней девности, он весь зачеркнут как depricated
9 лет назад Android был молодой и зелёный, было бы странно, если бы за это время ничего не устарело. Это Java может себе позволить 9 лет ничего не менять и называть это обратной совместимостью.
тоесть всегда надо юзать compat и при смене версии compat перелопачивать весь код
Очень редко при смене версий compat надо что-то «перелопачивать». Я помню только одну такую ситуацию, когда гугл зачем-то решил переименовать все пакеты. Зато эти либы позволяют использовать какие-то штуки, появившиеся в новых версиях Android, без необходимости отказываться от поддержки старых версий ОС. Без этого фрагментация среди Android-экосистемы была бы ещё больше.
instant apps вроде год чтоли продержались?
Вы что-то путаете, они и сейчас «держатся». Их, правда, почти никто не делает, но это уже другой вопрос.
Вы что-то путаете, они и сейчас «держатся»
я давно не слежу за андройдом
но тут на хабре читал гдето год назад статью
что они выкатили инстант апп как отдельную сущность потом её деприкейтнули и сделали частью обычного аппа… в итоге всем несколько раз надо было переписывать проекты
9 лет назад Android был молодой и зелёный, было бы странно
они сильно чаще выпиливают фишки какието чем раз в 9 лет.
мне вспоминается глобальный переход в районе 5-6 версии когда массово поменяли настраиваемую безопасность, а потом новый тип лайаутов… и чтото с асинхронщиной.
а 9 лет назад вышел 4 андройд который 'наконецто созрел и избавился от наследия 2й версии… помню киткату оды пели тогда… а сейчас киткат только в матерном контексте поминают
Не знаю какой размер должен быть у тех задания, чтобы для него надо было мучаться с историей коммитов, созданием CI/CD. Может быть еще и можно в release выложить готовый бинарник, но ревьюверу, для которого пишется тех задание, несложно его скомпилить
любой ревьювер от вашего кода придёт в восторг.
Очень плохо говорить за всех. У "любых" ревьюверов могут быть любые свои собственные хотелки и представления о том, что они хотят увидеть в проекте...
Если вы хотите, чтобы о вашем проекте дали отзыв, то пишите, что это за проект, что он делает.
Так это советы как успешно пройти ревью и выложить в гитхаб результаты тестового задания для конкретного ревьювера, или о том, как оформить пет проект и попробовать заманить на него людей для получения отзыва?
Тестовое задание требуется во время интервью, после этого можно про него забыть. Только небольшая часть таких заданий, которые дают в каких-нибудь FAANG и требующих неделю на выполнение, могут быть достаточно большими, чтобы их имело смысл оформлять и оставлять в гитхаб после завершения интервью.
Честно говоря, половина советов больше подходят для ведения пет проектов, а не разового тестового задания на один вечер, вторая половина - банальные вещи типа соглашениях имен, комментариях и проверке результата... Уж извините за критику.
10 советов «Как успешно пройти Code Review»