Как стать автором
Обновить

Комментарии 26

Вы открываете форму, и она показывает разницу между объектами: какие поля добавились или удалились.

Прошло 10 лет, и количество полей возросло до десятков тысяч.

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

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


Это я говорю как человек, которому неоднократно предлагали зафигачить в UI табличку на миллион+ строк, и возражения "но никто никогда в жизни не прочитает миллион строк" поначалу даже слышать не хотели.

Большие формы - это было частью бизнес процессов, типичная вещь в той доменной области, где я тогда работал.

С точки зрения программирования, скорость работы с такими формами решалась виртуализацией. Но это не отменяет модели с кучей полей. Кнонечно, это не означает 10к+ полей в DTO, так как у нас были составные поля (например, в гриде каждая ячейка считалась отдельным полем, значит грид 10х10 = 100 полей).

Конечно, это не есть хорошо и с точки зрения UI/UX, с этим борятся другими методами, не связанными с алгоритмами.

НЛО прилетело и опубликовало эту надпись здесь

Как будто что-то хорошее.

Я может чего не понимаю, но почему девушка по тексту парень… «я рассказал», «когда уходил»

может быть потому, что это - интервью?

Первая — рабочее приложение принимало только 10 тысяч последовательностей, каждая не длиннее 10 символов

А это не было каким-нибудь ограничением лицензии?

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

И вы таким образом нарушили лицензионное соглашение? :)

Я не мог ничего нарушить, ведь я создал свое ПО со своим алгоритмом и приложение, которым пользовались до этого, даже в глаза не видел. Да и посчитайте сами, старое приложение работало минуту, а мое обрабатывало в 450 раз больше данных за 7 секунд - если бы старое и могло столько данных обработать, то по времени это было бы явно сильно долго.

Все в алгоритмах хорошо, за исключением того, что они нужны в 1% случаев. А в остальных 99% не нужны, а иногда и вредны (потому что увеличивают стоимость поддержки кода, а вот профит от них может и не приносить пользу для бизнеса).
Соответственно, современная мода требовать алгоритмы на собеседовании приводит к тому, что прокачивается эффективность этого 1% работы. Тогда как вместо этого могла прокачиваться эффективность остальных 99%. Т.е. бизнес просит сотрудников прокачать малонужные навыки, что, естественно, выдаст снижение эффективности бизнеса.

P.S. я не отношу к алгоритмам обычные ошибки в производительности из разряда «не надо делать запрос к базе в цикле. если есть пакет данных, то и обработать его хорошо бы пакетно».

Смотря что подразумевать под "алгоритмами". Знание алгоритмов и структур данных помогает не только писать какие то хитрые алгоритмы. Это также требуется при, например, выборе правильной структуры данных для работы. Или при разделении между алгоритмами и доменной логикой. Чтобы просто пройтись нужным способом по дереву, надо какое то минимальное знание алгоритмов. Да даже если вы проектируете систему (проектируете, не кодите), можно использовать анализ алгоритмов, чтобы примерно представлять возможности масштабирования системы.

Потому ваши 1% ну сильно приуменьшены. По моему опыту процент будет в десятки раз больше. Наверное вы имеете ввиду случаи, когда надо реально какой то свой алгоритм изобретать - это да, это редко.

По закону Парето алгоритмы полезны в 20% случаях.

И вы все правы ) - все зависит от того, в какой области работаете. Если вы мобильный разработчик в финтехе или разрабатываете какое-нибудь учётное по по типу 1с, то это 1%. А если вы бэкендщик, которому интересны алгоритмы, и выбираете себе соответствующие места работы, то там процент будет сильно выше.

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

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

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

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

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

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

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

Я очень часто слышу такое мнение и я пожалуй хотел бы высказать свои мысли на эту тему.

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

