55+ в ИТ

[Мальчик-Одуванчик]

Положим, обойти дерево — это обычный санити чек. Он может быть несколько оскорбительным, но сделать такую задачу должен быть в состоянии любой погромист, даже если он за 20 лет работы ни разу с деревьями не работал.

Да ну. Полно уже формоклепателей которые сталкивались с подобным может быть только в вузе.
Хотя не удивлюсь, если большая часть формоклепателей и в вузе не училась.

[alex_127]

Вроде линейный самый быстрый на небольшом количестве. А потом выбор между тернарным с префетчем или чего. Совсем недавно доклад слушал. Попробую найти где.

[alex_127]

Нашёл. http://www.vldb.org/pvldb/vol11/p1550-schulz.pdf

[АццкоМото]

Я не понял, там похоже ошибка в логике.
Должно быть
boolean isItemInCart(Item item) {
for (int i=0; i<cart.size(); i++) {
if (cart.getItem(i).getId() == item.getId() {
return true;
}
}
return false;
}

Да, return false не на месте. Издержки написания спросоня и без ide

Но смысл, надеюсь, понятен.

а как надо?

ну там HashMap например. всякие RxJava делают то же самое куда элегантнее или там java streams. два последних подхода могут быть спорными, но тупой перебор да еще итакой многословный...

[АццкоМото]

Вообще КМК, возвращаясь к обходу деревьев, проблема совсем в другом. Знать структуры данных и базовые алгоритмы - недостаточно. Нужно их применять правильно и предсказуемо. Вот у нас есть чел старенький, думаю, лет 60. Он бодряк ого-го и код, вполне рабочий, пишет просто на ходу стирая шины. Побольше чем я раза в 2-3. Но если нужно проверить, условно, есть ли айтем в корзине, то код будет примерно такой:

Code: Select all

boolean isItemInCart(Item item) {
   for (int i=0; i<cart.size(); i++) {
   	if (cart.getItem(i).getId() == item.getId() {
   		return true;
   	}
   	return false;
   }
}

И, сцукко, это попаболь. Он обойдет дерево на интервью, расскажет про кучу алгориитмов, про какие-нибудь серо-буро-зеленые деревья. А вот в продакшн будет срать вот это УГ.

Как такое проверить на интервью? Я пока не знаю.

Я не знаю что делать с 60 летним программистом который воспроизводит такие баги.
Но приведенный тобою пример это типичные ошибки молодняка и даже претендующих на сениоров.
Отловить их на код ревью практически не возможно.

Мой ответ это юниттесты. Да это не дает даже 90% защиты от дурака. Но хотябы вынуждает его думать хоть немного и самому ковырятся почему его код не работает.
Не без доли хвастовства хочу отметить что мои проекты довольно стабильны на продакшн, что даже отмечено руководством, но весь секрет в моих тест сценариях.
Я не жалею времени на создание под-задач и расписывание юниттест сценарии под них. И пока я не увижу что мои сценарии покрыты я даже не пытаюсь понять что происходит в алгоритме.

но я только рад, благодаря вот таким "специалистам" нанимают меня контролировать конвейер и как я считаю даже переплачивают по рынку.

Ну, тут конфьюжн. То, что return false; не на месте - это мой факап, не того чувака. Еще раз: код он пишет вполне рабочий, багов производит не больше других.

Речь шла про использование тупого перебора в цикле, ровно как делали при Иване Грозном

[adda_]

ну там HashMap например. всякие RxJava делают то же самое куда элегантнее или там java streams. два последних подхода могут быть спорными, но тупой перебор да еще итакой многословный...

Извините, но код который вы привели не говорит, что для хранения данных в корзине использовалось что либо наподобии хеш таблиц или любого рода упорядоченные списки. Я лично решил, что это обычный не упорядоченый список в котором лежат объекты. Кстати для хранения небольшого количества данных (несколько десятков) - а в обычной корзине покупателя их обычно бывает всего несколько штук, вряд ли имеет место использовать что либо другое. Так что обычный линейный перебор - оптимальное решение. ИМХО.

[alex_127]

Дык науки говорит что все зависит от размера карта! Без этого знания как решить...

[alexan1]

Вообще КМК, возвращаясь к обходу деревьев, проблема совсем в другом. Знать структуры данных и базовые алгоритмы - недостаточно. Нужно их применять правильно и предсказуемо. Вот у нас есть чел старенький, думаю, лет 60. Он бодряк ого-го и код, вполне рабочий, пишет просто на ходу стирая шины. Побольше чем я раза в 2-3. Но если нужно проверить, условно, есть ли айтем в корзине, то код будет примерно такой:

Code: Select all

boolean isItemInCart(Item item) {
   for (int i=0; i<cart.size(); i++) {
   	if (cart.getItem(i).getId() == item.getId() {
   		return true;
   	}
   	return false;
   }
}

И, сцукко, это попаболь. Он обойдет дерево на интервью, расскажет про кучу алгориитмов, про какие-нибудь серо-буро-зеленые деревья. А вот в продакшн будет срать вот это УГ.

Как такое проверить на интервью? Я пока не знаю.

Я не знаю что делать с 60 летним программистом который воспроизводит такие баги.
Но приведенный тобою пример это типичные ошибки молодняка и даже претендующих на сениоров.
Отловить их на код ревью практически не возможно.

Мой ответ это юниттесты. Да это не дает даже 90% защиты от дурака. Но хотябы вынуждает его думать хоть немного и самому ковырятся почему его код не работает.
Не без доли хвастовства хочу отметить что мои проекты довольно стабильны на продакшн, что даже отмечено руководством, но весь секрет в моих тест сценариях.
Я не жалею времени на создание под-задач и расписывание юниттест сценарии под них. И пока я не увижу что мои сценарии покрыты я даже не пытаюсь понять что происходит в алгоритме.

но я только рад, благодаря вот таким "специалистам" нанимают меня контролировать конвейер и как я считаю даже переплачивают по рынку.

Ну, тут конфьюжн. То, что return false; не на месте - это мой факап, не того чувака. Еще раз: код он пишет вполне рабочий, багов производит не больше других.

Речь шла про использование тупого перебора в цикле, ровно как делали при Иване Грозном

а ламбду лучше?

хотелось бы увидеть правильны код

[rorp]

Он бодряк ого-го и код, вполне рабочий, пишет просто на ходу стирая шины. Побольше чем я раза в 2-3. Но если нужно проверить, условно, есть ли айтем в корзине, то код будет примерно такой:

Code: Select all

поскипано

Вот поэтому он и пишет побольше чем ты раза в 2-3.

[valchkou]

Вообще КМК, возвращаясь к обходу деревьев, проблема совсем в другом. Знать структуры данных и базовые алгоритмы - недостаточно. Нужно их применять правильно и предсказуемо. Вот у нас есть чел старенький, думаю, лет 60. Он бодряк ого-го и код, вполне рабочий, пишет просто на ходу стирая шины. Побольше чем я раза в 2-3. Но если нужно проверить, условно, есть ли айтем в корзине, то код будет примерно такой:

Code: Select all

boolean isItemInCart(Item item) {
   for (int i=0; i<cart.size(); i++) {
   	if (cart.getItem(i).getId() == item.getId() {
   		return true;
   	}
   	return false;
   }
}

И, сцукко, это попаболь. Он обойдет дерево на интервью, расскажет про кучу алгориитмов, про какие-нибудь серо-буро-зеленые деревья. А вот в продакшн будет срать вот это УГ.

Как такое проверить на интервью? Я пока не знаю.

Я не знаю что делать с 60 летним программистом который воспроизводит такие баги.
Но приведенный тобою пример это типичные ошибки молодняка и даже претендующих на сениоров.
Отловить их на код ревью практически не возможно.

Мой ответ это юниттесты. Да это не дает даже 90% защиты от дурака. Но хотябы вынуждает его думать хоть немного и самому ковырятся почему его код не работает.
Не без доли хвастовства хочу отметить что мои проекты довольно стабильны на продакшн, что даже отмечено руководством, но весь секрет в моих тест сценариях.
Я не жалею времени на создание под-задач и расписывание юниттест сценарии под них. И пока я не увижу что мои сценарии покрыты я даже не пытаюсь понять что происходит в алгоритме.

но я только рад, благодаря вот таким "специалистам" нанимают меня контролировать конвейер и как я считаю даже переплачивают по рынку.

Ну, тут конфьюжн. То, что return false; не на месте - это мой факап, не того чувака. Еще раз: код он пишет вполне рабочий, багов производит не больше других.

Речь шла про использование тупого перебора в цикле, ровно как делали при Иване Грозном

а ламбду лучше?

хотелось бы увидеть правильны код

Code: Select all

	
	boolean isItemInCart(Item item) {
	    return cart.getItems().contains(item);
	}

[Мальчик-Одуванчик]

cart.getItems() - переливаем из пустого в порожнее?
Сборщик мусора все стерпит.

[valchkou]

cart.getItems() - переливаем из пустого в порожнее?
Сборщик мусора все стерпит.

п-ть не мешки ворочать, предложите ваше решение

[АццкоМото]

Code: Select all

	
	boolean isItemInCart(Item item) {
	    return cart.getItems().contains(item);
	}

Ну вот да, хотя бы как-то так. Даже полученное с сервера в виде массива сохранить во что-то отличное от массива/ArrayList почему-то большинству в голову не приходит

Хотя на самом деле куда интереснее, когда нужно, например, посчитать общую стоимость айтемов в карте в предположении, что их может быть чуть больше 100500 миллионов. Тоже вроде бы не бином ньютона, а мало кто напишет эффективно. ИЧСХ даже тривиальное решение типа "а зачем считать при необходимости, можно же счетчик менять, когда добавляем/удаляем" тоже мало кто даст

И это очень грустно

[АццкоМото]

cart.getItems() - переливаем из пустого в порожнее?
Сборщик мусора все стерпит.

а в чем проблема-то?

[Мальчик-Одуванчик]

cart.getItems() - переливаем из пустого в порожнее?
Сборщик мусора все стерпит.

п-ть не мешки ворочать, предложите ваше решение

Нахрена на форуме ворочать мешки - я сюда исключительно потрындеть прихожу.
Если cart - контейнер, то воспользовался алгоритмом find, определив оператор равенства для item, если нет - то задал бы для него итераторы.
Если совсем лень - то тупо заменил простой цикл на его range-base форму типа: for(auto item_ : cart) ....

[Мальчик-Одуванчик]

cart.getItems() - переливаем из пустого в порожнее?
Сборщик мусора все стерпит.

а в чем проблема-то?

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

[Мальчик-Одуванчик]

Code: Select all

	
	boolean isItemInCart(Item item) {
	    return cart.getItems().contains(item);
	}

Ну вот да, хотя бы как-то так. Даже полученное с сервера в виде массива сохранить во что-то отличное от массива/ArrayList почему-то большинству в голову не приходит

Хотя на самом деле куда интереснее, когда нужно, например, посчитать общую стоимость айтемов в карте в предположении, что их может быть чуть больше 100500 миллионов.

Ну да, а потом какой-нибудь умник ради одноразовой операции преобразует массив в неупорядоченную таблицу якобы для ускорения поиска.

[АццкоМото]

cart.getItems() - переливаем из пустого в порожнее?
Сборщик мусора все стерпит.

а в чем проблема-то?

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

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

[АццкоМото]

Code: Select all

	
	boolean isItemInCart(Item item) {
	    return cart.getItems().contains(item);
	}

Ну вот да, хотя бы как-то так. Даже полученное с сервера в виде массива сохранить во что-то отличное от массива/ArrayList почему-то большинству в голову не приходит

Хотя на самом деле куда интереснее, когда нужно, например, посчитать общую стоимость айтемов в карте в предположении, что их может быть чуть больше 100500 миллионов.

Ну да, а потом какой-нибудь умник ради одноразовой операции преобразует массив в неупорядоченную таблицу якобы для ускорения поиска.

В общем случае не вижу ничего предосудительного.

[Мальчик-Одуванчик]

ИЧСХ даже тривиальное решение типа "а зачем считать при необходимости, можно же счетчик менять, когда добавляем/удаляем" тоже мало кто даст

Что налагает более жесткие требования устойчивости к исключениям для методов корзины.
Ведь так легко сделать данные несогласовынными если исключение вылетело между операцией изменения корзины и обновлением счетчика.

[Мальчик-Одуванчик]

getItems() же возвращает ссылку на коллекцию.

Тут я честно не понял. Разве getItems() не создает эту саму коллекцию, то есть новую структуру данных, отличающуюся от cart?

[valchkou]

Хотя на самом деле куда интереснее, когда нужно, например, посчитать общую стоимость айтемов в карте в предположении, что их может быть чуть больше 100500 миллионов. Тоже вроде бы не бином ньютона, а мало кто напишет эффективно.

согласен что интереснее, но не согласен что не бином.
добавим сюда вполне ожидаемые требования по high availability, scalability, latency и задача сразу превращается в нетривиальный проект.

[Мальчик-Одуванчик]

Code: Select all

	
	boolean isItemInCart(Item item) {
	    return cart.getItems().contains(item);
	}

Ну вот да, хотя бы как-то так. Даже полученное с сервера в виде массива сохранить во что-то отличное от массива/ArrayList почему-то большинству в голову не приходит

Хотя на самом деле куда интереснее, когда нужно, например, посчитать общую стоимость айтемов в карте в предположении, что их может быть чуть больше 100500 миллионов.

Ну да, а потом какой-нибудь умник ради одноразовой операции преобразует массив в неупорядоченную таблицу якобы для ускорения поиска.

В общем случае не вижу ничего предосудительного.

В случае если результат этого преобразования больше нигде не используется, то накладные расходы на создание новой одноразовой структуры данных чаще всего окажутся больше тупого линейного поиска, что и будет типичным переливанием из пустого в порожнее.
В этом действительно нет ничего предосудительного, сборщик мусора и не такое стерпит.

[valchkou]

Code: Select all

	
	boolean isItemInCart(Item item) {
	    return cart.getItems().contains(item);
	}

Ну вот да, хотя бы как-то так. Даже полученное с сервера в виде массива сохранить во что-то отличное от массива/ArrayList почему-то большинству в голову не приходит

Хотя на самом деле куда интереснее, когда нужно, например, посчитать общую стоимость айтемов в карте в предположении, что их может быть чуть больше 100500 миллионов.

Ну да, а потом какой-нибудь умник ради одноразовой операции преобразует массив в неупорядоченную таблицу якобы для ускорения поиска.

В общем случае не вижу ничего предосудительного.

В случае если результат этого преобразования больше нигде не используется, то накладные расходы на создание новой структуры данных чаще всего окажутся больше тупого линейного поиска, что и будет типичным переливанием из пустого в порожнее.

мы видим задачу по разному, в данном примере я предположил что
cart.getItems() не создает никаких коллекций, а попросту возвращает референс на коллекцию спрятанную внутри объекта cart.
причем имплементация коллекции может быть как массивом так и hash based structure.
но нам по барабану потому как они все имплементируют метод contains().

с другой стороны такой подход не надежен, потому как можно подменить содержимое cart не используя никаких add or set методов.
или даже словить concurrent ex если допустить что один поток пишет а другой ищет

[Komissar]

народ, неужели сборщики мусора по-прежнему куются вручную?!