React Testing Library - устраивает более чем, мы на него переехали с enzyme. Изъянов в нем не нашли, даже стало немного приятней тесты писать, но это конечно субъективно.
По поводу vite, до него к сожалению руки еще не дошли. Очень хочу протестировать до конца swc и понять чем придется пожертвовать, если babel отключим. А потом уже esbuild, vite и может еще что-то интересное подвернется.
Вы абсолютно правы от части, все будет проще если вы приходите на проект в качестве условного тим-лида. Но не забывайте, что всегда можно поговорить с коллегами и предложить им тот или иной инструмент. Согласятся — замечательно, нет — вы по крайней мере пытались.
Действительно, продолжать можно долго, если прочитать только первый абзац статьи, мне очень жаль что Вы не поняли ее смысла и нашли в ней призывы положить прод в первый день и остановить разработку на пол года.
Статья про технический чек лист и чем себя занять кроме клепания фич, пять дней в неделю.
Конечно экономят. Если следовать советам от Lighthouse — ваше приложение станет легче, загружаться оно будет быстрее (экономя время пользователя и трафик). Браузеру будет нужно тратить намного меньше ресурсов для парсинга файлов.
Простите, вы делаете проект для себя или для пользователя?
Мы делаем наши приложения для пользователей в первую очередь.
Я с Вами согласен от части, руками тоже все можно делать и более того, если хочется пойти дальше то это будет необходимо. Но нет ничего плохого в автоматизации проверок, они экономят Вам время.
Данный вопрос довольно тяжелый, так как к каждому человеку нужен свой подход. Но вот подходы которыми я пользуюсь с бизнесом.
Сроки
Вы можете оперировать сроками решения задач. Скажем так, если уделить время на рефакторинг конкретного куса кода — то реализация любой задачи в этой области будет стоить куда меньше чем без рефакторинга.
Баги
Вы можете оперировать тем, что без рефакторинга качество вашего продукта падает с каждой новой фичей. И если вы не уделите этому время, то в скором будущем — возможно вы не сможете реализовать фичу без полной переделки функциональности.
Пользователи
Можно попытаться продать рефакторинг улучшением UX. Ведь довольный пользователь — это меньше отказов и больше конверсия.
Если взять разработку, то все зависит от вашей позиции в команде и от ваших софт скилов. Можно провести конструктивную встречу с командой или тим-лидом. Если Вас не услышали — не отчаивайтесь, возможно на то были причины. Переварите беседу и попробуйте еще раз через месяц. За мою карьеру было и такое, что от желания сделать проект лучше, до выкатки в прод — проходило пол года.
Представьте ситуацию, вы первый день на новом для вас проекте, с чего будете начинать? Опишите свои шаги.
Более того, это набор чеков, если они все успешно будут пройдены — то вопросов нет, но как показывает практика в каком-то объеме эти шаги Вам будут нужны.
В самом начале я упомянул, что бэклога хватит на несколько месяцев вперед. Это не значит, что на всех проектах всё займет одинаковое количество времени. Это, скорее, в среднем по больнице, учитывая, что большую часть рабочего времени мы решаем проблемы бизнеса.
Нет, Вы не правильно понимаете. Разработчик должен уделять вниманию качеству кодовой базы и ЧСВ тут не при чем. Вы же дома убираетесь? Вот так же нужно убираться и у себя в проекте. В крупных компаниях под техническую квоту закладывают время и дают возможность разработчикам исправить или улучшить кодовую базу. И ни кто не говорит что вы должны только этим заниматься, рефакторинг можно делать постепенно.
Как я Jest с помощью SWC ускорял
Точно, есть же еще и terser.
Вьюшки часом не на react? Интересуюсь с целью понять на сколько хорошо работает react-refresh из коробки, немного смущен пометкой "эксперимент".
И за наводку на
loadable
тоже спасибо, понадобится.Как я Jest с помощью SWC ускорял
React Testing Library - устраивает более чем, мы на него переехали с enzyme. Изъянов в нем не нашли, даже стало немного приятней тесты писать, но это конечно субъективно.
По поводу vite, до него к сожалению руки еще не дошли. Очень хочу протестировать до конца swc и понять чем придется пожертвовать, если babel отключим. А потом уже esbuild, vite и может еще что-то интересное подвернется.
Как привести проект в чувство
Как привести проект в чувство
Как привести проект в чувство
Как привести проект в чувство
Как привести проект в чувство
Статья про технический чек лист и чем себя занять кроме клепания фич, пять дней в неделю.
Как привести проект в чувство
Конечно экономят. Если следовать советам от Lighthouse — ваше приложение станет легче, загружаться оно будет быстрее (экономя время пользователя и трафик). Браузеру будет нужно тратить намного меньше ресурсов для парсинга файлов.
Мы делаем наши приложения для пользователей в первую очередь.
Как привести проект в чувство
Как привести проект в чувство
Сроки
Вы можете оперировать сроками решения задач. Скажем так, если уделить время на рефакторинг конкретного куса кода — то реализация любой задачи в этой области будет стоить куда меньше чем без рефакторинга.
Баги
Вы можете оперировать тем, что без рефакторинга качество вашего продукта падает с каждой новой фичей. И если вы не уделите этому время, то в скором будущем — возможно вы не сможете реализовать фичу без полной переделки функциональности.
Пользователи
Можно попытаться продать рефакторинг улучшением UX. Ведь довольный пользователь — это меньше отказов и больше конверсия.
Если взять разработку, то все зависит от вашей позиции в команде и от ваших софт скилов. Можно провести конструктивную встречу с командой или тим-лидом. Если Вас не услышали — не отчаивайтесь, возможно на то были причины. Переварите беседу и попробуйте еще раз через месяц. За мою карьеру было и такое, что от желания сделать проект лучше, до выкатки в прод — проходило пол года.
Как привести проект в чувство
Вас ни кто не призывает делать это за один день.
Как привести проект в чувство
Более того, это набор чеков, если они все успешно будут пройдены — то вопросов нет, но как показывает практика в каком-то объеме эти шаги Вам будут нужны.
Как привести проект в чувство
Нет, Вы не правильно понимаете. Разработчик должен уделять вниманию качеству кодовой базы и ЧСВ тут не при чем. Вы же дома убираетесь? Вот так же нужно убираться и у себя в проекте. В крупных компаниях под техническую квоту закладывают время и дают возможность разработчикам исправить или улучшить кодовую базу. И ни кто не говорит что вы должны только этим заниматься, рефакторинг можно делать постепенно.
Ускоряем сборку веб-приложения с webpack
Они включены по умолчанию, пруф.
А то что в доке написано иначе — к сожалению так часто бывает, что readme ни кто не меняет.