Программирование, т. 8

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

^

^

ты расскажи это челику который у нас написал сортировку, которая выполнялась 2с (там дохуя данных) на реальном проекте

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

с очевидной оптимизацией это превратилось в 50мс

То есть значит втираешь мне о крутых требованиях и йоба задачах, но при этом такой слоупочный говнокод пропустили на код ревью? Не видишь тут проблемы? :)

ты переводишь тему

да, кто-то на код ревью не досмотрел, но это не отменяет того, что у челика нет ни малейшего представления о том, за какое время выполнится его код

@sonac биг дата инженером работаешь?

типа того, но пока не особо биг

ты переводишь тему

да, кто-то на код ревью не досмотрел, но это не отменяет того, что у челика нет ни малейшего представления о том, за какое время выполнится его код

А в реальности это проблема непонимания количества/типа данных и отсутствие банального профайлинга (может у него никаких тестовых данных не было и он знать не знал что там будет вселенский пиздец). Ибо если бы данных было нихуя (и была бы уверенность в этом), то скорее всего его говнокод был бы даже лучше читаем (чисто теоретически). Даже вы, будучи мамкиными гениями, проебали это на кодревью (в чем я не удивлен) и спалили лишь когда все стало медленным, после чего примитивный профайлинг указал вам на ботлнек, который уже в свою очередь было крайне легко изучить и залатать, а потом задним числом отыгрывать умников, втирая всем как вы бы с самого начала написали бы все пиздос как правильно. Ну и если в команде имеется код ревью, то все баги и проблемы автоматически становятся заслугой ВСЕЙ КОМАНДЫ. Чем раньше ты это поймешь, тем быстрее пойдет прогресс. А то задним числом рассказывать истории все умеют, о том как бы они с самого начала писали бы идеальные и самые быстрые в мире имплементации алгоритмов для решения всех возможныз задач. А на самом деле, даже в самых крутых проектах, мега крутые йоба-прогеры вначале говнокодят по быстрому, а потом уже по мере развития проекта латают дары (тут офк речь не идет о фундаментальных проблемах в архитектере и какой-нибудь критически важной разработке, где невозможны всякие хотфиксы).

https://tech.onliner.by/2018/08/28/microsoft-114

@@suez zemlyapuhom

Это же боян, разве нет? Airbnb или кто-то делал уже подобное. Там один хуй статичная хуйня всегда генерится, но для простеньких лендосов покатит.

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

 

ты переводишь тему

да, кто-то на код ревью не досмотрел, но это не отменяет того, что у челика нет ни малейшего представления о том, за какое время выполнится его код

А в реальности это проблема непонимания количества/типа данных и отсутствие банального профайлинга (может у него никаких тестовых данных не было и он знать не знал что там будет вселенский пиздец). Ибо если бы данных было нихуя (и была бы уверенность в этом), то скорее всего его говнокод был бы даже лучше читаем (чисто теоретически). Даже вы, будучи мамкиными гениями, проебали это на кодревью (в чем я не удивлен) и спалили лишь когда все стало медленным, после чего примитивный профайлинг указал вам на ботлнек, который уже в свою очередь было крайне легко изучить и залатать, а потом задним числом отыгрывать умников, втирая всем как вы бы с самого начала написали бы все пиздос как правильно. Ну и если в команде имеется код ревью, то все баги и проблемы автоматически становятся заслугой ВСЕЙ КОМАНДЫ. Чем раньше ты это поймешь, тем быстрее пойдет прогресс. А то задним числом рассказывать истории все умеют, о том как бы они с самого начала писали бы идеальные и самые быстрые в мире имплементации алгоритмов для решения всех возможныз задач. А на самом деле, даже в самых крутых проектах, мега крутые йоба-прогеры вначале говнокодят по быстрому, а потом уже по мере развития проекта латают дары (тут офк речь не идет о фундаментальных проблемах в архитектере и какой-нибудь критически важной разработке, где невозможны всякие хотфиксы).

 

ну да офк я согласен, нужен профайлинг етц 

