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