Пример разработки простой функции на JavaScript

#soer #itubeteam

[SERDEVS]

*Я понял, что зря использовал слово "универсальное" в видео, это вводит в заблуждение. На самом деле смысл видео в том, что нужно разделять два варианта реализации: в виде отдельной обработки однотипных сущностей и в виде обработки однотипных сущностей как коллекции.*

[BeketChan]

Не знал про "0, 1, множество". Спасибо.

[kakasimenator]

А теперь звонит заказчик и говорит что нужно вычитать, но он не уверен, может вообще не нужно и кажется вы как-то медленно работаете.

[ВладиславИгнатенко-яз]

Правило "ноль, один, много" здесь следует применять не к операндам, а к операциям. Сумма - это элементарная математическая операция с двумя операндами, поэтому самая первая реализация абсолютно верная. Сумма трех чисел - это уже две однотипные элементарные операции, поэтому такую сумму следует рассматривать как сложную операцию, представленную бесконечной (ибо операций две, а значит много) последовательной группой элементарных операций сложения двух чисел - накопителя и текущего операнда - классический reduce. В силу принципа бритвы Оккама изначально следует использовать самый первый (return a + b) вариант решения задачи, а при возникновении необходимости добавления третьего операнда следует переименовать функцию во что-то вроде basesum, а на месте sum реализовать простейший алгоритм с использованием basesum в качестве аргумента-оператора функции reduce. Кстати, в питоне это будет выглядеть примерно так: def sum(*args, initializer=0): return functools.reduce(operator.add, args, initializer); Все остальные варианты - это дикие костыли и велосипеды.

[ccsfdsdsd]

Очень понятно и по полочкам объяснил мне понравилось, не задумывался о мусоре на входе

[New]

Помимо достойного кода ты еще и достойно объясняешь. Делай побольше таких видео, где рассказываешь такие вот инженерные хитрости. Спасибо за видео, мне понравилось.

[nikolaymatveychuk]

Я поступаю иначе
Приблизительно оцениваю риски по переписываю кода и затраты на его "идеальную" реализацию, а также риски связанные с более сложной архитектурой "идеального" решения. Таким образом получив задание написать функцию суммирования двух чисел, я сначала сказал бы, что нам это не надо, ведь "a + b" - это и есть функция суммирования двух чисел, а потому бессмысленно писать то, что уже написано (да и ещё на уровне синтаксиса сделано так, что очень удобно вызывать эту же функцию для 3 и более аргументов через последовательные вызовы a + b + c + d ...). Если бы заказчик (потенциальный работодатель) настоял бы всё же на написании этого кода, то первым делом я бы задал вопрос, может ли ему понадобиться функция для 3 и более аргументов, если бы он сказал "нет" или "не знаю", то получил бы реализацию "в лоб", ну те самые "return a+b". После "но теперь надо на 3", получил бы вторую реализацию с добавлением ещё одной переменной. А вот после "а теперь 4", функция была бы переписана на две: sumArray и sum, где вторая была бы декоратором для первой. А обосновал бы свой подход тем, что простота кода тоже крайне важна, в то время как затраты на переписывание крайне малы и можно позволить себе писать максимально простой код, пока переписывание не превратится в постоянную тенденцию.
Насчёт проверки валидности данных - придерживаюсь идеи, что их надо проверять не в каждом методе, а на входе. То есть все каналы получения данных должны быть обвешаны валидаторами, которые будут бить в барабаны, звонить администратору, президенту, а в случае крайней необходимости жать на красную кнопку, чтобы на них обратили внимание и исправили данные. При этом весь остальной код может полагать, что работает с верными данными, и проверять только самые критические места с высокой ценой ошибки. Опять же такое решение вызвано идеей минимизации сложности кода.

[FrankyyBalboa]

Очень крутой разбор полётов. Снимаю шляпу. Такого элегантного подхода к решению такой примитивной задачи я ещё не встречал!

[EvgenyTalagaev]

Спасибо, вроде бы задача простая, но получилось очень интересно

[adamsden]

Спасибо за видео.
Очень познавательно!
надеюсь на продолжение )

[АлександрКузнецов-шн]

Два варианта:
1. Если пишем продукт, который потом будем поддерживать и менять в зависимости от новых правок - не надо делать такую огромную функцию. Сказали два числа, значит два числа. И выкидывать Error, а не пытаться сделать функцию "умной". Если аналитик уверен, что потом может быть 3 и более чисел, то стоит делать ф-ю сразу с поддержкой множества аргументов.
2. Если пишем продукт 1 раз и времени достаточно, то делать ф-ю только для двух чисел, но можно сделать "умную".

"Поддержка 2х аргументов", "поддержка 0+ аргументов", "умная функция обработки разных типов данных" это все разные требования и исполнять их надо только если это действительно надо. Не уверен - уточни требования.

[cycloferon]

это было круто=) всегда надо думать на пару шагов вперед...

[ВладимирЗлатомрезов]

спасибо за видео, только вот консоль все загораживала а так все прекрасно.

[alexnitro]

Не хочу придираться, но в 2017 году лучше не использовать arguments, когда есть замечательный rest синтаксис. Да и новички лучше это поймут, чем непонятно откуда появившийся arguments.

function sum(...rest) {
return rest.reduce((acc, next) => acc + next, 0);
}

Где можно подробнее почитать про принцип 0, 1 или много?

[tapin]

при всём уважении, и понимании что это тест код, не надо reduce((a, b)... Нужно как-то так: args.reduce((result, item) => {

[daniillipatkin]

Понятно, что это показательный пример, но многие новички могут побежать писать такой "идеальный код" с прочеками на каждый микро ангстрем входных данных, а что в итоге? Одна вкладочка в хроме 500 мб, операции длиной в 3 секунды, js и так не шибко быстрый язык, а засирать его всякими проверками это вообще ад. Такая функция не предполагает, что туда пойдет что-то, кроме чисел, и если использовать то нагромождение, что вышло в конце, скажем, при рендере списка в реакте, то будет жопная боль

[АнатолийАлексеевич-ск]

Где о таком еще можно узнать, что почитать возможно??

[MrAironik]

интересно, что для разных языков одни и те же фундаментальные утверждения (про универсальность и устойчивость системы) порождают разный подход и разные образы мышления.
Если же говорить именно про собеседования, то тут всё сложно. На собеседовании всё зависит от ожиданий конкретного собеседующего. Одна и та же задача может у разнх людей проверять совершенно разные вещи. Например, задача про мёрж двух отсортированных массивов - это задача и на знание оценок сложностей алгоритмов в одних руках, и оценка умения экономить ресурсы в других. В результате, собеседование - это всегда лотерея где выигрыш - это совпадение ожиданий и ответов.

[CHERNOMORGAMES]

Я поставил на паузу на 03:52 и написал вот так(отзывы, советы, предложения):
var array = [0, 1, 3, 5, 7];
function summ(data) {
var n = data.length;
var result = 0;
for (var i = 0; i < n; ++i) {
result += data[i];
}
console.log(result);
}
summ(array);
P.S. пользую var'ы, т.к. они точно нигде не заглючат.

[einhviperz]

как насчет console.log(sum(1, sum(1, 1))); и т.д чтобы не переписывать функцию? в итоге 1 неизменная функция может складывать сколько угодно чисел при этом не изменяясь?