я просто утверждаю, что у человека, который занимается программированием, должно быть хоть какое-то представление о сложности алгоритмов (хотя бы на уровне отличить O(n) от О(n^2))

или ты считаешь, что чувака с нулём знаний можно брать на работу, мол "на ревью увидим, что он не знает, что такое функция - объясним" (утрирую офк)

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

 

 

ты переводишь тему

да, кто-то на код ревью не досмотрел, но это не отменяет того, что у челика нет ни малейшего представления о том, за какое время выполнится его код

А в реальности это проблема непонимания количества/типа данных и отсутствие банального профайлинга (может у него никаких тестовых данных не было и он знать не знал что там будет вселенский пиздец). Ибо если бы данных было нихуя (и была бы уверенность в этом), то скорее всего его говнокод был бы даже лучше читаем (чисто теоретически). Даже вы, будучи мамкиными гениями, проебали это на кодревью (в чем я не удивлен) и спалили лишь когда все стало медленным, после чего примитивный профайлинг указал вам на ботлнек, который уже в свою очередь было крайне легко изучить и залатать, а потом задним числом отыгрывать умников, втирая всем как вы бы с самого начала написали бы все пиздос как правильно. Ну и если в команде имеется код ревью, то все баги и проблемы автоматически становятся заслугой ВСЕЙ КОМАНДЫ. Чем раньше ты это поймешь, тем быстрее пойдет прогресс. А то задним числом рассказывать истории все умеют, о том как бы они с самого начала писали бы идеальные и самые быстрые в мире имплементации алгоритмов для решения всех возможныз задач. А на самом деле, даже в самых крутых проектах, мега крутые йоба-прогеры вначале говнокодят по быстрому, а потом уже по мере развития проекта латают дары (тут офк речь не идет о фундаментальных проблемах в архитектере и какой-нибудь критически важной разработке, где невозможны всякие хотфиксы).

 

ну да офк я согласен, нужен профайлинг етц 

я просто утверждаю, что у человека, который занимается программированием, должно быть хоть какое-то представление о сложности алгоритмов (хотя бы на уровне отличить O(n) от О(n^2))

или ты считаешь, что чувака с нулём знаний можно брать на работу, мол "на ревью увидим, что он не знает, что такое функция - объясним" (утрирую офк)

 

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

 

 

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

 

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

 

 

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

 

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

 

Вот нанимаешь ты на галеры чела и задаешь ему ахуенные вопросы про сложность алгоритма сортировки в жс. И похуй овтечает он правильно или нет, он ничего с этим связанного не будет делать ДОХУЯ времени. А к тому моменту, когда он доростет до задачи где такое возможно понадобится, у него уйдет крайне мало времени на то чтобы быстро все отпрафайлить, изучить проблемные места, нагуглить чо там по разным алгоритмам для определенных проблем и как все это дело решить. У нас вот на сервисе с чартами дохуища данных прогоняется, в репорте грузится по 10-50 чартов, с большим набором данных (десятки датасорсов с периодом времени в год+) там процессинг данных на каждый чарт может занимать 10-40+ секунд. Вот начались проблемы, сели все профайлить, нашли хуйню, переписали часть на рамду, часть на собственные хуйни (все скурпулезно тестировали через jsperf каждый день) и все стало пиздос как быстро. Если бы кто-то в самом начале задавал бы вопросы про то, что смогли бы так сделать, то ответ скорее всего был бы отрицательным, тупо из-за непонимания предметной области и реальных объемов данных и как вся эта хуйня выглядит. Так что хватит уже блядь жить в каком-то мире, где абсолютно все при приёме на работу должны знать все алгоритмы, зачитывать Clean Code стихами и качественно сосать хуи заказчиков на галерах.

 

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

хз может ты и прав и личные качества намного важнее знаний

я всё-таки думаю, что чувак, который устраивается программистом, должен уже обладать какими-то базовыми знаниями (например умение отличать n от n^2)

сортировки дефолтный вопрос потому что это самые проситые и банальные алгоритмы где можно жонглировать сложностью n2/nlogn и жонглировать в пределах одного класса

и типа иедя в том что сортировки только даун не осилит

