От автора: вы когда-нибудь предлагали некоторый код JavaScript, а кто-то говорил: «Используйте цикл for, он быстрее ,чем forEach»? Это такой облом. Я всегда ненавижу возвращаться, чтобы удалить массив forEach с дюжиной или около того объектов, это кажется пустой тратой времени. Итак, в защиту методов массива, давайте поговорим о том, почему нам должно быть разрешено использовать их без вины или стыда.
О каких методах идет речь?
Есть много методов массива, но те, о которых я говорю, это итераторы массива: forEach, map, filter, every, reduce и тому подобное. Мне нравятся они в Ruby, и я был взволнован, когда новая версия JS добавила их.
Демонстрация
Я так рад, что теперь вместо этого:
const goodUsers = [];
for (let i = 0; i < users.length; i++) { const user = users[i]; if (user.isGood) goodUsers.push(user);
};Я могу сделать это:
const goodUsers = users.filter(user => user.isGood);
Они просто великолепны
Как вы можете видеть, они уменьшают потребность в повторяющемся, стандартном коде, но они также добавляют удобочитаемость. Вместо одного и того же цикла for для всего, использование map говорит мне, что я возвращаю массив, reduce означает, что я сокращаю значение на один, и filter… ну, это означает, что я фильтрую. Если вы не пытаетесь сделать что-нибудь сумасшедшее, добавьте метод к этому массиву и вызовите его. Это интуитивные методы, которые экономят время, так что вы можете беспокоиться о более важных вещах.
Так в чем проблема?
Все имеет свою цену; использование этих методов приводит к снижению производительности. Издержки, необходимые для использования метода массива, означают, что JS будет делать вещи менее эффективно. И в сегодняшнее время одержимость производительностью, кажется, проклятием для этих методов. За исключением того, что это не так. Потому что разница в скорости обычно измеряется в сотых долях секунды.
Дело в приоритетах
Когда старшие разработчики говорят «Используйте цикл for, он быстрее», они правы. Но кто сказал, что 100% оптимизация — это единственное, что меня волнует? Если мне нужно отфильтровать массив из 100 строк, меня не волнует буквально миллисекунда экономии, которую я получу от использования цикла for. Я предпочел бы иметь чистый, краткий, читаемый код.
Думайте
Беспокойство о скорости метода массива пахнет «излишней оптимизацией кода». Вы добьетесь большего, если будете беспокоиться о производительности, только если скорость станет проблемой. И даже тогда, вероятно, проблема будет в каком-то другом фрагменте — логической, а не синтаксической. Но не поймите меня неправильно, циклы for тоже не «плохие». Отнюдь нет!
Когда использовать цикл for?
Если вам нужно работать с гигантскими списками, тогда можно почувствовать влияние на производительность. Но кроме скорости циклы for дают вам настраиваемое поведение. Они могут делать специальные вещи, такие как: использовать break или continue; использовать число вместо массива; использование await; начать с любого места, двигаться в любом направлении на любое расстояние. Но имейте в виду, что использование в циклах break / continue и await также сопряжено с определенными затратами. Обратите внимание, что это не очень распространенные причины, по которым все больше разработчиков используют по умолчанию новые необычные методы и выполняют циклы for только при необходимости.
Все меняется
В течение многих лет циклы for были единственным реальным вариантом. И я думаю, что причина, по которой я в основном слышу жалобы от старых разработчиков, заключается в том, что изменения могут показаться ненужными. Это формально более производительно, на практике это часто не так, поэтому не продолжайте использовать старые методы? И поверь мне, я могу вас понять. Разработчики JS стремятся к новейшим вещам просто потому, что они новые (я смотрю на тебя, Svelte). Но использование итераторов массива не похоже на изменение ради изменений, это похоже на приятное улучшение, после долгих разочарований. Это просто следующая итерация.
Удачного всем кодирования, Майк.
Автор: Mike Cronin
Источник: https://levelup.gitconnected.com
Редакция: Команда webformyself.