Уровни погружения в сложность кода
В коментарии к посту выше накидали пачку краевых случаев при которых для одних и тех же вычислений и данных useMemo будет оптимально или не оптимально.
В разработке все время так, не получается соблюдать несколько простых паттернов для написания простого и эффективного кода, всегда находятся условия, игнорирование которых может привезти к ошибкам или просадкам производительности, а обработка к сложному или объемному коду. Как же соблюсти баланс?
Разделяется работу со сложностью на три этапа.
1) Дефолты. Определите небольшой набор базовых паттернов, которые успешно покрывают большую часть задач и используйте их при написании нового кода, покрывая success path и особо не думая об оптимизациях. Пример таких паттернов в предыдущем посте.
2) Ревью. Перед коммитом кода пробегитесь пару раз по дифу в стейдже и поревюйте собственные изменения с точки зрения того что можно оптимизировать, что может пойти не так и на что нужно еще тестов добавить. Так же ревью членов команды на ПРе / МРе.
3) Диагностика. Самый правильный способ нахождения проблем и узких мест - запуск кода в реальных условиях. Это может быть как e2e среда тестирования, так и прод - что и когда выбрать отдельная тема. Конкретно для профилирования производительности реакта есть очень мощный react-render-tracker. Больше о тестировании производительности можно почитать Ивана Акулова.
В коментарии к посту выше накидали пачку краевых случаев при которых для одних и тех же вычислений и данных useMemo будет оптимально или не оптимально.
В разработке все время так, не получается соблюдать несколько простых паттернов для написания простого и эффективного кода, всегда находятся условия, игнорирование которых может привезти к ошибкам или просадкам производительности, а обработка к сложному или объемному коду. Как же соблюсти баланс?
Разделяется работу со сложностью на три этапа.
1) Дефолты. Определите небольшой набор базовых паттернов, которые успешно покрывают большую часть задач и используйте их при написании нового кода, покрывая success path и особо не думая об оптимизациях. Пример таких паттернов в предыдущем посте.
2) Ревью. Перед коммитом кода пробегитесь пару раз по дифу в стейдже и поревюйте собственные изменения с точки зрения того что можно оптимизировать, что может пойти не так и на что нужно еще тестов добавить. Так же ревью членов команды на ПРе / МРе.
3) Диагностика. Самый правильный способ нахождения проблем и узких мест - запуск кода в реальных условиях. Это может быть как e2e среда тестирования, так и прод - что и когда выбрать отдельная тема. Конкретно для профилирования производительности реакта есть очень мощный react-render-tracker. Больше о тестировании производительности можно почитать Ивана Акулова.