Решит-то решит, вопрос в том, насколько это решение будет жизнеспособно от синтетического программиста, который 100% времени посвящал олимпиадным задачам
Какой-то полный бред только что прочитал. Было бы всё так просто...
Какие задачи, они что, одинаковые по сложности? Эти задачи абсолютно независимы друг от друга? Нет скорее всего. 2 сотрудника - это не в 2 раза быстрее. И чем больше сотрудников, тем меньше КПД будет у каждого, вроде даже формула существует (вы любите математику, я смотрю). Как составлены задачи, блокируют они друг друга или нет? Вы оцениваете эти задачи или разработчики? (С чего вы решили, что в месяц должно выполняться 20 задач, а не 8)? Вы узнавали у сотрудников, почему так получилось, делали выводы или только калькулятором пользовались и циферки сравнивали?
Глобального маркера не будет, потому что невозможно вписать всё многообразие человечества в логический тип Boolean. Все зачем-то пытаются всё упростить, а это невозможно. Если вам кажется, что это возможно, то вы попадаете на ошибку выжившего и просто напросто просматриваете хороших кандидатов из-за своего фильтра.
Дело не в форме и стиле, а в том, что понимание продукта приходит не сразу. Поначалу, если продукт сложный, может вообще не быть понимания, что будет на главной странице и для чего она нужна. А со временем будет приходить понимание, что можно вынести на главную, как она будет выглядеть и чем она привлечет пользователя и какие функции будет выполнять.
Тут вопрос в другом совсем. Конечно же хорошо заработать на своём проекте деньги, кто спорит. Но есть другая проблема - разочарование, если цель не будет достигнута.
Как мне кажется намного лучше иметь другие цели как первостепенные (а именно - инвестиция в себя, развитие навыков, да и просто создание интересного продукта как минимум для себя). Эти цели 100% достижимы и в них вы не будете разочарованы. И уже после того, как первые цели достигнуты, можно переходить к следующей - монетизации.
Я считаю , что намного больше шансов достигнуть вторую цель (монетизацию проекта), если у вас также есть и другие цели (о которых я писал). А на одной монетизации будет сложно уехать, легко будет сорваться и перестать этим заниматься. Всё равно, что работать на нелюбимой работе с единственной разницей, что денег вы за это не получите, по крайней мере в ближайшее время.
Никогда не надо делать первой целью монетизацию проекта. Пет-проект должен быть инвестицией всегда и в первую очередь должен делаться для развития навыков, а также если вам действительно интересно создать что-то новое. Монетизация - дело вторичное и хорошо, конечно, если проект получится монетизировать, но если не получится, вы всё равно будете в выигрыше.
Я не говорю про то, что не надо оптимизировать. Но не будем же мы оптимизировать абсолютно всё по-максимуму? В любом случае, 20% работы по оптимизации принесут 80% результата +-, а остальное и не надо, это уже лишнее, если вы не пишите шахматную программу, например, где по сути одна только оптимизация базового алгоритма и происходит. Не надо оптимизировать, ускоряя загрузку чего-либо на сотые доли, если это ухудшает читаемость кода. Не надо также "оптимизировать", не зная, принесёт ли это результат (используя бездумно useMemo и React.memo). Главное всё делать с пониманием.
Вот-вот) By default лично я использую useMemo в кастомных хуках, чтобы в будущем не думать об этом, когда использую что-то из хуков в зависимостях useEffect, например. Но это тоже не догма)
А так, если бы мне дали компонент на 300 или больше строк и спросили, что с ним не так, здесь намного однозначное был бы ответ.
Но тем не менее, если работает и не лагает, не нужно ничего "оптимизировать", особенно за счёт читаемости кода. Да и на самом деле далеко не факт, что использование React.memo или useMemo ускорит что-то. Это ведь тоже накладные расходы, которые могут превышать расходы по рендерингу, например, 50 элементов списка. Если вы можете доказать, что это что-то ускорит - ок, но стоит ли платить за это худшей читаемостью кода? Я считаю, что нет. Задумываться об оптимизации нужно, но только тогда, когда действительно есть проблема и тогда нужно её решать.
Если специалистов не хватало 2 года назад, то сейчас их тоже будет не хватать. Чудес не бывает. Из этих откликов 90% - какие-то левые люди, которые краем уха слышали про IT и 10% - кандидаты, из которых можно выбирать.
Может быть это просто потому, что люди, владеющие лошадью, просто уже более успешны -> имеют больше денег -> имеют возможность купить лошадь? Причинно-следственная связь обратная, вывод в исследовании неверный)
Я уверен, там была предыстория, перед тем как увидели книжку и уволили.
Решит-то решит, вопрос в том, насколько это решение будет жизнеспособно от синтетического программиста, который 100% времени посвящал олимпиадным задачам
Какой-то полный бред только что прочитал.
Было бы всё так просто...
Какие задачи, они что, одинаковые по сложности?
Эти задачи абсолютно независимы друг от друга? Нет скорее всего. 2 сотрудника - это не в 2 раза быстрее. И чем больше сотрудников, тем меньше КПД будет у каждого, вроде даже формула существует (вы любите математику, я смотрю).
Как составлены задачи, блокируют они друг друга или нет?
Вы оцениваете эти задачи или разработчики? (С чего вы решили, что в месяц должно выполняться 20 задач, а не 8)?
Вы узнавали у сотрудников, почему так получилось, делали выводы или только калькулятором пользовались и циферки сравнивали?
Можно наверное просто разделить хранение даты и времени в таком случае (делать это отдельно)
Чем-то напоминает супер-урезанную feature-sliced архитектуру (FSD)
Глобального маркера не будет, потому что невозможно вписать всё многообразие человечества в логический тип Boolean.
Все зачем-то пытаются всё упростить, а это невозможно. Если вам кажется, что это возможно, то вы попадаете на ошибку выжившего и просто напросто просматриваете хороших кандидатов из-за своего фильтра.
В 21-м веке диплом - это самый последний фильтр, на который надо смотреть при выборе кандидата.
Дело не в форме и стиле, а в том, что понимание продукта приходит не сразу. Поначалу, если продукт сложный, может вообще не быть понимания, что будет на главной странице и для чего она нужна. А со временем будет приходить понимание, что можно вынести на главную, как она будет выглядеть и чем она привлечет пользователя и какие функции будет выполнять.
Чет сыровато выглядит по первому впечатлению, когда включил темную тему в доке и увидел черный шрифт на черном фоне..
Тут вопрос в другом совсем. Конечно же хорошо заработать на своём проекте деньги, кто спорит.
Но есть другая проблема - разочарование, если цель не будет достигнута.
Как мне кажется намного лучше иметь другие цели как первостепенные (а именно - инвестиция в себя, развитие навыков, да и просто создание интересного продукта как минимум для себя). Эти цели 100% достижимы и в них вы не будете разочарованы. И уже после того, как первые цели достигнуты, можно переходить к следующей - монетизации.
Я считаю , что намного больше шансов достигнуть вторую цель (монетизацию проекта), если у вас также есть и другие цели (о которых я писал). А на одной монетизации будет сложно уехать, легко будет сорваться и перестать этим заниматься. Всё равно, что работать на нелюбимой работе с единственной разницей, что денег вы за это не получите, по крайней мере в ближайшее время.
Никогда не надо делать первой целью монетизацию проекта. Пет-проект должен быть инвестицией всегда и в первую очередь должен делаться для развития навыков, а также если вам действительно интересно создать что-то новое. Монетизация - дело вторичное и хорошо, конечно, если проект получится монетизировать, но если не получится, вы всё равно будете в выигрыше.
Я не говорю про то, что не надо оптимизировать. Но не будем же мы оптимизировать абсолютно всё по-максимуму? В любом случае, 20% работы по оптимизации принесут 80% результата +-, а остальное и не надо, это уже лишнее, если вы не пишите шахматную программу, например, где по сути одна только оптимизация базового алгоритма и происходит. Не надо оптимизировать, ускоряя загрузку чего-либо на сотые доли, если это ухудшает читаемость кода. Не надо также "оптимизировать", не зная, принесёт ли это результат (используя бездумно useMemo и React.memo). Главное всё делать с пониманием.
Это будет фильтр по чему угодно, но только не по критерию "что-то из себя представляет". Огромное заблуждение.
Вот-вот)
By default лично я использую useMemo в кастомных хуках, чтобы в будущем не думать об этом, когда использую что-то из хуков в зависимостях useEffect, например. Но это тоже не догма)
А так, если бы мне дали компонент на 300 или больше строк и спросили, что с ним не так, здесь намного однозначное был бы ответ.
Но тем не менее, если работает и не лагает, не нужно ничего "оптимизировать", особенно за счёт читаемости кода.
Да и на самом деле далеко не факт, что использование React.memo или useMemo ускорит что-то. Это ведь тоже накладные расходы, которые могут превышать расходы по рендерингу, например, 50 элементов списка. Если вы можете доказать, что это что-то ускорит - ок, но стоит ли платить за это худшей читаемостью кода? Я считаю, что нет.
Задумываться об оптимизации нужно, но только тогда, когда действительно есть проблема и тогда нужно её решать.
А лучше тогда useQuery использовать, может?)
Зачастую, чтобы написать быстро, нужно писать медленно. Быстрое клёпанье может замедлить разработку в целом на дистанции.
Если специалистов не хватало 2 года назад, то сейчас их тоже будет не хватать. Чудес не бывает. Из этих откликов 90% - какие-то левые люди, которые краем уха слышали про IT и 10% - кандидаты, из которых можно выбирать.
Нет
Скорее нет, только если человек делал много форм с хорошей валидацией
Может быть это просто потому, что люди, владеющие лошадью, просто уже более успешны -> имеют больше денег -> имеют возможность купить лошадь? Причинно-следственная связь обратная, вывод
в исследовании неверный)