Items это LINQ обертка над Item[], внутре у нее неонка которая в генерируемом javascript дергает find, fiter и проч.
Проверку аргументов на null в private методах обычно не делаем
Да, это ок, но по сути то же самое. Почему не рассмотреть HashSet<Item> или HashMap<Id, Item> ? Не всегда это лучшее решение, но очень часто
Все зависит от задачи. Если мы про shopping cart то количество предметов в ней не будет того порядка когда разница между hashmap будет существенна и оправданна. Плюс кто сказал что надо будет всегда искать по id? А по категории товара, по количеству, по стоимости?
Я не против быстрого кода, у меня задачи часто такие что без оптимизации просто никуда, но оптимизировать и усложнять там где можно обойтись чем то простым и надежным считаю напрасной тратой времени. То есть если бы речь шла о методе isItemInOrderHistory() то бяда пичалька, а так не особо.
Если не считать что твой старпер не верит в электречество и array.find() не использует, не говоря уже про LINQ. Code review у меня бы по этому не прошел. Читабельность страдает
Items это LINQ обертка над Item[], внутре у нее неонка которая в генерируемом javascript дергает find, fiter и проч.
Проверку аргументов на null в private методах обычно не делаем
Да, это ок, но по сути то же самое. Почему не рассмотреть HashSet<Item> или HashMap<Id, Item> ? Не всегда это лучшее решение, но очень часто
Все зависит от задачи. Если мы про shopping cart то количество предметов в ней не будет того порядка когда разница между hashmap будет существенна и оправданна. Плюс кто сказал что надо будет всегда искать по id? А по категории товара, по количеству, по стоимости?
Я не против быстрого кода, у меня задачи часто такие что без оптимизации просто никуда, но оптимизировать и усложнять там где можно обойтись чем то простым и надежным считаю напрасной тратой времени. То есть если бы речь шла о методе isItemInOrderHistory() то бяда пичалька, а так не особо.
Если не считать что твой старпер не верит в электречество и array.find() не использует, не говоря уже про LINQ. Code review у меня бы по этому не прошел. Читабельность страдает
Я там выше в цитате два ключевых момента выделил. Да, не всегда ХэшМап/Таблица это лучшее решение. Но а) их нужно рассмотреть как вариант бэ) даже перебор нужно делать элегантнее
АццкоМото wrote: 08 Oct 2018 23:05
Хотя на самом деле куда интереснее, когда нужно, например, посчитать общую стоимость айтемов в карте в предположении, что их может быть чуть больше 100500 миллионов. Тоже вроде бы не бином ньютона, а мало кто напишет эффективно.
согласен что интереснее, но не согласен что не бином.
добавим сюда вполне ожидаемые требования по high availability, scalability, latency и задача сразу превращается в нетривиальный проект.
я бы сказал, что нетривиально будет все это делать с нуля и самому. но все колеса изобретены до нас и в буквально несколько строк это можно сделать с RxJava или другой подобной "реактивной" бляблятекой. но чтобы высрать эти несколько строк у Интерраптушки уйдет полчаса, у меня - день-два, а у некоторых не выйдет вовсе
если мы говорим про агрегацию 100500 миллионов, то одной блятекой тут не обойтись даже интерапту, не зря же наворотили разных хадупов, спарков и следом распределенных in-memory DB.
сначала нужно все это барахло найти поставить настроить и только потом можно будет немного расслабившись налить чайку и написать несколько строчек работающего кода.
major Major Major Major wrote: 09 Oct 2018 17:18
Если не считать что твой старпер не верит в электречество и array.find() не использует, не говоря уже про LINQ. Code review у меня бы по этому не прошел. Читабельность страдает
Ну тогда по идее самое оно параметризовать тип контейнера в реализации и специализировать функцию поиска, если она отличается от тривиального find()
Komissar wrote: 09 Oct 2018 07:49
У мужика нормальный читаемый код, скорее всего для данной задачи можно обойтись перебором. Меня напрягло, чтотне взбрасывается exception, если в корзине обнаружен item which is null.
Komissar wrote: 09 Oct 2018 07:49
У мужика нормальный читаемый код, скорее всего для данной задачи можно обойтись перебором. Меня напрягло, чтотне взбрасывается exception, если в корзине обнаружен item which is null.
Проблема в том, что вы примерно схожего возраста. Поэтому для вас это норм код. Для меня - нет, хоть я себя и чувствую стариком. Приемлемый 30-летний погромист просто блеванет
На самом деле 30-летний погромист учился кодить на питоне, поэтому он выдаст чтото вроде
Komissar wrote: 09 Oct 2018 07:49
У мужика нормальный читаемый код, скорее всего для данной задачи можно обойтись перебором. Меня напрягло, чтотне взбрасывается exception, если в корзине обнаружен item which is null.
Проблема в том, что вы примерно схожего возраста. Поэтому для вас это норм код. Для меня - нет, хоть я себя и чувствую стариком. Приемлемый 30-летний погромист просто блеванет
На самом деле 30-летний погромист учился кодить на питоне, поэтому он выдаст чтото вроде
Komissar wrote: 09 Oct 2018 07:49
У мужика нормальный читаемый код, скорее всего для данной задачи можно обойтись перебором. Меня напрягло, чтотне взбрасывается exception, если в корзине обнаружен item which is null.
Проблема в том, что вы примерно схожего возраста. Поэтому для вас это норм код. Для меня - нет, хоть я себя и чувствую стариком. Приемлемый 30-летний погромист просто блеванет
На самом деле 30-летний погромист учился кодить на питоне, поэтому он выдаст чтото вроде
def is_in_cart(item, cart):
return item in cart.getItems()
Не принципиально. Суть в том что 30-летний погромист напишет на питоне обход листа в одну строчку, и забудет. Пока Комиссар будет выяснять, не подменили-ли инопланетяне у него в карте один айтем на нулл.
Komissar wrote: 09 Oct 2018 07:49
У мужика нормальный читаемый код, скорее всего для данной задачи можно обойтись перебором. Меня напрягло, чтотне взбрасывается exception, если в корзине обнаружен item which is null.
Проблема в том, что вы примерно схожего возраста. Поэтому для вас это норм код. Для меня - нет, хоть я себя и чувствую стариком. Приемлемый 30-летний погромист просто блеванет
На самом деле 30-летний погромист учился кодить на питоне, поэтому он выдаст чтото вроде
def is_in_cart(item, cart):
return item in cart.getItems()
Не принципиально. Суть в том что 30-летний погромист напишет на питоне обход листа в одну строчку, и забудет. Пока Комиссар будет выяснять, не подменили-ли инопланетяне у него в карте один айтем на нулл.
Зато у Комиссара приложение не начнёт падать в продакшн с нуль пойнтер эксепшен когда какое-нибудь другое молодое дарование внезапно(tm) поменяет код по добавлению айтемов в эту корзину.
Хотя, конечно, мы ту обсуждаем сферического коня в вакууме. Без знаний как за кадром устроен этот cart из примера, что там с айтемами (как там например имплементирован метод equal() и т.п.) - все остальное гадание на кофейной гуще. Фреймворки тоже не боги писали, как мне помнится классный библиотечный binary search в Java как раз на 100500 классно гнал фуфло.
KinDzaDza wrote: 10 Oct 2018 16:50
Зато у Комиссара приложение не начнёт падать в продакшн с нуль пойнтер эксепшен когда какое-нибудь другое молодое дарование внезапно(tm) поменяет код по добавлению айтемов в эту корзину.
сюрпрайз: для этого придуманы не только аннотации типа @NonNull, которые решают проблему частично, но и йызыки тиипа Котлина, которые решают проблему полностью. И молодое дарование наверняка умеет этим пользоваться, а старперы будут и дальше надувать щеки "а вот если вдруг"
На всякий случай напомню, что идея Комми - проверять на нуль и кидать эксепшн. Не NPE, а другой. Т.е. по факту у неопытного писюка будет код такой, что нарушить null-safety будет невозможно, а у Комми - такой, что не падает со стыдным NPE, но падает с KommyVerifiedThatHereWeHaveANullPointerInCollectionAndYouAllSuckException
А вообще всех за пояс заткнет Кумар Дипшитович, который честно поймает null pointer и в обработчике сделает молчаливый возврат безо всякой диагностики. И подумает: "у меня ничего не падает, а вы поебитесь отлаживать".
KinDzaDza wrote: 10 Oct 2018 16:50
Зато у Комиссара приложение не начнёт падать в продакшн с нуль пойнтер эксепшен когда какое-нибудь другое молодое дарование внезапно(tm) поменяет код по добавлению айтемов в эту корзину.
сюрпрайз: для этого придуманы не только аннотации типа @NonNull, которые решают проблему частично, но и йызыки тиипа Котлина, которые решают проблему полностью. И молодое дарование наверняка умеет этим пользоваться, а старперы будут и дальше надувать щеки "а вот если вдруг"
На всякий случай напомню, что идея Комми - проверять на нуль и кидать эксепшн. Не NPE, а другой. Т.е. по факту у неопытного писюка будет код такой, что нарушить null-safety будет невозможно, а у Комми - такой, что не падает со стыдным NPE, но падает с KommyVerifiedThatHereWeHaveANullPointerInCollectionAndYouAllSuckException
Мои эксепшны выводятся на экран PM со словами "ЗА ВАМИ УЖЕ ВЫЕХАЛИ"
KinDzaDza wrote: 10 Oct 2018 16:50
Зато у Комиссара приложение не начнёт падать в продакшн с нуль пойнтер эксепшен когда какое-нибудь другое молодое дарование внезапно(tm) поменяет код по добавлению айтемов в эту корзину.
сюрпрайз: для этого придуманы не только аннотации типа @NonNull, которые решают проблему частично, но и йызыки тиипа Котлина, которые решают проблему полностью. И молодое дарование наверняка умеет этим пользоваться, а старперы будут и дальше надувать щеки "а вот если вдруг"
На всякий случай напомню, что идея Комми - проверять на нуль и кидать эксепшн. Не NPE, а другой. Т.е. по факту у неопытного писюка будет код такой, что нарушить null-safety будет невозможно, а у Комми - такой, что не падает со стыдным NPE, но падает с KommyVerifiedThatHereWeHaveANullPointerInCollectionAndYouAllSuckException
Мои эксепшны выводятся на экран PM со словами "ЗА ВАМИ УЖЕ ВЫЕХАЛИ"
Ага. А когда мой код не работает, фиксят компилятор. Продолжим?