если человек их не осилил, значит он даун. если он их не знает т.к. не учил, значит он скорее всего не имеет понятия что из себя эти вещи вообще представляют

и если по какой-то причине к кандидату есть требование по минимуму чето отдуплять в алгоритмах и структурах данных, то человек который хавает на сортировках скорее всего похавает на всём остальном тоже и он тебе не нужен

все эти рассказы что это гуглится за 5 минут это конечно охуенно, ну вот и загугли перед интервью раз это так просто. если ты не в гугл собеседуешься то тебя же не будут спрашивать хардкор, деревья там бинарные инвертировать или вставки/удаления в RB деревья, а всего-лишь ебучие примитивные сортировки

Ну даун и даун, зачастую это никак не помешает его работе и лутанью бабосов.  А ведь бывает что всякие мего мозги, знают кучу алгоритмов и способов оптимизации, имеют 10+ лет опыта всяких с++  с# и лутают до 1к$, зато не дауны  

Я хуй знает, как вы не можете понять, что далеко не везде нужно знать ебучие сортировки. Кстати меня ни на одном собесе про них не спрашивали, из таких похожих ебанутых вопросов, как-то просили написать на листочке метод который выводит числа фибоначчи.

 

ты переводишь тему

да, кто-то на код ревью не досмотрел, но это не отменяет того, что у челика нет ни малейшего представления о том, за какое время выполнится его код

А в реальности это проблема непонимания количества/типа данных и отсутствие банального профайлинга (может у него никаких тестовых данных не было и он знать не знал что там будет вселенский пиздец). Ибо если бы данных было нихуя (и была бы уверенность в этом), то скорее всего его говнокод был бы даже лучше читаем (чисто теоретически). Даже вы, будучи мамкиными гениями, проебали это на кодревью (в чем я не удивлен) и спалили лишь когда все стало медленным, после чего примитивный профайлинг указал вам на ботлнек, который уже в свою очередь было крайне легко изучить и залатать, а потом задним числом отыгрывать умников, втирая всем как вы бы с самого начала написали бы все пиздос как правильно. Ну и если в команде имеется код ревью, то все баги и проблемы автоматически становятся заслугой ВСЕЙ КОМАНДЫ. Чем раньше ты это поймешь, тем быстрее пойдет прогресс. А то задним числом рассказывать истории все умеют, о том как бы они с самого начала писали бы идеальные и самые быстрые в мире имплементации алгоритмов для решения всех возможныз задач. А на самом деле, даже в самых крутых проектах, мега крутые йоба-прогеры вначале говнокодят по быстрому, а потом уже по мере развития проекта латают дары (тут офк речь не идет о фундаментальных проблемах в архитектере и какой-нибудь критически важной разработке, где невозможны всякие хотфиксы).

 

често большинству людям наверное похуй на знание алгоритмов, сложностей алгоритмов и тд

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

Большинство вопросов и задачек как раз задают ради отсеивания дебилов.

У того чела написал алгоритм который выполняется 2 сек не из-за того что он сложности алгоритмов не знал, а потому что он дебил ебаный

 

@sonac биг дата инженером работаешь?

 

типа того, но пока не особо биг

 

а в снг тем же занимался?

Фронтендеру не нужно знание онотации

Фронтендеру не нужно знание онотации

ему даже не обязательно знать как включается комп или ноут 

Самое смешное что это правда

PS: "ты не можешь в мавен проекте ссылаться на классы из папки target" схуяли? это все в одном джарнике лежит и потом будет одним класслоадером загружаться, так что проблем нет

я там проебался в одном месте с класс пасом 

пизда вы тут развели зха сортировки

я в целом согласен с суезом

что ну вот наъуй не надо

к тому же крутить 100 элементов и крутить датасет из 100000000 элементов немного разные вещи 

и во втором случае collection.sort() может принести пихздец и оверхед по времени

когда например проще взять я хз квиксорт и написать его для твоих данных

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

банально могу сразху понять будет тут о(н2) или о(нлогн) к примеру или где вместо о(н2) можно за о(н)