Задать вопрос

Насколько обоснованы замечания по тестовому заданию?

Недавно выполнил тестовое на вакансию js-разработчика и получил отказ со следующими замечаниями:

1) Необходимо использовать Redux
2) клонирование объектов делать не нужно
3) не к месту использование PureComponent там, где лучше использовать функциональный компонент
4) использование legacy context
5) инлайн функции
6) Работа с storage не обернута в try catch
7) state можно менять только через setState

Код можно посмотреть тут: https://github.com/regulyarniy/planner
Само задание: https://docs.google.com/document/d/1YrXEhzXuuij8H0...

Мои ремарки по поводу каждого пункта, которые я для себя на данный момент сформулировал (вероятно я не прав):
1) в задании не было слова про redux, я использовал контекст. И для такого проекта действительно нужен ли redux? Я конечно понимаю, что это стандарт де факто, но в данном случае мне кажется это оверхед
2) клонирование объектов производилось для того, чтобы не мутировать стейт
3) в данном случае это вопрос личных стилевых предпочтений. если суть замечания в оптимизации - то тут нужно мерять и смотреть на месте, что быстрее - функциональные компоненты могут замедлять приложение не хуже PureComponent при неправильном использовании
4) в коде нет legacy context api
5) опять же вопрос личных стилевых предпочтений и преждевременной оптимизации
6) согласен с замечанием
7) в коде нет мутаций state напрямую

Опытному разработчику со стороны работодателя конечно виднее - ведь от его решения частично зависит то, с кем ему потом возможно работать(возможно например были и другие замечания, но человеку лень было все описывать). У меня вопрос - насколько данные замечания адекватны и что из них стоит принимать за чистую монету? Просто хотелось бы понять какую провести работу над ошибками, а что не особо обоснованно.
  • Вопрос задан
  • 729 просмотров
Подписаться 4 Простой 3 комментария
Пригласить эксперта
Ответы на вопрос 1
mazhekin
@mazhekin
Frontend, Backend Web Developer
Да не переживайте, это обычная ситуация, это скорее всего случай когда валится проект, руководство ищет выход из кризиса, какому нибудь лиду предлагает кандидатов, а он упирается и отсеевает всех, чтобы все от него зависело. А если вы ещё и знания показываете вам вообще туда дорога закрыта. В крайнем случае там может появится очень сильно лояльный джун на которого потом повесят ответственность за весь факап (типа лучше него невозможно спецов найти). И ничего по большому счету тут сделать нельзя, пока все не лопнет, и не поменяют всех вместе с лидом.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы