Почитайте про "проклятие знания". В этом есть проблема и тестовых заданий, и подобных задач, которые вы даёте на собеседованиях. Вы знаете решение конкретной задачи и ожидаете, что хороший специалист должен эту задачу решать так же хорошо, как и вы и также быстро. Но ваши ожидания - ваши проблемы. По факту вы просто редкие выборку специалистов и сужаете себе круг таким фильтром. Давайте те задачи, которые специалисту надо будет решать в работе. Лично я понимаю, что задача простая. Но я бы никогда не дал подобное на собеседовании, если бы этого не требовала работа. Всё люди разные и у всех есть свои лучшие и худшие стороны. И вы никогда не сможете определить уровень специалиста за одно собеседование и скорее всего упустили хороших кандидатов.
Это не так работает. Шахматы и футбол - это "экстримистан". Там есть деньги. Но они будут у 0...001% людей. Остальные на этом ничего не заработают.
И есть "медиокристан". Тут тоже есть деньги. По сути любая работа на дядю (то же программирование, хотя оно может переместиться в экстримистан при определенных условиях). Тут вы заработаете практически точно, но будет предел по максимальному доходу.
У меня претензия была к тому, что был сделан вывод об опыте автора на основании 2-х цифр (16 лет опыта и сотни проектов). А так не надо делать. Это упрощение и навешивание ярлыков чаще приводит к ошибочным выводам. Слишком мало данных для вывода. А Вы зачем-то продолжаете строить выводы на основании этих 2-х цифр.
Почему в одном месте-то? 2 файла, один для логики, другой для JSX. Что тогда вы брали инфу из пропсов, что сейчас вы берете инфу из хука в одной строке. Только с хуком у вас нет дополнительного компонента-обертки и redux-а. Всё намного проще и также тестируется. Просто мокаете не пропсы, а хук. И всё. А хук отдельно тестируете. Если это действительно необходимо, потому что всё покрывать тестами тоже плохо (ИМХО).
Что-то очень легко вы оценили опыт автора. Я бы не стал делать какие-либо выводы, узнав о цифре в 16 лет и сотнях проектах. Да ещё и настолько упростив это - тупо поделив. Откуда вы знаете, может, один проект был на 8 лет к примеру, а остальные сотни - оставшиеся 8. Да и всё равно это всего лишь цифры.
На мой взгляд, в идеале компонент должен изменяться только в случае изменения дизайна. И наоборот, логика изменяется лишь тогда, когда изменились бизнес требования.
И в чем же проблема оставить один хук и один компонент, который использует этот хук? Если у вас поменяется ViewModel и ее внешний интерфейс, вы в любом случае будете делать какие-то изменения в отображении/передаче параметров. Сейчас же у вас вместо простейшего решения из компонента и хука - слайс redux-а, компонент отображения, компонент, который занимается связью redux-слайса и отображения. Во что это превратится, если вы напишите что-то более серьезное, чем counter, думаю, говорить не нужно.
Я не вижу проблемы. Можно сделать 2 юнита - компонент (отображение) и хук (его view-model). То есть то же самое, что вы предлагаете, но намного проще. Зачем redux запихивать, в чём его преимущество? Да и в принципе, для решения конкретно этой задачи и в подавляющем большинстве задач хватит хуков реакта.
Решит-то решит, вопрос в том, насколько это решение будет жизнеспособно от синтетического программиста, который 100% времени посвящал олимпиадным задачам
Какой-то полный бред только что прочитал. Было бы всё так просто...
Какие задачи, они что, одинаковые по сложности? Эти задачи абсолютно независимы друг от друга? Нет скорее всего. 2 сотрудника - это не в 2 раза быстрее. И чем больше сотрудников, тем меньше КПД будет у каждого, вроде даже формула существует (вы любите математику, я смотрю). Как составлены задачи, блокируют они друг друга или нет? Вы оцениваете эти задачи или разработчики? (С чего вы решили, что в месяц должно выполняться 20 задач, а не 8)? Вы узнавали у сотрудников, почему так получилось, делали выводы или только калькулятором пользовались и циферки сравнивали?
Глобального маркера не будет, потому что невозможно вписать всё многообразие человечества в логический тип Boolean. Все зачем-то пытаются всё упростить, а это невозможно. Если вам кажется, что это возможно, то вы попадаете на ошибку выжившего и просто напросто просматриваете хороших кандидатов из-за своего фильтра.
Дело не в форме и стиле, а в том, что понимание продукта приходит не сразу. Поначалу, если продукт сложный, может вообще не быть понимания, что будет на главной странице и для чего она нужна. А со временем будет приходить понимание, что можно вынести на главную, как она будет выглядеть и чем она привлечет пользователя и какие функции будет выполнять.
Тут вопрос в другом совсем. Конечно же хорошо заработать на своём проекте деньги, кто спорит. Но есть другая проблема - разочарование, если цель не будет достигнута.
Как мне кажется намного лучше иметь другие цели как первостепенные (а именно - инвестиция в себя, развитие навыков, да и просто создание интересного продукта как минимум для себя). Эти цели 100% достижимы и в них вы не будете разочарованы. И уже после того, как первые цели достигнуты, можно переходить к следующей - монетизации.
Я считаю , что намного больше шансов достигнуть вторую цель (монетизацию проекта), если у вас также есть и другие цели (о которых я писал). А на одной монетизации будет сложно уехать, легко будет сорваться и перестать этим заниматься. Всё равно, что работать на нелюбимой работе с единственной разницей, что денег вы за это не получите, по крайней мере в ближайшее время.
Никогда не надо делать первой целью монетизацию проекта. Пет-проект должен быть инвестицией всегда и в первую очередь должен делаться для развития навыков, а также если вам действительно интересно создать что-то новое. Монетизация - дело вторичное и хорошо, конечно, если проект получится монетизировать, но если не получится, вы всё равно будете в выигрыше.
Почитайте про "проклятие знания". В этом есть проблема и тестовых заданий, и подобных задач, которые вы даёте на собеседованиях. Вы знаете решение конкретной задачи и ожидаете, что хороший специалист должен эту задачу решать так же хорошо, как и вы и также быстро. Но ваши ожидания - ваши проблемы. По факту вы просто редкие выборку специалистов и сужаете себе круг таким фильтром. Давайте те задачи, которые специалисту надо будет решать в работе.
Лично я понимаю, что задача простая. Но я бы никогда не дал подобное на собеседовании, если бы этого не требовала работа. Всё люди разные и у всех есть свои лучшие и худшие стороны. И вы никогда не сможете определить уровень специалиста за одно собеседование и скорее всего упустили хороших кандидатов.
Это не так работает.
Шахматы и футбол - это "экстримистан". Там есть деньги. Но они будут у 0...001% людей. Остальные на этом ничего не заработают.
И есть "медиокристан". Тут тоже есть деньги. По сути любая работа на дядю (то же программирование, хотя оно может переместиться в экстримистан при определенных условиях). Тут вы заработаете практически точно, но будет предел по максимальному доходу.
По-моему раньше всегда так было
Согласен, никогда не понимал этого.
Совсем другое - целенаправленная запись треков. Тут уже есть, куда разгуляться, занимаюсь этим как пет-проектом.
У меня претензия была к тому, что был сделан вывод об опыте автора на основании 2-х цифр (16 лет опыта и сотни проектов). А так не надо делать. Это упрощение и навешивание ярлыков чаще приводит к ошибочным выводам. Слишком мало данных для вывода. А Вы зачем-то продолжаете строить выводы на основании этих 2-х цифр.
А зачем это нужно? В чем преимущество будет отойти от жизненного цикла компонента?
Почему в одном месте-то?
2 файла, один для логики, другой для JSX.
Что тогда вы брали инфу из пропсов, что сейчас вы берете инфу из хука в одной строке. Только с хуком у вас нет дополнительного компонента-обертки и redux-а. Всё намного проще и также тестируется. Просто мокаете не пропсы, а хук. И всё. А хук отдельно тестируете. Если это действительно необходимо, потому что всё покрывать тестами тоже плохо (ИМХО).
Что-то очень легко вы оценили опыт автора. Я бы не стал делать какие-либо выводы, узнав о цифре в 16 лет и сотнях проектах. Да ещё и настолько упростив это - тупо поделив. Откуда вы знаете, может, один проект был на 8 лет к примеру, а остальные сотни - оставшиеся 8. Да и всё равно это всего лишь цифры.
И в чем же проблема оставить один хук и один компонент, который использует этот хук? Если у вас поменяется ViewModel и ее внешний интерфейс, вы в любом случае будете делать какие-то изменения в отображении/передаче параметров. Сейчас же у вас вместо простейшего решения из компонента и хука - слайс redux-а, компонент отображения, компонент, который занимается связью redux-слайса и отображения. Во что это превратится, если вы напишите что-то более серьезное, чем counter, думаю, говорить не нужно.
Я не вижу проблемы. Можно сделать 2 юнита - компонент (отображение) и хук (его view-model). То есть то же самое, что вы предлагаете, но намного проще. Зачем redux запихивать, в чём его преимущество? Да и в принципе, для решения конкретно этой задачи и в подавляющем большинстве задач хватит хуков реакта.
Я уверен, там была предыстория, перед тем как увидели книжку и уволили.
Решит-то решит, вопрос в том, насколько это решение будет жизнеспособно от синтетического программиста, который 100% времени посвящал олимпиадным задачам
Какой-то полный бред только что прочитал.
Было бы всё так просто...
Какие задачи, они что, одинаковые по сложности?
Эти задачи абсолютно независимы друг от друга? Нет скорее всего. 2 сотрудника - это не в 2 раза быстрее. И чем больше сотрудников, тем меньше КПД будет у каждого, вроде даже формула существует (вы любите математику, я смотрю).
Как составлены задачи, блокируют они друг друга или нет?
Вы оцениваете эти задачи или разработчики? (С чего вы решили, что в месяц должно выполняться 20 задач, а не 8)?
Вы узнавали у сотрудников, почему так получилось, делали выводы или только калькулятором пользовались и циферки сравнивали?
Можно наверное просто разделить хранение даты и времени в таком случае (делать это отдельно)
Чем-то напоминает супер-урезанную feature-sliced архитектуру (FSD)
Глобального маркера не будет, потому что невозможно вписать всё многообразие человечества в логический тип Boolean.
Все зачем-то пытаются всё упростить, а это невозможно. Если вам кажется, что это возможно, то вы попадаете на ошибку выжившего и просто напросто просматриваете хороших кандидатов из-за своего фильтра.
В 21-м веке диплом - это самый последний фильтр, на который надо смотреть при выборе кандидата.
Дело не в форме и стиле, а в том, что понимание продукта приходит не сразу. Поначалу, если продукт сложный, может вообще не быть понимания, что будет на главной странице и для чего она нужна. А со временем будет приходить понимание, что можно вынести на главную, как она будет выглядеть и чем она привлечет пользователя и какие функции будет выполнять.
Чет сыровато выглядит по первому впечатлению, когда включил темную тему в доке и увидел черный шрифт на черном фоне..
Тут вопрос в другом совсем. Конечно же хорошо заработать на своём проекте деньги, кто спорит.
Но есть другая проблема - разочарование, если цель не будет достигнута.
Как мне кажется намного лучше иметь другие цели как первостепенные (а именно - инвестиция в себя, развитие навыков, да и просто создание интересного продукта как минимум для себя). Эти цели 100% достижимы и в них вы не будете разочарованы. И уже после того, как первые цели достигнуты, можно переходить к следующей - монетизации.
Я считаю , что намного больше шансов достигнуть вторую цель (монетизацию проекта), если у вас также есть и другие цели (о которых я писал). А на одной монетизации будет сложно уехать, легко будет сорваться и перестать этим заниматься. Всё равно, что работать на нелюбимой работе с единственной разницей, что денег вы за это не получите, по крайней мере в ближайшее время.
Никогда не надо делать первой целью монетизацию проекта. Пет-проект должен быть инвестицией всегда и в первую очередь должен делаться для развития навыков, а также если вам действительно интересно создать что-то новое. Монетизация - дело вторичное и хорошо, конечно, если проект получится монетизировать, но если не получится, вы всё равно будете в выигрыше.