У меня 6 лет опыта разработки веба. Использую Клауд отслеживая каждое его действие. В рутинных задачах значительно ускоряет. Это станет для вас инструментом в тот момент, когда вы на берётесь опыта и нутром будете чуять, какая задача подойдёт для ллм, а что лучше самому.
путаница случается между слоями Widgets и Features
Если компонент можно назвать существительным - это виджет. Глагол(действие) - фича
И однажды, когда вам понадобится переместить компонент с уровня widget на уровень features вы проклянете всё
Тут проблема не в FSD а диких требованиях бизнеса если вам понадобилось перемещать целый widget в features. Ну либо в изначальной ошибке. И подобные изменение в любой методологии потребуют кучу изменений
Не знаю, даже в крупных проектах FSD при правильной готовке не вызывает боли. Особенно в связке с effector & farfetched. Я так же предпочитаю немного нарушить методологию положив особенно важные сторы которые влияют на все приложение в shared слой.
Не понимаю, чего в комментах столько негатива к LLM. Я программирую давно, скорость высокая. С приходом LLM моя скорость увеличилась думаю в 2 раза точно т.к. теперь всю рутину по типу написания мелких неприятных функций в стиле пересчёта кучи параметров в куче данных, сложные вычисления во временах/датах и прочее забрали модели.
Я точно знаю, что в функциях, которые не используют ничего экстравагантного внутри себя и их размер не превышает 100 строк кода - не будет ошибок. Модели отлично справляются с такими задачами. Если даже и будут ошибки, то когда функция покроется тестами - я это увижу. А если нужно написать какого то "монстра", и когда не знаешь с чего начать, LLM может дать пример кода, который просто натолкнет на мысль, а дальше я уже сам напишу.
В общем не знаю, как по мне при ограниченном использовании, без всяких курсоров и клаудов - LLM ускоряет работу и при этом код остаётся красивый и расширяемый.
"куда положить NotificationService" - если ты правильно используешь fsd сервисов обычно вообще нет. Если нужны уведомления во всем приложении в шаред пишешь lib, в app заворачиваешь все приложение. А ещё лучше - заверни это в пакет, устанавливай как либу и юзай в app
Что? Обжимать провода и сидеть в тех.поддержке? Если вы прошли такой путь, в котором тратили время на абсолютно не нужные для вашей основной сферы вещи, то не надо всем такой путь навязывать.
У нас кастомизированный FSD, NextJS, effector. Не смотря на хорошую архитектуру, документацию, типизированные контракты, ts и линтинг, код становится слишком запутанным.
Пример: у нас было действие которое дергало несколько других фичей ивентом, затем после того как работа каждой закончена, так же с помощью ивентов, финальный результат отправлялся на бэк, ожидался ответ, а затем новыми ивентами дергались другие вещи. Это породило хаос. Что и откуда прилетает не понятно. Повторюсь, все было хорошо документировано в коде, но что бы понять что делает та или иная фича, нужно было порой потратить минут 20, тогда как при классических подходах это занимало 2 минуты. Мы отказались от этого подхода и решили, что это не для фронта. FSD достаточно для удобного поддержания клиента.
P.S. если вам надо редактировать 12 файлов для добавления кнопки скорее всего вы работаете с быдлокодом
Абсолютно не согласен с расстановкой важности навыков. Как можно было поставить умение кодить на своем языке на 4 место? ИИ часто дают плохой код. И в 95% случаев, примерно на 300 строк кода там 1-2 ошибки которые если исправить код будет работать. Найти и исправить их можно только хорошо зная свой фреймворк и язык. Вот прямо сейчас я делаю объемный таск. Я решил доверится ИИ. Использовал около 1500 строк сгенерированного кода. Потратил часов 6 на исправления. Все заработало, но потом я обнаружил баг в работе функционала. Переправка кода этой же ИИ или другой результатов не дала и теперь мне нужно ковырять 1500 строк кода(примерно в 5 файлах) и искать в чем проблема.
Знание своего языка - это база номер 1. Нейронки все ещё слишком плохи
У vim есть огромнейший минус - даже изучив редактор вдоль и поперек, когда нужно какое то сложное решение, типа плагинов для i18n приходится кучу времени тратить что бы красиво все это сделать под vim.
В vscode я установил плагин vim и использую все плюсы норм ide и все плюсы vim раскладки
Я в 29 вкатился. TypeScript. Учился не вынимая 8 часов в день Эври дей включая выходные в течении полутора лет. Только бесплатно. Никаких курсов. Пет проекты начал делать с самого момента как понял базовые вещи. На пет проектах и учился, типа "хм, мне надо сделать пагинацию. Как это делается?". Через полтора года вот такой возни и более 1000 разосланных резюме пошли отклики. С 3го раза оффер
Сейчас уже уровень мидл + , но откликов теперь вообще нет. Не знаю в чем дело. Опыт теперь очень богатый и релевантный. Много разнообразных проектов потрогал, но откликов нима.
У меня 6 лет опыта разработки веба. Использую Клауд отслеживая каждое его действие. В рутинных задачах значительно ускоряет. Это станет для вас инструментом в тот момент, когда вы на берётесь опыта и нутром будете чуять, какая задача подойдёт для ллм, а что лучше самому.
Очередная HRюша пытается доказать, что она не такая ;)
Если компонент можно назвать существительным - это виджет. Глагол(действие) - фича
Тут проблема не в FSD а диких требованиях бизнеса если вам понадобилось перемещать целый widget в features. Ну либо в изначальной ошибке. И подобные изменение в любой методологии потребуют кучу изменений
Не знаю, даже в крупных проектах FSD при правильной готовке не вызывает боли. Особенно в связке с effector & farfetched. Я так же предпочитаю немного нарушить методологию положив особенно важные сторы которые влияют на все приложение в shared слой.
Несколько раз с командой мучали tailwind. Дружно пришли к мнению, что это не подходит для больших проектов.
У tailwind проблемы если проект большой. Как по мне вообще нет смысла использовать т.к. если проект вырастет все равно придется менять.
Css-in-js сложно поддерживать и проблемы с северным рендерингом.
Модули CSS лучшее как по мне, что мы имеем на данный момент.
Так же нравится postcss
Что теперь делать? Учиться программировать))
5 лет опыта, юзаю обычный ГПТ. Лимиты не кончаются, контроль за мной, где, что поменять я знаю сам. Работа ускорилась примерно в 2-3 раза.
В итоге программисты всё ещё на коне))
Не понимаю, чего в комментах столько негатива к LLM. Я программирую давно, скорость высокая. С приходом LLM моя скорость увеличилась думаю в 2 раза точно т.к. теперь всю рутину по типу написания мелких неприятных функций в стиле пересчёта кучи параметров в куче данных, сложные вычисления во временах/датах и прочее забрали модели.
Я точно знаю, что в функциях, которые не используют ничего экстравагантного внутри себя и их размер не превышает 100 строк кода - не будет ошибок. Модели отлично справляются с такими задачами. Если даже и будут ошибки, то когда функция покроется тестами - я это увижу. А если нужно написать какого то "монстра", и когда не знаешь с чего начать, LLM может дать пример кода, который просто натолкнет на мысль, а дальше я уже сам напишу.
В общем не знаю, как по мне при ограниченном использовании, без всяких курсоров и клаудов - LLM ускоряет работу и при этом код остаётся красивый и расширяемый.
Может автору стоило хотя бы разобраться в инструменте прежде чем обсирать его? Зачем серверные логи в браузере искать?
"куда положить NotificationService" - если ты правильно используешь fsd сервисов обычно вообще нет. Если нужны уведомления во всем приложении в шаред пишешь lib, в app заворачиваешь все приложение. А ещё лучше - заверни это в пакет, устанавливай как либу и юзай в app
Что? Обжимать провода и сидеть в тех.поддержке? Если вы прошли такой путь, в котором тратили время на абсолютно не нужные для вашей основной сферы вещи, то не надо всем такой путь навязывать.
Мы пробовали это и это с треском провалилось.
У нас кастомизированный FSD, NextJS, effector. Не смотря на хорошую архитектуру, документацию, типизированные контракты, ts и линтинг, код становится слишком запутанным.
Пример: у нас было действие которое дергало несколько других фичей ивентом, затем после того как работа каждой закончена, так же с помощью ивентов, финальный результат отправлялся на бэк, ожидался ответ, а затем новыми ивентами дергались другие вещи. Это породило хаос. Что и откуда прилетает не понятно. Повторюсь, все было хорошо документировано в коде, но что бы понять что делает та или иная фича, нужно было порой потратить минут 20, тогда как при классических подходах это занимало 2 минуты. Мы отказались от этого подхода и решили, что это не для фронта. FSD достаточно для удобного поддержания клиента.
P.S. если вам надо редактировать 12 файлов для добавления кнопки скорее всего вы работаете с быдлокодом
Абсолютно не согласен с расстановкой важности навыков. Как можно было поставить умение кодить на своем языке на 4 место? ИИ часто дают плохой код. И в 95% случаев, примерно на 300 строк кода там 1-2 ошибки которые если исправить код будет работать. Найти и исправить их можно только хорошо зная свой фреймворк и язык. Вот прямо сейчас я делаю объемный таск. Я решил доверится ИИ. Использовал около 1500 строк сгенерированного кода. Потратил часов 6 на исправления. Все заработало, но потом я обнаружил баг в работе функционала. Переправка кода этой же ИИ или другой результатов не дала и теперь мне нужно ковырять 1500 строк кода(примерно в 5 файлах) и искать в чем проблема.
Знание своего языка - это база номер 1. Нейронки все ещё слишком плохи
Обожаю vim, но ушел в vscode
У vim есть огромнейший минус - даже изучив редактор вдоль и поперек, когда нужно какое то сложное решение, типа плагинов для i18n приходится кучу времени тратить что бы красиво все это сделать под vim.
В vscode я установил плагин vim и использую все плюсы норм ide и все плюсы vim раскладки
Я в 29 вкатился. TypeScript. Учился не вынимая 8 часов в день Эври дей включая выходные в течении полутора лет. Только бесплатно. Никаких курсов. Пет проекты начал делать с самого момента как понял базовые вещи. На пет проектах и учился, типа "хм, мне надо сделать пагинацию. Как это делается?". Через полтора года вот такой возни и более 1000 разосланных резюме пошли отклики. С 3го раза оффер
Сейчас уже уровень мидл + , но откликов теперь вообще нет. Не знаю в чем дело. Опыт теперь очень богатый и релевантный. Много разнообразных проектов потрогал, но откликов нима.
Ага, а теперь представь - ты должен лечь на операцию, а оперировать тебя будет хирург, который бОльшую часть работ "схалтурил" с помощью ai.