Hidden text
Нужны
Предыстроия
Мне 21 год и я работаю программистом всего 4 года, за это время я побывал на 2-3 мелких проектах и 3-4 проектах крупных компаний, таких как: Luxoft (упокой его душу), Альфа, ОТП, ГПБ и др. Так же я часто прохожу собеседования и в другие компании, чтобы «держать себя в форме», собирать статистику и т. п. Прохожу собеседования, в том числе и в крупные финтехи и пока что не хочу туда идти. А почему, это тема для отдельной статьи.
В разговорах со своими коллегами я очень часто слышал фразу «алгоритмы программистам не нужны», «алгоритмы никогда не используются в работе» и т.п. Я не являюсь ярым приверженцем того, что алгоритмы нужно учить и использовать их повсеместно, но я понимаю, как они могут помочь мне в жизни программиста.
Знакомство с математикой
Ещё со школы мы учим математику, физику, биологию и другие б̶е̶с̶п̶о̶л̶е̶з̶н̶ы̶е, как нам кажется, бесполезные предметы и даже после школы не все понимают, для чего всё это было нужно. Как часто вы слышали фразу «мне математика в жизни не нужна, калькулятор всегда под рукой»? С одной стороны, всё верно, калькулятор всегда под рукой, любую формулу или теорему тоже можно найти за 2 минуты. Но как эти аргументы могут оспорить мнение, что все эти предметы просто меняют мышление. Как человек знает, что колесо проще катить, чем тащить булыжник, так и я знаю что бинарный поиск быстрее\лучше, чем линейный. Хотя ни разу ни разу не тащил булыжник, не катил колесо и не писал алгоритм бинарного поиска в рабочем коде. Все эти алгоритмы реализованы в каждой второй библиотеке, и писать самостоятельно это практически никогда не нужно. Но как я пойму, что его тут вообще можно применить? Как я пойму, что он тут улучшит работу?
Я могу не помнить, как этот алгоритм написан, где он реализуется и т.д, но я знаю, что могу вспомнить что это такое только посидев в интернете пару минут, я знаю, что такой алгоритм существует, что он применим в той или иной задаче. Но как бы я узнал эту информацию, если бы не зашел на LeetCode\CodeWars\Codeforces (нужное подчеркнуть) и не провел бы там хотя бы 20 минут своего времени, даже просто смотря на топики задач?
Алгоритм не нужно учить, его нужно реализовать самостоятельно. Написать (можно даже с гайдами), с дебагом попробовать что-нибудь посмотреть внутри, поменять что-нибудь и понять что именно сломалось. Любая информация запоминается в разы лучше, если ёе записать\нарисовать\реализовать. Так и с алгоритмами, не нужно заходить на математические форумы и прошерстывая сотни страниц запоминать какой-либо алгоритм. Достаточно всего лишь зайти на любой сайт с алгоритмическими задачками открыть уровень Easy и решить 2-3 задачи на тот или иной алгоритм. Тут не идёт речь про алгоритмы уровня корневой оптимизации, которая помимо того, что просто специфична, но и абсолютна не реализуема в 99% задач в программировании. Бинарный поиск, сортировки, жадные алгоритмы и т.п. - наши лучшие друзья. После их реализации в голове появятся трейдоффы многих из них. Жадный алгоритм не всегда точно находит ответ, для бинарного поиска нужен отсортированный список и т.д.
Наш мозг запомнит условия, в которых этот алгоритм был написан и в следующий раз на уровне ассоциаций подскажет решение для новой функции. А там уже скорее всего и встроенное решение можно найти.
Собеседования скатываются
Я очень часто прохожу собеседования и очень часто слышу вопрос про HashMap, про индексы в БД. Знаю как на них отвечают другие люди, и в большей части люди могут только пересказать выученное предложение с какого-нибудь сайта. Возможно такое влияние на статистику имеют выпускники IT курсов, но и прожжённые опытом программисты не всегда понимают каким образом бинарный поиск лучше линейного, или из-за какой структуры данных индекс вообще ускоряет работу. Они знают их сложность алгоритмов, знают, что алгоритм бинарного поиска применим на сортированном массиве (хотя это тоже не всегда), но не знают почему. И тогда становится непонятно, как такой работник сможет на глаз определить узкое место какого-нибудь процесса или хотя бы предложить использовать другой, более продуктивный вариант функции.
Тут опять может прозвучать аргумент «я же не реализую эти индексы, зачем мне знать какая там структура внутри? Мне сказали, что быстрее работает и это самое главное. А, как и почему это уже дело второстепенное». Всё верно, в современных реалиях программистам зачастую можно не знать как работает та или иная функция, но «экспертное» мнение обязательно должно быть в каждой команде. А что если такого человека нет у вас в команде? Тогда начинаются проблемы. Индексы вдруг начинают работать дольше потому, что никто не знает, что они замедляют операции вставки, поиск по списку начинает занимать секунды, если не десятки секунд и вся программа работает в разы медленнее только потому, что данных стало больше, а алгоритмы остались те же, т.к. никто не знает об существовании других или не знает куда их применить. Теперь ваш тестировщик вас постоянно пилит: «А почему теперь страница 2 минуты открывается?». Бесконечные созвоны, лживые оптимизации по типу «убрать лишний if из метода» и т. п. И все это продлится до того момента, как вас не уволят или не наймут человека с той самой «экспертизой». Так почему бы тогда не ждать человека, который вас может заменить, а самим стать человеком, который может заменить кого‑нибудь. Это так же может стать триггером для повышения зарплаты, так что никогда не поздно.
Это так же проблема компаний, которые нанимают людей. Взять человека, который знает, что зачастую HashSet работает быстрее, чем TreeSet одно дело, но взять человека, который знает почему HashSet работает быстрее, чем TreeSet дело абсолютно другое. Один из них знает накладные расходы данной структуры данных, и сможет понять, что именно в данном случае нужна одна или другая коллекция, а второй просто знает, что зачастую HashSet работает быстрее, чем TreeSet. Но кроме крупных финтехов никто не спрашивает людей о таком. Все хотят спросить на собеседовании «в ширь», чтобы человек мог сказать поверхностно, но побольше, а там уже разберется. Хотя хорошо углубившись только в одну тему можно понять насколько человек может разобраться и в других темах.
Заключение
В следующий раз, как я буду реализовывать очередную п̶е̶р̶е̶к̶л̶а̶д̶к̶у̶ ̶j̶s̶o̶n̶'̶о̶в бизнес-задачу, смогу подумать «а не могу ли я случайно улучшить этот процесс?»
Комментарии (66)
MountainGoat
04.04.2024 13:46+9У меня на пред-предыдущей работе человек, который имеет кандидата наук в вычислительной алгебре, и человек, который после чтения каждой строки из постгреса закрывал соединение и открывал снова, просто чтобы было удобно что весь код БД в одном месте - это один и тот же человек.
Математиков к коду вообще лучше не подпускать - с них сыпятся сферичские вакуумные кони.
Какая разница, быстрее там по алгоритму HashMap или TreeMap, если в вышем языке один из них, например, потокобезопасен а другой нет?
constXife
04.04.2024 13:46Всё зависит от уровня решаемых задач, как упоминали выше. Я вот, так уж вышло, обычно работал в мелких фирмах, где гораздо выгоднее было для проекта внедрить багтрекер, оптимизировать CI пайплайны, отладить общие процессы разработки, оптимизировать сущности в БД, замутить дистрибутед трейсинг, чтобы быстрее определять возможные проблемы в микросервисной инфраструктуре, изучить возможности k8s, чтобы добавить надежности/удобства в рамках развертывания веб-приложения, следить за поддерживаемостью кода, чтобы не офигевать через какое-то время от того, что мы там понаписали.
У меня никогда не было такой проблемы, чтобы мы упирались именно в незнание алгоритмов и не смогли бы локализовать это незнание и изучить при необходимости предметную область.
werevolff
04.04.2024 13:46Странно. Кубер и MSA актуальны на проектах с ощутимым набором данных: по нескольку тысяч строк в десятке таблиц, как минимум. Логика, которую нужно разбивать по микросервисам, поскольку только одна доменная область может иметь очень много кода, и обслуживать его в монолите - тот ещë мазохизм.
Однако, тенденция уже много лет остаëтся неизменной: стоимость ресурсов железа гораздо меньше стоимости часа программиста. И это - основная причина того, что в мелких проектах применяют зоопарк решений: кубер, MSA, кафка, и т.д.. И это - основная причина того, почему на собесе у человека могут не спрашивать про алгоритмы и структуры данных. Докупить ресурс в облаке или на сервере будет дешевле.
И, всë-таки, когда объëм данных превышает определëнную отметку, за которой время выполнения алгоритмов начинает расти (а это происходит в любом случае, если бизнес не закрывается раньше), компания, как-правило, заменяет своих специалистов на тех людей, кто может произвести оптимизацию. При этом, рост зарплаты на рынке для специалистов, которые не могут понять причины неэффективности алгоритмов, идëт медленнее инфляции. На коротком промежутке времени (года в 2 - 2,5) это не критично. Наверное, даже 5 лет не будут достаточно критичной величиной. Зарплата немного растëт при переходе в другую компанию, уровень жизни остаëтся +- прежним. Может, даже немного улучшается. А вот перспектива буста в 2 раза и более - уже сомнительная. Поскольку, тут уже на собесах спросят и про алгоритмы, и про блокировки в параллельных вычислениях, и про индексы в БД, и ещë может повезти попасть на архитектурную секцию с проработкой интересных паттернов взаимодействия различных сервисов и слоëв.
Интересное наблюдение: за 9 лет мой заработок вырос примерно в 6 раз. Уровень жизни вырос, но не скажу, что значительно. Но он вырос.
Так что, в краткосрочной перспективе алгоритмы, возможно, и не нужны. Но, если человек хочет достичь определëнных высот, они обязательны к изучению и пониманию. Как и математика, как и теория операционных систем, теория реляционных систем данных и т.д..
Proscrito
04.04.2024 13:46+1Задача провести оптимизацию сводится к нахождению узкого места и масштабированию оного, либо за счет более эффективного алгоритма, либо путем вычленения его в отдельный сервис и масштабированию его вертикально. Подобрать эффективный алгоритм сегодня может любой джун, который умеет задавать вопросы ИИ. Выделить функциональность в отдельный сервис тоже, хотя тут уже желателен опыт, будет заметная разница в скорости. Особенно если нужно организовать какую-то сагу или типа того.
Настоящая сложность современных задач программиста намного, намного больше давным-давно всем известных алгоритмов, по сути справочной информации. Никому не нужны живые справочники, особенно в современном мире ии.
kemenchik Автор
04.04.2024 13:46Да вы правы, справочная информация не нужна. Но как и описано в статье, работодатель в "идеальном мире" должен не спрашивать: "знаешь ли ты этот алгоритм?", а спрашивать: "а можно ли этот алгоритм применить вот в этой задаче". Тут уже половина начинает сыпаться, т.к. не могут применить справочную информацию к нестандартной ситуации
Proscrito
04.04.2024 13:46+7Работодатель не должен такого спрашивать, есть миллион и один куда более важный вопрос в современном мире программирования. Вопросы по непосредственно алгоритмам имеет смысл задавать только на крайне узкоспециализированные позиции. Например, разработчика компилятора, или движка субд. Это настолько ничтожный процент от современного айти, что как-то генерализировать важность знания алгоритмов не представляется возможным.
"Иделального мира" не существует, на то он и идеальный. Если 30 лет назад программистам особо нечего было знать, кроме алгоритмов, то сегодня одна позиция программиста отличается от другой, как профессия плотника, отличается от профессии бухгалтера. Как-то обобщить знания первых и вторых, чтобы нанять универсального работника - не представляется возможнымkemenchik Автор
04.04.2024 13:46Вопрос более обширный и слово "алгоритмы" выбрано как "один из". Работадатель должен спрашивать в глубь чего-либо. Да хоть структуры данных, хоть фреймворк. Даже про интерфейс Map можно говорить всёсобеседование. Основная реализация, потокобезопасноть, использование Map другими структурами и т.д. Это показывает насколько человек готов погружаться в то, чем он сейчас занимается, на сколько это ему интересно. Для работодателя - это, грубо говоря, ресурс, который он может с сотрудника получить. А обязан или не обязан это, конечно, дело каждого. Вопрос про сложности найма тоже достаточно обширный, данная статья, к сожалению, не раскрыла эту тему. Может в следующей напишу
Proscrito
04.04.2024 13:46+3Знание возможностей фреймворка, или технологии - это не про алгоритмы. Это знание, какие задачи можно решить при помощи того, или иного инструмента. К примеру, знание того, как реализовать систему авторизации и ролей на основании JWT токенов не подразумевает знание каких-либо алгоритмов. Или знание каких-то ОРМ систем, их достоинств и недостатков, способов оптимизации работы с базой данных. Или распределенного кэша. И тд и тп.
Да, если очень и очень "в общем" то все это можно назвать алгоритмами, но тогда теряется смысл статьи, потому что "алгоритмы" от "алгоритмов" могут отличаться, как сказки братьев Гримм от Бхагват-Гиты. Паттерн "сага" для микросервисной архитектуры - это алгоритм, или нет? В какой-то мере да. Об этом статья? Нет.
Статья об алгоритмах из задачек с литкода, что-то типа того. Которые ИИ щелкает как семечки, выдавая рабочее решение на любом языке за секунды, не уступая лучшим специалистам. Тогда как опыт работы с конкретными технологиями (то, что реально дает бизнес-велью, ускоряя получение результата), так просто не получить, даже с помощью ИИ. Сходу и не узнаешь что спрашивать, не понимая устройства приложений подобного типа и не зная способов решения определенного рода задач. Каждый подводный камень (а их в процессе решения реальной задачи вылезет тысяча и один) будет вызывать серьезную задержку и обширный инвестигейт, куча чтива, эксперименты. А у человека с нужным опытом и знаниями это время сокращается в разы. Он уже читал, сталкивался, знает, решал, наступал на грабли. Он куда полезнее. Знание реализации сортировки пузырьком, или эффективного обхода конем шахматной доски - не даст ничего. Это за 3 минуты можно узнать.
Spyman
04.04.2024 13:46С одной стороны я с вами согласен, с другой под конец статьи речь скатывается к пониманию принципа работы бинарного поиска и хешмапы а это уже элементарные вещи, и хороший программист должен уметь придумать такой алгоритм если не знает его. У людей которые этого не могут начинают встречаться методы с кубической а то и экспоненциальной сложностью там, где вполне можно было получить квадратичную или логарифмическую. Я такое видел и метод со сложностью по экспоненте может заставить тормозить самое современное железо на очень смешной задаче, но человек этого в момент написания не поймет т.к. оценивать сложность алгоритмов скорее всего не умеет (и так сказать насмотренности нет) а тестировать будет на небольшом наборе данных. И никакой ИИ который поможет потому, что чтобы он помог нужно осознать что проблема есть, а она либо проявит себя на ревью когда код написан либо в проде.
werevolff
04.04.2024 13:46+1Вы так много говорите про современный мир ИИ. Но, по сути, если в вашем сообщении заменить "ИИ" на "Google", то, Во-первых, смысл не изменится. А во-вторых, текст с Google был бы применим и 9 лет назад.
Так что, не знаю о каком "современном мире ии" вы говорите. По сравнению с 2015 годом у нас, по сути, поменялся только поисковый движок.
Proscrito
04.04.2024 13:46В чем-то вы правы. Вы даже можете заменить "гугл" на "справочник", мой посыл от этого не изменится по большому счету. Никогда и ни от кого не требуется знать справочную информацию и помнить всю теорию.
Дискуссия же о том, чем современный ИИ отличается от Гугла уже выходит за рамки обсуждения предмета статьи. Но я все же отвечу, раз вы подняли эту тему. По сравнению с 2015м годом у нас все поменялось радикальнейшим, катастрофическим образом, не будет большим преувеличением сказать, что мы ушли за горизонт событий с того времени.
Расскажу забавный случай. Когда был молод - увлекался математикой. Пока сверстники мечтали стать порноактерами и бандитами (не помню уже кем там обычно мечтают стать школьники), я всерьез хотел стать математиком. Выигрывал олимпиады по всем точным наукам, ботанил в общем. Конец 90х. Но неблагополучное детство и необходимость на что-то кушать привели меня в айти, где я практически сходу неплохо устроился в начале нулевых. Тогда еще у меня оставалась тяга к фундаментальным вещам, и я очень долгое время любил решать алгоритмические задачки. Однако т.к. математика программисту не нужна, я ее благополучно забыл со временем. Решать задачки забесплатно, с возрастом тоже перестал. Очень давно. Взрослая жизнь, дети, все такое. И вот вдруг, недавно, на собеседовании, мне дают задачку с литкода на бэктрекинг. Представляете? С ума сойти. Я думал, что рассказы о подобном на собеседованиях - сказки Венского леса. Лонг стори шорт: на втором мониторе скормил задачку ГПТ и он выдал готовое рабочее решение с пояснениями. Во-первых, мне лень тратить калории на собеседовании, во-вторых было просто любопытно выйдет или нет. Вышло. Гугл так не умеет. Гугл не позволяет половину кода писать кнопкой таб. Гугл не ответит развернуто на сложный вопрос.
Вот пример. "Вероятность успешного эксперимента определяется как частное количества успешных экспериментов к общему их количеству. Сколько экспериментов мне нужно провести, чтобы вычислить вероятность успешного с погрешностью ниже 5%?". Это интересная математическая проблема и если вы о ней знаете - замечательно. Я вот не знал, а мне понадобился ответ. Конечно, я мог бы найти ответ и через Гугл. Это заняло бы какое-то время, я долежен был бы вспомнить теорвер, почитать материал. ГПТ ответил точно, быстро и максимально развернуто, а главное - правильно. Он позволил мне одновременно и найти ответ за минуту, и освежить необходимые знания. Может у вас и не поменялось ничего с 2015го года. У меня поменялось точно.werevolff
04.04.2024 13:46В конце 90-х - нулевых годах Google был точно таким же "рывком". До него были каталоги сайтов. Однако, развитие копипастинга, как способа решения проблем в программировании, связано с наполнением баз StackOverflow и Habr. А как способа прохождения интервью - только с развитием схем удалённого трудоустройства. В 10-х годах, чтобы устроиться в Web-студию, приходилось писать код на листочке, а решение можно было спросить, максимум, у голубя, сидящего за окном.
С одной стороны, может показаться, что поменялось многое: можно устраиваться на работу по скайпу, можно давать примеры нейросети, и она будет находить правильные ответы...
А с другой стороны, ничего не поменялось: программирование как было научной деятельностью, так и осталось. Раньше были Web-мастера, которые собирали сайты мышкой, сейчас есть кодеры, которые работают методом копипасты. Но они не осуществляют научную деятельность в рамках своей работы. Они собирают простые средства автоматизации.
Есть человек, который жарит котлеты во "Вкусно и Точка", есть человек, который готовит блюда в мишленовском ресторане. Они решают похожие задачи, но не эквивалентные. Хотя, казалось бы, техпроцесс приготовления бургеров шагнул далеко вперёд, чтобы заменить собой традиционную готовку вычурных блюд. И, всё-таки, приготовление бургеров - это достаточно автоматизированная деятельность. Она хорошо оптимизируется, и она оплачивается гораздо скромнее, чем деятельность шеф-повара в ресторане. Исчез ли спрос на шеф-поваров? Нет.
Бургер - это идеальная метафора для интеграции. Повар жарит котлету, готовит соус, режет салат, помидоры и сыр. Потом, собирает всё в единую конструкцию и отдаёт клиенту. По сути, деятельность похожа на то, что делают кодеры, пользующиеся StackOverflow или ChatGPT. Получить готовый кусочек кода, интегрировать в готовый продукт, продать клиенту.
Осталось найти ответ на простой вопрос: является ли должность повара во "Вкусно и Точка" пределом ожиданий выпускника кулинарных техникумов и академий? И является ли копипастинг посредством любых поисковых систем или лингвистических моделей пределом ожиданий человека, который идёт писать программы?
Proscrito
04.04.2024 13:46Программирование как не было никогда научной деятельностью, так и не стало ею. И никогда не станет. У науки есть вполне внятное и четкое определение, под которое деятельность программистов не попадала и не попадает. Наука - это деятельность, направленная на познание. Программирование - это ремесло. Как и медицина, например.
ИИ - это инструмент. Когда-то писали программы с помощью перфокарт, потом появились удобные редакторы, в современных ИДЕ давно есть системы интеллисенса, подсказок и дописок позволяют писать еще быстрее. ИИ - следующий шаг, он не просто дописывает список параметров, или имя методов, он выполняет еще больше рутинной работы. А большая часть работы программиста - рутина. Самое первое, что должен сделать любой программист получая задачу - поиск готового решения. ИИ ускоряет этот поиск в разы, более того, он может выдать адаптированное решение типовой задачи сам, без всякого поиска. Не пользоваться этим, только потому что ты и сам способен написать это, пусть медленнее? Или потому что можно пользоваться гуглом? А смысл? Наоборот, я лучше уделю больше внимания архитектуре разного уровня, займусь наиболее интересной творческой частью. Чем я собственно, как техлид и занимаюсь.
Шеф-повар, если он готовит еду, а не просто командует другими поварами, точно так же пользуется передовыми инструментами и технологиями своей профессии. И если ему нужно взбить майонез, то он будет его взбивать также точно, как и поваренок-подмастерье. В целом же аналогии обычно только уводят в сторону. С таким же успехом можно сравнить эффективность туда рикши и таксиста, здесь будет очевидным преимущество использования технологических средств. Люди давным-давно создают технические средства, чтобы расширить свои возможности. Почему-то когда дело касалось только физических возможностей, ни у кого антагонизма не возникало и в голову не приходило, заявить, что реактивный двигатель - это вдруг не большой скачок вперед. А когда появился инструмент, действительно расширяющий возможности интеллектуальные, тут же появился снобизм, дескать надо пользоваться только своим биологическим интеллектом и привлекать искусственный для решения каких бы то ни было задач - моветон и вообще означает какую-то ущербность.
Те, кто водит автомобиль, не разучатся ходить. Но всегда будут быстрее тех, кто полагается только на свои две ноги. ИИ - это гиганский скачок вперед, и он действительно все поменял радикальнейшим образом. Изменилось все. Кто этого не поймет, в ближайшей перспективе может оказаться в неприятной ситуации.werevolff
04.04.2024 13:46А вот ГОСТ 19781—90 определяет программирование, как научную деятельность. Кому или чему мне верить? Стандарту, или случайному человеку в Интернете?
Proscrito
04.04.2024 13:46+1Толковому словарю. Нау́ка (праслав. *na- + *učiti – учить, выкнуть) — деятельность, направленная на выработку и систематизацию объективных знаний о действительности.
В госте определено программирование, как "научная и практическая деятельность по созданию программ". Это в прямом смысле означает, что если вы занимаетесь компьютерными науками, то согласно этому госту вашу деятельность можно отнести к программированию. А не что любое программирование - это научная деятельность. Семантика. Но оставя за кадром для кого и зачем этот гост написан, а также что делать, если я живу в США и у меня подобных гостов нет, остается простой вопрос: вы занимаетесь компьютерными науками? Если занимаетесь, тогда вам безусловно понадобится математика и знания алгоритмов. Большинство, все же, под программированием понимают практическую деятельность, а не научную.
Даже если вы занимаетесь именно наукой, все равно неясен снобизм в отношении ИИ. Ученые сейчас используют ИИ очень широко. Уже были открыты новые лекарства с помощью ИИ (например абауцин - новый антибиотик), ИИ расшифровывает древние тексты и даже целые языки (например аккадский), а снимки с Уэбба сейчас тоже анализируются в первую очередь ИИ. В компьютерных науках наверняка тоже можно найти ему применение. Хотя вам виднее, я-то научной деятельностью не занимаюсь.werevolff
04.04.2024 13:46Вы не ответили на вопрос: кому или чему мне верить? Стандарту, или случайному человеку в Интернете?
Proscrito
04.04.2024 13:46+2Я что, предлагал кому-то верить? К чему эта демагогия? Что не так с гостом я ответил достаточно подробно. Нечего ответить, не хотите отвечать, не устраивает аргументация - не отвечайте. Эта дискуссия ни к чему не обязывает ни вас, ни меня.
Proscrito
04.04.2024 13:46+2Вы свели дискуссию к ложной дихотомии вопросом "кому верить из двух". Ложная дихотомия - прием демагогии. Не единственный в ваших постах, и я могу легко это показать. В моих постах демагогии нет, вы что-то напутали.
werevolff
04.04.2024 13:46А вы, вместо того, чтобы признать факт, стали заниматься откровенным враньëм, пытаясь нивелировать значение официального документа. Не вижу смысла разговаривать с манипулятором и лжецом.
Proscrito
04.04.2024 13:46+2А это аргументум ад хоминем. Очередной прием демагогии.
Демагог бездоказательно обозвал меня лжецом, ну надо же какая неприятность...
flx0
04.04.2024 13:46Наука - это все что использует научный метод. Программист по десять раз на дню выдвигает гипотезу что его код работает, после чего пытается ее опровергнуть при помощи тестов. Так что программирование - это чистейшая наука.
Proscrito
04.04.2024 13:46В таком случае я недавно занимался наукой, когда блины пек. Эмпирические гипотезы пытался подтверждать экспериментально. Как ученый ученому: все прошло хорошо.
Я дал определение слову наука. Это определение общепринято. В такой же, либо схожей форме, присутствует во всех словарях на любых языках. Система знаний об устройстве мира и деятельность, направленная на их приобретение.
Программирование же это деятельность по созданию и модификации программного обеспечения. Какой бы ни была наукоемкой отрасль, будь-то медицина, или инженерия - это не наука. Если цель деятельности состит не в объяснении картины мира - это не наука. Любое объяснение не годится, конечно же. Религия вроде тоже что-то объяснить пытается, но она тоже не наука. Как бы некоторым не хотелось. Теологам, например... Действительно, необходимо использовать научный метод. Но метод называется научным, потому что сформирован в рамках науки, а не наука называется наукой из-за метода.
kemenchik Автор
04.04.2024 13:46Мы стараемся проводить рефакторинг кода каждые полгода, и всегда видим случайно или специально допущенные "алгоритмические" ошибки. Тут квадрат лишний, тут вообще всю коллекцию перебираем со вложенными сущностями (декартово произведение). И статья про то, что мы могли их и не увидеть. И в силу юного возраста, я просто надеюсь, что глаз начнет сразу замечать такие вещи
werevolff
04.04.2024 13:46+2В этом прелесть работы человека: мы не машины - мы ошибаемся. Дело не в знании или незнании алгоритма. Как ни странно, мы можем не увидеть такие ошибки не потому, что не знаем теорию алгоритмов, а потому, что банально устали в тот день, когда это писалось.
Однако, я согласен с тезисами статьи. За 12 лет работы в IT, 9 из которых - в области коммерческой разработки, я пришëл к тому, что знания нужны. Знания различных теорий, связанных с IT, знание математики. Потому, что с этими знаниями уровень разработки совсем другой. В нëм минимизирован элемент случайности. Ты смотришь на коллег, которые не обладают базой, и видишь, что они не выбирают правильные пути решения задачи. В то время, как у коллег с базой выбор подхода идентичен тому, что выбрал бы ты. Это радует: так, хотя бы, можно понять, что не сошëл с ума.
Потому, что вокруг тебя целая куча программистов, которые сошли. Один носится с какой-нибудь дикой теорией, что код надо писать только так, как он учит. При этом, никто до сих пор не может начать писать так, как пишет он, поскольку он выбирает стиль и алгоритмы рандомно. Другой кричит, что ему, как сеньор-джуну математика не нужна, и он готов писать статьи на эту тему. И вообще, он много лет работает на одном месте, и работодатель им доволен.
Нет, всë-таки, базу нужно знать. Хотя бы, ради возможности общаться на одном уровне с нормальными инженерами, которые пишут одинаково лаконичный и качественный код. Потому, что в наш век Искусственного Интеллекта, очень трудно найти интеллект. Он заявлен, но его нет. Ни искусственного, ни естественного. Есть только море дезинформации и продвинутые боты типа Chat GPT или Copilot. В этот век не трудно закинуть в сеть какой-нибудь фэйковый материал про алгоритмы, а потом наблюдать, как у этого материала появляются адепты, и как работодатели включают в собесы пункты вопросов, чтобы отсеивать этих адептов.
И, я думаю, всë к этому идëт: скоро многие идеи мира IT превратятся в религиозные догмы. У Лю Цисина псевдонаучная организация "Грани Науки" продвинула идею того, что "физики не существует". Современные авторы хабра пишут, что "математика не нужна". То, о чëм вы говорите - алгоритмы, математика, различные теории, которые входят в минимум для айтишника - они нужны не для того, чтобы вы не совершали ошибок в коде. Вы их, так или иначе, будете совершать. Всë это нужно потому, что программирование - это научный процесс, и все эти базовые вещи - это база научного процесса. Они нужны затем, чтобы вы не занимались лженаукой. Чтобы шли только по пути доказанных теорем. А это, в свою очередь, нужно для того, чтобы ваша деятельность имела положительный результат, была продуктивной и снижала процент случайностей.
michael_v89
04.04.2024 13:46и все эти базовые вещи - это база научного процесса
Базовые означает, что без них задачу сделать нельзя, или это будет сложнее. Приведите пожалуйста конкретные примеры того, что вы называете базой, и задач, которые она помогла вам решить. А то может быть так, что все под базой понимают разное, что-то действительно нужно знать, а что-то нет.
werevolff
04.04.2024 13:46+1Вот вы пристали со своими примерами. Ещë с вашего поста о том, что математика не нужна. Раздел математики, определяющий большинство процессов в современном IT, называется "Дискретная математика". Код, который вы пишете на языке программирования, подчиняется правилам логических высказываний.
Пример здесь - любой программный код. Ваши инструкции либо имеют логическое обоснование, либо не имеют.
Графы имеют непосредственное отношение к БД, поскольку ими реализована часть индексов. Вот, например, какой индекс вы будете использовать при поиске по дате в таблице последовательного лога событий? Почему? Каким индексом можно реализовать полнотекстовый поиск, не прибегая к использованию сторонних поисковых движков? Почему индексация в эластике проходит долго и как это исправить? Всë это - логические шарады, которые, так или иначе, решаются дискретной математикой. Вы можете еë не знать, но вы еë применяете каждый день. Просто, если вы еë знаете, то вы применяете еë эффективнее.
Сложность алгоритма - это, по сути, нахождение в уме производной и процесс дифференцирования функции, поскольку именно производная является мерилом любых изменений, а дифференциал показывает как меняется функция при прогнозируемом изменении аргумента (да поправят меня математики). Вы можете не знать всего этого, но вы используете это каждый день, и если вы знаете базу, то вы используете это эффективнее.
Например, можете ли вы доказать, что логарифмическая сложность алгоритма лучше, чем квадратичная? Насколько лучше? Допустим, вы видите, что при постоянном приращении числа заказов в бд на 100 в день, через месяц ваш алгоритм, использующий эти записи для отчëта, будет обрабатывать их в сумме на 10 секунд дольше. Откуда вы это видите? Как вы это посчитали? Ну, хорошо, посчитали и посчитали. Теперь, вы идëте к заказчику и говорите: "Насяльника, алгоритм совсем медленный будет, да! Согласуй доработку на 40 часов"! А он вам говорит: "Обоснуйте-ка, Мишель89, оплату вам 40 часов". И, опять, чтобы обосновать выгоду оплаты 40 часов для снижения сложности алгоритма, вам понадобится математика.
michael_v89
04.04.2024 13:46+3Вот вы пристали со своими примерами.
Естественно, потому что много разговоров о том, что эти знания много где нужны, но примеры почему-то привести никто не может.
Вот для нахождения производной таблица умножения это база, без умножения правильно ее посчитать нельзя, потому что степень переменной умножается на коэффициент.Просто, если вы еë знаете, то вы применяете еë эффективнее.
Очередное утверждение без доказательств, в котором непонятно, что вы подразумеваете, для чего я и прошу примеры.
Ещë с вашего поста о том, что математика не нужна
Например, можете ли вы доказать, что логарифмическая сложность алгоритма лучше, чем квадратичная?В моем посте я написал про математику алгоритмов отдельно, где сказал, что она нужна на базовом уровне.
Пример здесь - любой программный код. Ваши инструкции либо имеют логическое обоснование, либо не имеют.
Подмена понятий. Логическое обоснование состоит из фактов и логики, но не любые факты и логика связаны с алгоритмами. Если брать любой программный код, то ваше утверждение неверно, в написании большинства кода дискретная математика не помогает.
Графы имеют непосредственное отношение к БД, поскольку ими реализована часть индексов.
Подмена понятий. Мы говорим не о том, что используется в БД, а о том, что об этом нужно знать программисту. По вашей логике получается, что квантовая физика имеет непосредственное отношение к чайнику, поскольку чайник реализован элементарными частицами, а значит надо знать квантовую физику, чтобы вскипятить чайник.
Вот, например, какой индекс вы будете использовать при поиске по дате в таблице последовательного лога событий? Почему? Каким индексом можно реализовать полнотекстовый поиск, не прибегая к использованию сторонних поисковых движков?
Это всё практические знания инструментов, а не знания алгоритмов. Да, внутри принципы одинаковые, но это не даст вам знания о том, как сделать поиск по тексту в конкретной СУБД. Вы откроете документацию и прочитаете, какие индексы там есть. А то может для полнотекстового поиска там вообще ничего нет.
Например, можете ли вы доказать, что логарифмическая сложность алгоритма лучше, чем квадратичная?
Нет, и именно доказательство этого для ответов на дальнейшие вопросы не нужно. Достаточно знать, что она лучше.
Допустим, вы видите, что при постоянном приращении числа заказов в бд на 100 в день, через месяц ваш алгоритм, использующий эти записи для отчëта, будет обрабатывать их в сумме на 10 секунд дольше.
На практике такого никогда не бывает. Заказы из БД выбираются запросом, и по ним идет одинарный цикл с линейной сложностью. Либо делается группировка средствами БД, и нужно знать средства оптимизации самой БД. Вот поэтому и нужны практические примеры, а не гипотетические.
чтобы обосновать выгоду оплаты 40 часов для снижения сложности алгоритма, вам понадобится математика.
На практике начальник скорее всего скажет "Есть более важные задачи, давай через месяц посмотрим, если будет тормозить, оптимизируем".
gurovofficial
04.04.2024 13:46+4Привет. Больше 15 лет назад, я так же рассуждал. Зачем мне математика? Мне казалось, что я разбирался лучше преподавателей в некоторых областях. В итоге я бросил учебу. А сейчас, решая действительно сложные задачи - я чувствую, что мне просто не хватает знаний. И очень хочу снова пойти учиться, но появляются новые и новые проблемы. Вывод очевидный: если есть возможность учиться - надо учиться и учиться, чтобы потом разбираться во всем и лучше всех.
michael_v89
04.04.2024 13:46+2Расскажите пожалуйста, в какой области и какие знания математики вам нужны.
DenSigma
04.04.2024 13:46"Математику нужно учить уже только потому, что она ум в порядок приводит". Программист, имеющий вышку с хорошей математической базой, просто инстинктивно, на глубинном уровне, проверяет свои выражения на правильность. Упрощает выражения ВЕЗДЕ и ВСЕГДА, добиваясь абсолютной ясности. Математика - это упрощение выражений. Математика - это вывод сути из горы формул и выражений. Программист с вышкой добивается "математической" правильности программы. Без костылей, без велосипедов. Работающей всегда, при любых входных данных (естественно, с защитой от неправильных данных).
Программист без вышки полагает, что высшая доблесть программиста - наворотить гору кода за день.
Программист с вышкой полагает, что высшая доблесть программиста - написать минимум кода.
В жизни не нужны знания математики. В жизни нужны УМЕНИЯ математики.
Homyakin
04.04.2024 13:46Сейчас делаю игру в качестве пет-проекта. Для расчёта баланса нужно самостоятельно прописывать формулы, использовать статистику, аналитику.
Не согласен с тем, что углублённые знания математики нужны всем и каждому, но лично я немного жалею, что в некоторых местах халявил в универе.
michael_v89
04.04.2024 13:46Я баланс в играх не делал, но кажется для статистики и аналитики не такие уж сложные формулы. В крайнем случае можно неделю посидеть порешать примеры на интегралы и среднеквадратичные отклонения. О том и речь, что обычно открываешь документацию и изучаешь, исключений не так уж много. Сложность алгоритмов одно из них, но и тут достаточно иметь представление об основных концепциях, на что обратить внимание и т.д., а не знать наизусть сложность всех методов сортировки в лучшем, худшем и среднем случаях.
tsukasa_mixer
04.04.2024 13:46+2Ну в противовес, программист должен понимать принципы работы алгоритмов и методы работы со стандартными структурами, т.к. это база.
Вообще программиста я считаю определяет понимание работы механизмов, чтобы для него было как можно меньше черных ящиков в разработке (магии).
Иначе порой получаем абсолютно бредовые вещи на выходе.
А инструменты и языки за десятилетие меняются порой кардинально 2-3 раза и знания по ним становятся попросту не нужны.
А вот знание под капотом как все работает, пригодятся регулярно.
Batalmv
04.04.2024 13:46+3Знать или не знать алгоритмы - вопрос не в знании. Знание в чистом виде в современном мире не стоит почти ничего, так как почти любая инфа лежит под ногами. Ну реально.
Вопрос в том, сможет ли человек:
1) Понять вообще, что он применяет. Это важно когда случается "ничего не рабоатет", а ответ часто где-то "внутри" фреймворка. Либо решение "валит" прод под нагрузкой либо в кластере. Понятно, долгое время можно "говнокодить", если задача вообще не критична по нефункциональным требованиям - это будет сходить с рук. Вывод: важно знать, как реализовывать ннефункциональные требования, так как их выполнение отделяет хороший код от плохого.
2) Понять, что вообще надо принять во внимание. Огромное число девелоперов реально вообще не осознают, что их код может быть запущен в более чем одном экземпляре. У них то на машине все ок, так как он один. Если вы в теме, что надо, к примеру, маскировать sensitive данные во время сохранения - то хотя бы поинтересуетесь, надо ли это делать вам в коде, ти если да - какой алгоритм взять/посоветовать
Т.е. обобщая, важно, сколько разработчки знает "половинок вопроса", чтобы задать их себе перед началом работы над таской (в хорошем вопросе содержится половина ответа). Знать же в конкретный момент вторую половинку ответа - это просто вопрос опыта / умения гуглить либо спросить ChatGPT
Grigory_Otrepyev
04.04.2024 13:46В разговорах со своими коллегами я очень часто слышал фразу «алгоритмы программистам не нужны», «алгоритмы никогда не используются в работе» и т. п.
аж ЖЫР потек
tema4p
04.04.2024 13:46Проходят десятилетия но все еще остаются люди что рассуждают нужны ли алгоритмы и нужна ли математика. Если бы вы посмотрели на название "Алгоритмы и СТРУКТУРЫ ДАННЫХ" то заметили бы, что там еще есть какие-то "структуры данных". Я работаю уже более 15 лет и до сих пор вижу даже среди больших ентерпрайз проектов код который вместо использования пресловутой структуры Map использует например поиск на каждый элемент, например добавить к 1000 записям поле из другого массива в 1000. Т.е. с Map это делается за один проход по обеим массивам в 2000 чтений. Без Map это может занять 1000*1000 чтений. Благодаря таким "решениям" тормозит все вокруг, все ваши телефоны, сайты, сервера. Никто не требует знания всех алгоритмов сортировок. Но знание основных структур данных, применимость и оценивать сложность алгоритмов по памяти/скорости должен любой инженер. Ребята, да простому инженеру хватит 2-3 недели на освоение базы по алгоритмам что бы проходить собесы и не писать тормозную дичь.
Asker1987
04.04.2024 13:46Книга Кормена, конечно, топчик. Но вот с чем не соглашусь - 2-3 недель не хватит. Алгоритмы являются непреодолимым барьером практических для всех программистов на всех собесах. А что такое вдруг?! Ведь каждый знает, что это этап собеса, но вот ненавидят этот этап и все тут! Прочитать пару сотен страниц кормена - мелочь какая по сравнению с книгами по всем фреймворкам собеса. Всего лишь 5% от общего объёма требуемых знаний. Тогда почему не уделять эти 2-3 недели? А все просто. 2-3 недели недостаточно. Любой фреймворк усваивается со скоростью чтения или просмотра Ютуб. А алгоритмы - не справочная информация, необходимо в голове формировать сложные связи и абстракции. Проще говоря, думать надо, а это уже злит испытуемого.
Asker1987
04.04.2024 13:46+2Ты ходишь по очень тонкому льду)) тебя тупо захейтят, заодно и меня. В 2024м алгоритмы уже давно под запретом. Тенденция продолжалась десяток лет и достигла апогея. Вообще надо скрывать свои знания, чтобы тебя не спалили и не накинулись токсики. Как вообще алгоритм может пригодиться, если о его существовании даже не знают?! Более того, зачастую фреймворковые программисты даже не способны идентифицировать проблему, чтобы начать хотя бы гуглить "как решить ХХХ".
ЗЫ провел опрос, алгоритмы ни разу не пригодились ни сантехнику, ни электрику, ни уборщику.
ЗЫ ЗЫ сейчас понапишут якобы частные истории, доказывающие, что алгоритмы зло, а ещё хуже люди, знающие их)))
werevolff
04.04.2024 13:46Да, да, да. Выше уже один написал, что делал баланс в игре - математика и алгоритмы ему не пригодились. Если бы кто-то сказал, что реализовывал программу для выполнения преобразований Фурье, они бы ответили, что писали такой код, но математика им для этого не потребовалась.
michael_v89
04.04.2024 13:46Слово "баланс" выше встречается в 2 комментариях, ни в одном из них не написано "делал, но математика и алгоритмы не пригодились".
Про преобразования Фурье хороший пример. Если мне нужно будет сделать преобразование Фурье, я почитаю документацию 2-3 дня, поищу примеры кода, потом напишу сам или выберу библиотеку, которая это делает. Так же, как сделал бы это при изучении в университете. Само преобразование Фурье мне заранее знать не нужно.
В очередной раз указываю на то, что вы неправильно понимаете, что люди подразумевают под словами "надо знать математику и алгоритмы". Как и автор статьи. Грубо говоря, под этим подразумевается, что вы можете описать, как делается преобразование Фурье, определенная сортировка или обход графа сразу на собеседовании.werevolff
04.04.2024 13:46+1
michael_v89
04.04.2024 13:46+2Выглядит так, как будто вы считаете, что в университете есть какой-то магический источник знаний, и люди там изучают материал как-то по-другому) Что ж, не буду разрушать ваши фантазии.
Pardych
04.04.2024 13:46+1Алгоритмы, структуры и паттерны проектирования + хорошая насмотренность в рамках рабочего и смежных стеков нужны и важны, в первую очередь, для того чтобы инженер имел инструментальную базу. Оная база позволяет опытному инженеру предложить не одно, а несколько решений задачи по разному весу в треугольнике "деньги-время-качество", отсеяв из них то не что подходит под область определения данной задачи.
Давать литкод-задачки, спрашивать основы фреймворка/языка, проверять количество запомненных дезигн-шаблонов на собесе бесполезно с уровня миддл+, это я вам как человек проводивший много собесов могу сказать. Все это хорошо для недавнего выпускника вуза у которого нет реального опыта, или для чуваков у которых он сильно однообразен. В первую голову мы матчим человека с проектом куда он пойдет и пытаемся определить справится ли он, во вторую насколько мы с ним сработаемся.
"Не терять форму" проходя собесы хорошо для собесов и вообще никак для работы. Встречал экстремально анекдотичных персонажей обоих сторон - и тех кто которые отшлифовали собес-скиллы и абсолютно непригодны для работы и тех кто вносят серьезный вклад в сложные проекты, но на собесах никакие. Сам в некоторые периоды жизни бывал во второй роли, фиксится это заплывом по этим самым собесам после любого перерыва.
Ну и - собесы не скатились. Собеседуют люди, люди все разные, опыт в найме это отдельный скилл. Чекнуть именно этот скилл - практически невозможно. Задачи набрать разработчиков умеющих подбирать других разработчиков никогда не стоит. В итоге техсобесы в подавляющем большинстве случаев проводят буквально дилетанты.
Вот вам и вся история с наймом и алгоритмами. Это не параллельные вселенные, но пересекаются они единожды.
michael_v89
04.04.2024 13:46+2Но как я пойму, что его тут вообще можно применить? Как я пойму, что он тут улучшит работу?
Потому что вы знаете, что есть такой бинарный поиск, и он лучше перебора.
но и прожжённые опытом программисты не всегда понимают каким образом бинарный поиск лучше линейного, или из-за какой структуры данных индекс вообще ускоряет работу.
Потому что они знают, что "могут вспомнить что это такое посидев в интернете пару минут".
как такой работник сможет предложить использовать другой, более продуктивный вариант функции
Никак, берем и замеряем все варианты. Это нужно делать в любом случае.
Цикл по двумерному массиву можно реализовать 2 способами, сначала по x или сначала по y, их логическая сложность одинаковая, но один вариант немного медленнее из-за кеша в процессоре.а второй просто знает, что зачастую HashSet работает быстрее, чем TreeSet
Вот дело как раз в том, что в большинстве случаев это ни на что не влияет. Если кому-то нужно выбрать, он прочитает в интернете описания для конкретной версии конкретного языка, а то вдруг там баг в какой-то версии, или они для многопоточности не подходят.
Индексы вдруг начинают работать дольше потому, что никто не знает, что они замедляют операции вставки
Это как раз практические знания возможностей инструментов, а не знание алгоритмов.
я знаю, что такой алгоритм существует, что он применим в той или иной задаче
Это не то, что подразумевается в словах "знать алгоритмы". Знание алгоритмов как раз этому противопоставляется. Считается, что недостаточно знать только то, что вы написали, об этом и есть весь спор.
MinimumLaw
04.04.2024 13:46+1В разговорах со своими коллегами я очень часто слышал фразу «алгоритмы программистам не нужны», «алгоритмы никогда не используются в работе» и т.п.
Т.е. коллеги решают поставленные им вопросы, тем же методом, что и обезьяны пишут "войну и мир"? Вообще, пока решение любой задачи алгоритмизируется. И без этого никак. Ну, может быть, вышеназванным методом... Но это маловероятно...
Другое дело, что для решения конкретной задачи не нужно все множество алгоритмов, а самые востребованные алгоритмы давно существуют в виде библиотек.
Отсюда главный вопрос - а что спрашивает данная статья? Должен ли программист знать ВСЕ МНОЖЕСТВО АЛГОРИТМОВ, созданных до него и им самим? Очевидно нет. В отдельных случаях надо знать ГДЕ посмотреть тот или иной алгоритм. Должен ли программист уметь составлять и реализовывать алгоритмы? Очевидно да, ибо это и есть его основная работа. Должен ли программист использовать алгоритмы из библиотек, вместо создания своих собственных - это реально вопрос. Но он точно не имеет однозначного ответа, и действительно тут все зависит только от задачи. В общем случае, если МОЖНО использовать готовое, то НУЖНО использовать готовое. В остальных случаях ПРИДЕТСЯ делать самому.
ermadmi78
04.04.2024 13:46+1Алгоритмы для программиста - это примерно как огнетушитель в бардачке машины. Обычно огнетушитель не нужен от слова совсем. Но вот когда не дай Бог пожар - без огнетушителя вообще никак.
Dominux
04.04.2024 13:46Алгоритмы по сути исходят из концепции того, что если человек умеет решать алгоритмы, то он имеет неплохую мат базу и способен решать другие задачи
Однако под этим лозунгом на собесах слишком их пропушивают уж слишком много. По итогу мы имеем олимпиадников, которые знают только яп, и они решают такие задачи, и реального разраба, имеющего за плечами годы прохождения и огня, и воды, но не способного решить и medium задачи с литкода. Кого вы возьмёте на работу?
n0ne
04.04.2024 13:46Я бы взял второго, честно.
Но он не пройдёт даже первую техничку. Опыт создателя homebrew - типичный пример.
Selenix
04.04.2024 13:46Весь смысл - понимать почему какой-то алгоритм быстрее другого, чтобы в какой-то неординарной ситуации применить другой алгоритм вместо стандартного. А чтобы это знать нужно знать сам алгоритм.
n0ne
04.04.2024 13:46Думаю, начинать надо с принципа работы полевого транзистора. Это же основа всего, на чем, в основном, крутятся ваши/наши программы!
Проблема в том, что задачи на алгоритмы решают одну и только одну задачу: отсеять тех, кто не потратил 100-500 часов на эти алгоритмы. В 99,9% случаев фронтендеру не понадобятся графовые алгоритмы, а бэкендеру не придется merge sort реализовывать.
Andrey_Solomatin
04.04.2024 13:46Думаю, начинать надо с принципа работы полевого транзистора. Это же основа всего, на чем, в основном, крутятся ваши/наши программы!
Я тут общался с коллегами которые занимаются железом узнал много нового как измерять потребление ресурсов на многоядерном процессоре. Между транзисторами и программой тоже много чего происходит.Проблема в том, что задачи на алгоритмы решают одну и только одну задачу: отсеять тех, кто не потратил 100-500 часов на эти алгоритмы.
Они находят людей которые увлечены или готовы тратить время для достижения цели. Когда у тебя очередь из кандидатов такой отбор вполне неплох.
headliner1985
04.04.2024 13:46Для 99% это даже вредно, важнее изучать клиникод и практики промышленного программирования. На поделки алгоритмистов и олимпиадников можно посмотреть на примере любой sdk от Яндекса, и понять насколько это зло упарываться в алгоритмы. Можно просто сравнить их поделки с любой sdk от международного вендора, где люди в первую очередь думают сначала головой и то как люди будут использовать их продукт, а во вторую очередь уже про алгоритмы и оптимизации.
1dmitry
04.04.2024 13:46Технические вопросы на собесах позволяют оценить уровень технической интеллигентности собеседуемого.
LuckyTrends
04.04.2024 13:46На мой взгляд знание алгоритмов и непосредственно сам опыт написание программ, это все таки несколько разные вещи, которые развиваются параллельно друг другу. Главное, чтобы одно другому не мешало, а то может возникнуть ситуация, когда какой-нибудь олимпиадник с кучей золотых медалей, который знает все самые сложные алгоритмы и высшую математику с трудом может написать программу сложнее чем Hello world:)
nikolz
Есть разный уровень решения задач. Если задача сводится к применению уже известных алгоритмов в виде готовых библиотек, то внутренности алгоритмов не обязательно знать.
Но если Вы решаете неформализованную задачу, то ее решение начинается с разработки алгоритма , а в более сложных случаях еще и с выбора методов решения.
Например, Вам надо разработать программу управления экскаватором в реальном масштабе времени при ограниченном объеме памяти управляющего микроконтроллера.
Сразу начнете писать программу?
Или начнете разрабатывать алгоритм?
Andrey_Solomatin
Если вам нужно хранить уникальные неповторяющиеся значения и доступ к ним осуществляется только итерацией по коллекции, то какую страндартную структуру вы выберете?
nikolz
Вы по теме статьи спрашиваете?
Структуру чего Вы хотите выбрать и из какого стандарта?
Proscrito
Сферическую в вакууме, как и сам вопрос.
В реальной жизни этот вопрос обычно идет последним, имеет околонулевое значение и над ним никто реально не задумывается, выбирая автоматом. Первыми же идут такие вопросы: как хранить коллекцию? Как выбирать коллекцию из хранилища? Кэшировать, или не кэшировать коллекцию? Если да, то этот кэш надо пошарить между разными инстансами, или нет? Как сериализовать и передавать коллекцию? Как обновлять коллекцию? И тд, еще может быть 100500 реальных вопросов, после которых окажется, что выигрыш каких-то наносекунд от использования конкретной структуры намного меньше на 8 порядков меньше, чем среднее время отклика. А еще потом окажется, что из этой же коллекции удобно достать пару элементов по условию, но т.к. в ней все равно не больше 30 элементов, то... А о чем был вопрос?
Andrey_Solomatin
Я не очень верю, что человек который не представляет как базовые коллекции устроенны внутри и как работают алгоритмы оптимально ответит на все эти вопросы.
Да можно заучить основные операции с коллекцией, но всегда есть нюансы.
Можно данные в HashSet со сложностью O(n) вставлять. Но это редкость.
Чаще я видел вставку в начало ArrayList.
Proscrito
Человек, который вообще не представляет, как устроены базовые коллекции, скорее всего вообще не программист.
Но вы подменили вопрос. Не представлять, как устроены коллекции - это одно, а создавать в 99% случаев List даже не задумываясь, потому что это экономит время разработки и не влияет никаким значительным образом на результат - это другое. Наверное статья не очень хорошо очерчивает предметную область, потому что похоже каждый спорит о своем.
Спорное решение - тратить время на изучение способов обхода графа, или там бинарного дерева (которые ты учил когда-то в вузе, или не в вузе, но забыл за ненадобностью за 20 лет разработки) в ущерб времени на изучение Mass Transit или Wolverine, сложность работы с которыми точно не в алгоритмах, а знание тонкостей и деталей требуется здесь и сейчас, т.к. непосредственно и очень сильно влияет на результат и сроки.
Современное приложение представляет из себя чудовищный зоопарк технологий и фреймворков, и знание того, как с этим зоопарком работать, что из этого зоопарка можно или нужно поменять, как заставить его работать друг с другом, и работать эффективно - это основная задача и сложность. При этом все это требует знать об алгоритмах лишь то, что они существуют в принципе. И да, само-собой, необходимо иметь даже не базовые, а глубокие знания как все устроено под капотом. И не только (и не столько) коллекции. В том числе и для того, чтобы определять, на что сейчас стоит тратить время и усилия, а на что нет - как на выбор коллекции тут, или там.
Pardych
решение неформализованной задачи начинается с допроса с пристрастием всех к ней причастных и никак иначе