Это я не конкретно этот пример описываю, а вообще. Когда вы начинаете считать строчки кода, задумайтесь — а оно вам надо?
И я полностью согласен с вашими доводами по сложности кода и количеству строк. Просто нужно было хоть как-то оценить разные подходы в сравнении(и это только в рамках заметки на habr). Как я и написал, я не придумал другого способа оценки. Но если вы можете предложить нечто более подходящее — я с радостью перепишу раздел с выводами.
Если сильно хочется иметь на выходе именно синхронную функцию
не было такого непреодолимого желания. Ваш вариант тоже имеет место быть, только тогда надо его привести в общий вид, примерно, так:
function makeRequests(urls, initialData, callback) {
let result = Promise.resolve(initialData);
for (const url of urls) {
result = result
.then(res => fakeFetch(url, res));
}
return result
.then(res => callback(null, res);
}
Я с вами полностью согласен, но я попытался реализовать ровно те способы решения, которые предлагали сходу кандидаты.
В любом случае, если вам необходимо еще проверить умение работы с гененераторами/рекурсиями/AsyncAwait/Reduce/For of, то это можно сделать в рамках одной задачи, нежели на каждый случай формулировать новую.
Вы точно знаете что такое простой, легко и быстро воспринимаемый и читаемый код?
Думаю, это довольно субъективное мнение. Но все, надеюсь, согласятся с тем, что решение с использованием генераторов намного более громоздкое и не наглядное (или все же кто-то считает иначе?). Именно это и было целью этой заметки. А еще рассуждения на тему того, что у любой задачи есть несколько решений, и в каждом конкретном случае, какие-то подходы могут быть избыточны или громоздки.
еще раз повторюсь: цель собеседования — посмотреть на ход мыслей и опыт интервьюируемого. Что бы он не предложил в качестве решения, все равно будут обсуждаться разные решения, которыми можно было бы решить задачу. А уже в ходе обсуждения становятся видны достоинства и недостатки каждого решения.
Ваш вариант с reduce это как раз то, что мне пришло в голову в самую первую очередь
К сожалению, мне ни разу не пришлось сходу слышать этого ответа. Но все прекрасно понимают, что в ходе интервью кандидат часто нервничает и выдает решение побыстрее, чтоб не делать большую паузу. Когда уже переходит на написание, немного поразмыслив, некоторая часть людей уже предлагала точно такое же решение.
двигался бы в сторону решения которое нравится интервьюверу
то что интервьювер ожидал и что ему нравится — разные вещи.
Если бы от кандидата требовалось только решение задачи, это происходило бы с помощью инструментов онлайн тестирования. Но это не спортивное программирование. Именно поэтому, подобные задачи обсуждаются и решаются у доски (так называемый white board interview)
возвращет Promise (как вам вообще в голову идея с callback пришла в 2020)
callback для возвращения использовался только для того, чтоб постараться поставить все решения в одинаковые условия (и делалось это только для заметки на habr), потому что в случае к возвращением промиса, например, рекурсия или reduce получат преимущества в виде уменьшения кода на одну строку, так как можно будет просто сделать:
return url.reduce
В случае же с генераторами и асинхронными генераторами этого не выйдет.
Но тем не менее, даже в 2020 году callback все еще используется, как минимум на стороне сервера, например, загляните посмотрите в сторону NodeJs: nodejs.org/api/fs.html
Не могу не согласиться. Никто не поддает сомнению, что императивные for быстрее в несколько раз функций высшего порядка.
И forEach, в свою очередь, быстрее map (хотя в случае с forEach это происходит скорее из-за того, что forEach просто вызывает callBack функцию не дожидаясь результатов).
Но, тем не менее, функции высшего порядка на порядок нагляднее (разумеется, это субъективное мнение). А Также присутствует возможность чейнинга, что увеличивает наглядность в сложных случаях, хоть и за счет производительности.
Разве на подобных собеседованиях не принято искать того кто будет разгребать говны написанные собеседующими
на мой взгляд, основная цель собеседования — не опустить всеми методами интервьюируемого, как в армии, а посмотреть его ход мыслей и проверить опыт. Именно поэтому, на white board интервью в силиконовой долине, за решение принимается даже псевдокод для алгоритмических задач.
выделяет лишнюю память на promise обертки
Напомню, что функция с ключевым словом async всегда возвращает промис. Значения других типов оборачиваются в завершившийся успешно промис автоматически.
— выделяет лишнюю память на функцию аккумуляции, то есть GC лишний раз будет дергаться
Для переменной const url в цикле for, тоже выделяется память, при чем она выделяется на каждой итерации кода.
— не короче чем «for of»:
«for of» тоже может быть решением, но тогда давайте объективно оценивать. А для этого нам этот код надо привести в общий вид, произведя форматирование кода. Потому что reduce тоже можно превратить в однострочник, только это будет не объективно.
И тогда код приобретет примерно следующий вид:
async function seriesFetch(callback) {
let result;
for (const url of urls) {
result = await fakeFetch(url, result);
};
callback(result);
}
В таком варианте уже можно сравнивать объективнее.
Новичков считающих себя «не новичками» можно определить по использованию reduce там где этого не требуется.
И я полностью согласен с вашими доводами по сложности кода и количеству строк. Просто нужно было хоть как-то оценить разные подходы в сравнении(и это только в рамках заметки на habr). Как я и написал, я не придумал другого способа оценки. Но если вы можете предложить нечто более подходящее — я с радостью перепишу раздел с выводами.
не было такого непреодолимого желания. Ваш вариант тоже имеет место быть, только тогда надо его привести в общий вид, примерно, так:
и потом уже сравнивать
В любом случае, если вам необходимо еще проверить умение работы с гененераторами/рекурсиями/AsyncAwait/Reduce/For of, то это можно сделать в рамках одной задачи, нежели на каждый случай формулировать новую.
Думаю, это довольно субъективное мнение. Но все, надеюсь, согласятся с тем, что решение с использованием генераторов намного более громоздкое и не наглядное (или все же кто-то считает иначе?). Именно это и было целью этой заметки. А еще рассуждения на тему того, что у любой задачи есть несколько решений, и в каждом конкретном случае, какие-то подходы могут быть избыточны или громоздки.
К сожалению, мне ни разу не пришлось сходу слышать этого ответа. Но все прекрасно понимают, что в ходе интервью кандидат часто нервничает и выдает решение побыстрее, чтоб не делать большую паузу. Когда уже переходит на написание, немного поразмыслив, некоторая часть людей уже предлагала точно такое же решение.
то что интервьювер ожидал и что ему нравится — разные вещи.
Если бы от кандидата требовалось только решение задачи, это происходило бы с помощью инструментов онлайн тестирования. Но это не спортивное программирование. Именно поэтому, подобные задачи обсуждаются и решаются у доски (так называемый white board interview)
callback для возвращения использовался только для того, чтоб постараться поставить все решения в одинаковые условия (и делалось это только для заметки на habr), потому что в случае к возвращением промиса, например, рекурсия или reduce получат преимущества в виде уменьшения кода на одну строку, так как можно будет просто сделать:
В случае же с генераторами и асинхронными генераторами этого не выйдет.
Но тем не менее, даже в 2020 году callback все еще используется, как минимум на стороне сервера, например, загляните посмотрите в сторону NodeJs: nodejs.org/api/fs.html
И forEach, в свою очередь, быстрее map (хотя в случае с forEach это происходит скорее из-за того, что forEach просто вызывает callBack функцию не дожидаясь результатов).
Но, тем не менее, функции высшего порядка на порядок нагляднее (разумеется, это субъективное мнение). А Также присутствует возможность чейнинга, что увеличивает наглядность в сложных случаях, хоть и за счет производительности.
на мой взгляд, основная цель собеседования — не опустить всеми методами интервьюируемого, как в армии, а посмотреть его ход мыслей и проверить опыт. Именно поэтому, на white board интервью в силиконовой долине, за решение принимается даже псевдокод для алгоритмических задач.
Напомню, что функция с ключевым словом async всегда возвращает промис. Значения других типов оборачиваются в завершившийся успешно промис автоматически.
Для переменной const url в цикле for, тоже выделяется память, при чем она выделяется на каждой итерации кода.
«for of» тоже может быть решением, но тогда давайте объективно оценивать. А для этого нам этот код надо привести в общий вид, произведя форматирование кода. Потому что reduce тоже можно превратить в однострочник, только это будет не объективно.
И тогда код приобретет примерно следующий вид:
В таком варианте уже можно сравнивать объективнее.
Оценил ваш сарказм