Да, поэтому я пропагандирую вариант что вообще их писать не нужно, до определенного момента, если уж очень хочется, сходите к ИИ, а не тратьте недели на написание тестов
Грейды я не раздаю, но если человек уже хорошо пишет код и умеет в бизнес задачи, а нынешний найм работает по паттернам VK, которые способны к поиску кого угодно, но не адекватных разработчиков, то человека можно назвать джуном (и давно джун это грейд?) Про тесты, их вообще мало кто пишут во фронтенде, а нормальные тесты пишут еще меньше, если мы говорим про галлеры, там там часто пишут тесты ради тестов, и нафиг там не надо уметь их писать, пишешь что то что повышает покрытие тестами. А там где тесты пишут нормально, там объясняют что и как нужно тестировать, потому что нельзя взять часть проекта, дать ее джуну (Который ни бизнеса не знает, ни технических тонкостей) и ждать нормальных тестов
Ну, скидывать джунам юнит-тесты..... Ну, это очень странно, я никогда не видел, чтоб джунам давали писать юнит-тесты на чужой функционал (при условии, что это не джун с 2 годами опыта). Так как писать нормальные тесты сложно, скорее всего, если так делают, то задача не написать тесты, а сделать покрытие 90%, и плевать на качество тестов и способ их написания. Если уж так случилось, что нужно дать задачу хоть какую-то, чтоб работал, дайте писать тесты на утилиты, там не должно быть бизнес-логики.
Название статьи прочитайте, пожалуйста, речь идет о людях, которые только учатся.
Про сливать коммерческий код: если это код утилит или хуков без специфичной бизнес-логики (ключей, API и т. д.), то я проблем не вижу. Если вы думаете, что очередной специфичный конвертер телефонов нельзя залить в ГПТ для написания тестов, дело ваше, но в нем нет ничего, что может создать уязвимость. (Скорее всего, этот конвертер был уже взят из ГПТ или Stack Overflow.)
Я имел ввиду что нет смысла тратить время на написание, к примеру, unit тестов, когда это может сделать ИИ, но не нужно слепо копировать, прочитайте код, проверьте, похож ли тест на что то имеющие смысл
Вот я вас не пойму, вроде написано что для тех кто еще не пишет продакш код, кто только учится и вместо основ языка учит паттерны и SOLID, а у вас все одно, пока 10 лет на computer science не потратил, не разработчик
FSD не замена SOLID, но в функциональном мире реакта SOLID выглядит странно и сложно, если взять FSD, накинуть на него правила написания компонентов в react и приправить здравым смыслом (DRY, APO, KISS, YAGNI), то получится хороший код.
Ну вот примерно про это я и говорю, вы сами приводите примеры не из SOLID, а из обычной логики и читаемости кода, для этого не нужно знать SOLID, есть фронтовые гайды, как правильно писать код, к примеру FSD, в котором это всё описано, но нет абстракций, которые всё усложняют, так как FSD изначально делался под фронтовые проекты.
Хорошая статья! Хотелось бы немного больше тонкостей о работе мемоизации в React, так как заголовок кричит что мы получим что то новое, но в целом статья очень даже неплохая) Добро пожаловать на Хабр, в это уютное и немного токсичное болотце)
Ну может это и костыли, но разработчики React сказали что классы фу-фу-фу, и надо использовать хуки, в теории оба подхода имеют свои плюсы, но джуну не нужно знать о плюсах подхода который больше мертв чем жив. Про дебаг ошибок сказать ничего не могу, сам на классах писал довольно мало и переходя на хуки мне становилось проще писать код и искать в нем ошибки
Статистика с getmatch, для чистоты проверял на hh, данные сошлись. Как первоисточник данных не взял hh так как множество вакансий с вилкой 100к-300к и в статистику такое не пойдет, а в части вакансий нет ЗП
Ну мобильные приложения разные бывают, к примеру приложение показа погоды это просто морда для данных с backend'a, задача разработчика мобильных приложений в таком случае просто отрисовать данные которые он получил с сервера. В тоже время сайт с погодой делает все тоже самое, и получается что мобилка и фронт являются разными видами отображения одних и тех же данных
Согласен с вами, одной из целей данной статьи было предостеречь джунов от идеи идти в fullstack, так как сейчас много рекламы в духе, стань fullstack middle за 4 месяца
Да, поэтому я пропагандирую вариант что вообще их писать не нужно, до определенного момента, если уж очень хочется, сходите к ИИ, а не тратьте недели на написание тестов
Грейды я не раздаю, но если человек уже хорошо пишет код и умеет в бизнес задачи, а нынешний найм работает по паттернам VK, которые способны к поиску кого угодно, но не адекватных разработчиков, то человека можно назвать джуном (и давно джун это грейд?)
Про тесты, их вообще мало кто пишут во фронтенде, а нормальные тесты пишут еще меньше, если мы говорим про галлеры, там там часто пишут тесты ради тестов, и нафиг там не надо уметь их писать, пишешь что то что повышает покрытие тестами. А там где тесты пишут нормально, там объясняют что и как нужно тестировать, потому что нельзя взять часть проекта, дать ее джуну (Который ни бизнеса не знает, ни технических тонкостей) и ждать нормальных тестов
Так я пишу что это не надо учить
Ну, скидывать джунам юнит-тесты..... Ну, это очень странно, я никогда не видел, чтоб джунам давали писать юнит-тесты на чужой функционал (при условии, что это не джун с 2 годами опыта). Так как писать нормальные тесты сложно, скорее всего, если так делают, то задача не написать тесты, а сделать покрытие 90%, и плевать на качество тестов и способ их написания. Если уж так случилось, что нужно дать задачу хоть какую-то, чтоб работал, дайте писать тесты на утилиты, там не должно быть бизнес-логики.
Название статьи прочитайте, пожалуйста, речь идет о людях, которые только учатся.
Про сливать коммерческий код: если это код утилит или хуков без специфичной бизнес-логики (ключей, API и т. д.), то я проблем не вижу. Если вы думаете, что очередной специфичный конвертер телефонов нельзя залить в ГПТ для написания тестов, дело ваше, но в нем нет ничего, что может создать уязвимость. (Скорее всего, этот конвертер был уже взят из ГПТ или Stack Overflow.)
Я имел ввиду что нет смысла тратить время на написание, к примеру, unit тестов, когда это может сделать ИИ, но не нужно слепо копировать, прочитайте код, проверьте, похож ли тест на что то имеющие смысл
Это пост из моего тг, уж очень хотелось высказаться
Вот я вас не пойму, вроде написано что для тех кто еще не пишет продакш код, кто только учится и вместо основ языка учит паттерны и SOLID, а у вас все одно, пока 10 лет на computer science не потратил, не разработчик
FSD не замена SOLID, но в функциональном мире реакта SOLID выглядит странно и сложно, если взять FSD, накинуть на него правила написания компонентов в react и приправить здравым смыслом (DRY, APO, KISS, YAGNI), то получится хороший код.
Ну вот примерно про это я и говорю, вы сами приводите примеры не из SOLID, а из обычной логики и читаемости кода, для этого не нужно знать SOLID, есть фронтовые гайды, как правильно писать код, к примеру FSD, в котором это всё описано, но нет абстракций, которые всё усложняют, так как FSD изначально делался под фронтовые проекты.
А что плохого в переводе статей про нормальные хуки?
Значит эта статья написана не зря)
К сожалению это правда жизни) Но речь не о сложных структурах и понимание на уровне экспертов, а про начните с простого, а дальше пойдет
Хорошая статья!
Хотелось бы немного больше тонкостей о работе мемоизации в React, так как заголовок кричит что мы получим что то новое, но в целом статья очень даже неплохая)
Добро пожаловать на Хабр, в это уютное и немного токсичное болотце)
Ну может это и костыли, но разработчики React сказали что классы фу-фу-фу, и надо использовать хуки, в теории оба подхода имеют свои плюсы, но джуну не нужно знать о плюсах подхода который больше мертв чем жив. Про дебаг ошибок сказать ничего не могу, сам на классах писал довольно мало и переходя на хуки мне становилось проще писать код и искать в нем ошибки
Хотелось бы) Но пока живем с Redux'ом
Статистика с getmatch, для чистоты проверял на hh, данные сошлись. Как первоисточник данных не взял hh так как множество вакансий с вилкой 100к-300к и в статистику такое не пойдет, а в части вакансий нет ЗП
Ну мобильные приложения разные бывают, к примеру приложение показа погоды это просто морда для данных с backend'a, задача разработчика мобильных приложений в таком случае просто отрисовать данные которые он получил с сервера. В тоже время сайт с погодой делает все тоже самое, и получается что мобилка и фронт являются разными видами отображения одних и тех же данных
Согласен с вами, одной из целей данной статьи было предостеречь джунов от идеи идти в fullstack, так как сейчас много рекламы в духе, стань fullstack middle за 4 месяца
Прочтите комментарий SeokkySss на который я отвечал