Просто лично я работал в крупных конторах с числом программистов более тысячи (пожалуйста, не воспринимайте как хвастовство, просто на мелких проектах мне скучно) и в этом сегменте всё несколько иначе: там приходится строить приложения может быть и не особо сложные, в том плане что это просто пачка мелких микросервисов, но из-за огромного числа этих маленьких микросервисов систему простой назвать язык не поворачивается. И в таких проектах, с командой по 50 человек и выше, вроде как на первый взгляд тоже не особо нужны алгоритмы... И я бы снова согласился что алгоритмы не нужны... Но есть одно "но": там сильно рулит сисдиз, вы должны понимать как строить сложные архитектуры из мелких кубиков, причём в этих кубиках всё настолько пропитано алгоритмами, что хорошо бы, чтобы алгоритмы уже спинным мозгом понимались, а не приходилось долго и мучительно вдумываться. Например, как работают разные виды кеширования. Или как устроены кластерные индексы в реляционных таблицах. А откроешь Клеппмана по высоконагруженным системам - там через страницу такое.

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

Поэтому знания алгоритмов и структур данных я воспринимаю именно как знание азбуки или таблицы умножения, как один из важных кирпичиков для более сложного знания. А потому - маст хэв.

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

Вот только алгоритмы надо знать, потому что иначе этот 1% становится нерешаемым. Программист просто даже не подумает, что вот тут можно применить алгоритм.
Или считается, что задача нерешаемая и приходится отказываться от какой-то фичи, или пишется тупое наивное решение, которое дико тормозит.


Тогда как вместо этого могла прокачиваться эффективность остальных 99%.

Чем знание алгоритмов может помешать программисту клепать формочки или перекладывать json-ы (из чего в основном и состоят остальные 99%) работы, я не представляю.

Знание алгоритмов и структур данных помогает не только писать какие то хитрые алгоритмы. Это также требуется при, например, выборе правильной структуры данных для работы. Или при разделении между алгоритмами и доменной логикой. Чтобы просто пройтись нужным способом по дереву, надо какое то минимальное знание алгоритмов.


При столь широкой трактовке под алгоритмы попадает почти все. Термин вообще ужасно «резиновый». Я под ними не подразумеваю базовые вещи, вроде обычного обхода дерева. Я к «алгоритмам» отношу очень специфичные знания вроде:
различия в деревьях (балансировка, красно-черное и т.д.)
различия в методах сортировки (вот эта вся тема про «давайте хеши разложим в корзины, а внутри каждой дерево).
(извиняюсь, веткой промахнулся. это ответ на habr.com/ru/company/southbridge/blog/655927/#comment_24172521 конечно же)

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

Про устройство хешсета\хешмапы я вообще молчу, это же основы. Как, например, можно понять зачем перегружать equals и hashcode - если не знаешь зачем этот hashcode - я таких проблем на stack overflow видел не один десяток.

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

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

Вот про это и есть курс. Там нет хитрых алгоритмов балансировки деревьев, но я поясняю, что это за зверь такой - двоичное дерево поиска и зачем его балансировать. Или например я покажываю самую простую реализацию хештаблицы и рассказываю, как качество хеш функции влияет на производительность и вообще корректность работы структуры данных. То есть примеры и теория максимально приближены к практике, но не перегружены деталями. Я не стал, например, рассказывать про Кнутта-Морриса-Пратта или Белмана-Форда (а вы как часто это используете?), но рассказал самые основы теории графов и самые популярные обходы (bfs\dfs) с конкретно практическим примером, который встречался мне именно на работе.

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

Вот такой получился курс, там нет никакого rocket science, но есть конкретные примеры из конкретно моей практики и теория привязана именно к ним.

С одной стороны кричат - преждевременная оптимизация это зло!

С другой - какие не оптимизированные алгоритмы вы используете!

Все верно, в программировнии должны быть компромиссы. То же самое про что угодно можно сказать: "с одной стороны - учите солиды\паттерны, с другой - hello, world: enterprise edition".

"Преждевременная оптимизация" — эта цитата была скорее про микрооптимизации. Типа использовать битовые трюки везде где можно, хранить несколько переменных в одном int-е для экономии памяти и всякая другая фигня. Выбор правильного алгоритма и структур данных должен происходить еще на этапе проектирования. Оно не может быть преждевременным.

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

Очередную узкоспецифичность возвели карго культ.

tym32167, как решили нерешаемую задачу? что использовали?

Зарегистрируйтесь на Хабре , чтобы оставить комментарий