А нужно ли знать программисту алгоритмы?

    Не встречали еще разработчика, который вместо стандартной в скриптовом языке функции деления строки по регулярке — пишет C-подобный код с конечным автоматом, который вводит неокрепшие умы в трепет?

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

    О этом много говорят: на конференциях, на бигдатовских тусовках, на собеседованиях… Но на практике, при решении конкретных бизнес-задач в жесткие сроки, может оказаться — что твои академические знания как-то странным образом «не особо требуются» и горячий кэш мозга для эффективной работы содержит лишь названия библиотек в boost, java или консольных команд unix, пути к файлам логов и незарастаемую тропинку к бите в подсобке.



    Да, я помню вычислительную машину Тьюринга, теорию регулярных выражений на основе конечных автоматов и не только, ragel — а на практике нужно знать, что есть grep, egrep, awk, немного perl и синтаксис регулярок на уровне популярных кейсов.

    Да, очень прикольно удаляются узлы в RB-дереве, а очередь с приоритетами иногда даже может быть полезна… но я пишу старый добрый кулинарный SQL-запрос и использую индексы.

    Конечно, понятно «в целом» для чего нужна операционная система — но в данный момент меня интересует ключ, выводящий подробности о принадлежности потоков в команде ps.

    Полезно знать о поиске в глубину из теории графов и многочисленные NP-hard задачки и подвохи для неопытных, которыми можно пугать внуков — но гораздо чаще требуется понимать на пальцах рук и ног, как работает IP, из чего состоит пакет и почему тормозит этот скрипт, который написал коварно улыбающийся разработчик, попивающий горячий кофе.

    Да, конечно, процессор выполняет жестко (не совсем, но нередко в CISC и RISC) запаянные в него команды и понимает небольшой, ограниченный, примитивный набор команд — но, коллеги, без strace часто не понятно, что дает дыхание жизни этому потребляющему 10ГБ ОЗУ крокодилу.

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

    Складывается устойчивое впечатление, что на практике гораздо ценнее иметь не очень сложные, но требующие глубокого погружения обширные прикладные знания — тонкости C++, системные вызовы unix, структура пакета TCP, ключики команды ps, типы сборщиков мусора jvm — чем набивать голову обсосанной десятилетиями в научных кругах теорией алгоритмов и вычислений. Хотя конечно, расширение кругозора в свободное время — дело безусловно полезное.



    Машинное обучение

    С очередной, в который раз за последние десятилетия, модой на нейронки — deep learning и поиском «золота» в больших массивах данных, ну да, стало чуть повеселее. Начали вспоминать «подзабытую» банальную математическую статистику с логистическими регрессиями, бородатый столетний байесовский классификатор. Появились как грибы после дождя утилиты «анализа больших данных», которые ничего алгоритмически сложного внутри себя не представляют и пишутся средним разработчиков на пару отпусков: Spark, Hadoop/MR и т.п.

    Анализ языков

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

    Выводы

    Фанатизм в приобретении теоретических знаний может отобрать много времени и сил, а на практике знания могут не пригодиться и выветриться — т.к. почти все нужное человечеству уже написано/переписано по 100 раз в стандартных библиотеках, БД, файловых системах и прочей классике.

    Приобретение практических навыков: детали языков программирования, особенности unix, настройки софта, среды разработки, SQL, модные NoSQL возможности (а это опять таки подзабытые старые добрые алгоритмы) и немодные, но не менее мощные SQL инструменты — гораздо более полезно.

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

    Учимся коммуницироваться и работать в команде. Хорошее настроение — залог успеха проекта.

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

    Читайте мануалы по unix и до конца. Их много, это надолго и серьезно. Когда программа будет стабильно и предсказуемо работать — нальете чаю, закажете книжку типа этой и насладитесь наукой.

    Всем удачи, побольше практических кейсов и хорошего настроения!
    Share post

    Similar posts

    Comments 347

      +49
      Это справедливо для кодера (он же — "прикладной программист"), но не для разработчика (который с большой буквы).
      Рано или поздно возникают задачи, которые не может адекватно решить не то что ни одна из boost'овских библиотек — в принципе ни одна из существующих. И тогда приходится делать свой алгоритм, свою библиотеку, еще лучше других. Так и происходит прогресс :)

      Другое дело, что задач, не требующих computer science, гораздо больше — как в принципе и всего в реальном мире. Продавцов и менеджеров значительно больше, чем ученых. Тем не менее, в школах дают базовых курс физики и химии, поэтому понимание алгоритмов на базовом уровне (хотя бы для перспективы роста) — скорее необходимо.
        +3
        я и не спорю. просто странно, почему так востребованы и действительно полезны прикладные знания
          +29
          Потому что специалист, который знает библиотеки, но не понимает, как работает хеширование, сортировка, бинарный поиск, прохождение графов и т.д., может решать задачи, но до первой серьезной проблемы. Если где-то возникнет «бутылочное горлышко», понимающий алгоритмы разработчик его сможет разрешить, а кодер — не сможет.
            +9
            Такие случаи в моей практике — крайне редки. Сортировки и поиски по деревьям давно написаны и в либах и в БД. Хэширование… ну там просто все, на пальцах, за полчаса можно дойти по linear-probing hashing с бубнами. А глубоко понять… изменение системы счислений, метод Горна… нужно ли для решения задачи?
              +12
              Ну как редки? Практически в любом крупном проекте когда-никогда случаются. И в команде нужно иметь хотя бы одного специалиста, который способен их разрешать. Вы же поймите, что без этих знаний вы, конечно же, работу себе найдете и сможете вполне успешно заниматься разработкой. Но вы просто себе выставляете определённый потолок профессионального мастерства, за который (почему-то, непонятно почему) решили не заходить.
                +5
                Не все проекты являются высоконагруженными. Вам может нравится писать собственную реализацию какой-нибудь операции с модным алгоритмом дающим 1% прироста скорости, но вот юзеров будут бесить баги, которые возникают из-за того что вы пишите свой велосипед, а не используете проверенное решение, где баги уже выловили.
                  +9
                  Мы о разных вещах говорим. Я говорю, что знание и понимание алгоритмов — это полезное качество для профессионального разработчика. И может ему пригодиться в ряде случаев. Вы говорите, что плохо писать велосипеды и делать программы с багами. Конечно же, это плохо. Но к умению писать алгоритмы оно никакого отношения не имеет. Если человек вместо использования подходящего по критериям проекта готового решения пишет велосипед, это как раз непрофессионально.
                  С другой стороны, обратите внимание на «подходящего по критериям проекта». Наличие готового решения само по себе — это тоже далеко не всегда признак того, что не надо писать велосипед. Во-первых, его кастомизация может быть сложнее и «дырявее», чем создание некоторого нужного проекту подмножества функций. Во-вторых, оно может быть… плохо проверенным. Готовые библиотеки далеко не всегда хорошие. И так далее. В общем, не ищите себеряную пулю в стратегиях разработки, нет её. Но никакие профессиональные знания/умения лишними не бывают.
                    +6
                    Я скорее имел ввиду, что знание алгоритмов полезно но не является решающим навыком в квалификации программиста (за исключением особых случаев, типа поддержка критичного компонента в хай-лоад системе). Для сферического веб-программиста в вакууме будет полезнее знать SQL и особенности используемой БД, чем помнить как работает merge sort. И поэтому когда вы спрашиваете на интервью как инвертировать бинарное дерево, то потом не жалуйтесь что нету нормальных кандидатов.
                      +1
                      А особенности используемой БД разве не выражаются в тех алгоритмах, которые там используются?
                        +4
                        А кто нам даст время писать свою БД? :-)
                          +3
                          В той БД, которую вы используете каждый день — какие-то другие вещи, а не алгоритмы?

                          Думаю, пора выпускать дистрибутивы БД с надписью «без алгоритмов».
                            +4
                            В той ОС, которую вы используете каждый день, есть алгоритмы? Вы считаете, что каждый программист должен в подробностях знать, как перейти из реального режима в защищенный, какая структура у дескрипторов, какой в ней алгоритм планирования задач и вытеснения страниц?
                              +4
                              Вообще говоря, было бы очень неплохо. Не в подробностях, но хотя бы в общих чертах.
                                +2
                                А ассемблер знать не надо чтобы веб приложения делать? А то вдруг придется драйвер мыши вручную патчить.
                      +2
                      знание и понимание алгоритмов — это полезное качество

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

                      А еще по опыту работы, реализовать какой либо алгоритм эффективнее существующих решений сложно, но возможно это или нет — зависит скорее от IQ человека, чем от того знает он алгоритм наизусть или нет. Разница между тем, хранится знание в сером веществе или в электронном виде где нибудь на сервере — только в скорости доступа)
                        +2
                        Разница между тем, хранится знание в сером веществе или в электронном виде где нибудь на сервере — только в скорости доступа

                        Соглашусь. Однако, скорость доступа порой имеет очень важное значение. Например, когда для решения сложной задачи надо комбинировать набор алгоритмов. Если алгоритмы в "быстром доступе" в мозге, то решение будет найдено, если алгоритмы на сервере, то решение может быть попросту не найдено, так как мозг не будет способен найти "хитрую" но полезную связь между двумя описаниями алгоритма на сервере, в то же время, он сможет найти и использовать эту связь, если алгоритмы есть в мозгу. Подобным свойством мышления оперируют, в частности, MindMap'ы для достижения "Аха!"-эффекта при решении сложных задач..

                        Другой пример: решая сложную задачу, можно внезапно обнаружить, что ты изобретаешь велосипед, исходя из прототипа/набросков нового алгоритма — осознав, что предложенное новое "наивное" решение задачи есть не что иное, как реализация алгоритма X, который уже давно изучен, и можно сразу найти все его преимущества и недостатки… Я таких велосипедов наизобретал в аспирантуре, когда волею судеб был брошен в новую (ок, хорошо забытую со 2-го курса) для меня область.
                  +3
                  Вы уже сами ответили на свой вопрос:
                  ну там просто все, на пальцах, за полчаса можно дойти
                  — я верю что вы дойдете, а вот кодер — нет. Неужели не встречали таких? С другой стороны, обратный случай тоже нередок — перекачанный в теории индивид начинает через губу всех учить, хотя его код очевидно никуда не годится.
                  Я лично считаю что программирование конечно ремесло, ремесло в той же степени как и например живопись. А чего там такого сложного? Здесь красным намазать, здесь зеленым, и погуще, двухнедельных курсов должно хватить на обучение.
                    +2
                    Ну да, но без знания анатомии вы портрет хороший не нарисуете.
                      +3
                      я маринист )
                        +1
                        Как там с цветоведением?
                          +3
                          М-м-м, не очень понял, у меня ирония была, а у вас?
                          А с цветоведением у нас, маринистов, на двухнедельных курсах было просто, я же писал уже: зеленым — главное погуще.
                      +1
                      > Я лично считаю что программирование конечно ремесло, ремесло в той же степени как и например живопись
                      Ну не совсем так. Для программирования все-таки только знания нужны, а для любой живописи нужны как знания, так еще и «физические» навыки.
                      +6
                      Ведь проблема не в том, что надо написать сортировки, хеширование и другое. Проблема в том, что человек, который не писал, не может отличить одно от другого! И потом если ошибка в библиотеки он в полном ступоре. В общем проблема не в том, чтобы взять готовое решение, проблема в том, чтобы понять, что это решение.

                      Человек, который не знает, что такое поиск в ширину и в интернете найдет полную фигню.
                      –1
                      Кодер пойдет на stackoverflow и тоже сможет )
                      +4
                      Один из моих преподавателей на эту тему высказывался примерно так.

                      Само по себе _программирование_, в смысле написания кода — это ремесло. Можно и не знать «как», «почему» и «зачем», но при этом писать действительно замечательный код. Более того, при этом можно даже учить других это делать :-) Но, без «как», «почему» и «зачем» кроме, собственно написания кода, в наше с вами области знаний ничего делать-то и нельзя. Хорошая «новость» для некоторых из вас, заключается в том, что в подавляющем большинстве случаев вы будете заниматься т.н. прикладными задачами, которые суть и есть «задачи по написанию кода». Т.к. они уже давно все решены, и все что будет требоваться от вас, это записать это решение на каком-то конкретном языке.
                        +1
                        Это сложное ремесло. Огромное количество проектов — проваливается по причине "заговнокожения" чистых идей. Взлетают реально единицы.
                          +2
                          Сложное оно или нет — не важно же на самом деле :-) Писать код — это ремесло, ровно в том же смысле, в котором ремеслом является написание любого текста. Например, чтобы написать свой комментарий, вам сильно вряд ли понадобились знания о "как", "зачем" и — главное — "почему" в плане, например, падежей русского языка :-) Т.е. это, грубо говоря, дело привычки… навык, если хотите. А это и есть ремесло. У кого-то этот "навык" развит лучше, у кого-то есть "чувство стиля", кто-то вообще "поэт-прозаик" — суть от этого не меняется :-)
                            +8
                            Ни разу не видел проекта, который бы провалился по причине говнокода.
                            Зато знаю массу невероятно популярных проектов, представляющих из себя нечто невообразимое, но крайне востребованное десятилетиями.
                            простейший пример — WordPress. Или любой бесплатный движок интернет-магазина.

                            Талантливый алгоритмист — враг стартапа, пока он не называется Google. Всем остальным хватит говнокода, вопрос совсем не в этом.
                            первое, что определяет успех проекта — нужен ли он людям, или это фантазии авторов. Второе — сумеют ли авторы о себе рассказать. А как там оно написано — да плевать с пизанской башни, лишь бы работало. Будет затык — поправят. Наймут кого-то на месяц, и поправят. Или перепишут. Или свой компилятор нарисуют. Все это фигня, главное, чтоб был интерес...
                              +1
                              Я работал в стартапе, в котором было много говнокода. Конечно, нельзя сказать с уверенностью сказать, что он не взлетел из-за говнокода (были проблемы с монетизацией), но и из-за него было много проблем: на определенном этапе стало тяжело вносить изменения, начались тормоза, баги, хранение информации в облаках (фотографии) стало выливаться в большие шестизначные суммы в месяц (думаю, что это можно было бы оптимизировать и достаточно сильно сократить расходы). Толковый программист не пойдет работать в стартап с говнокодом (ну я бы сейчас точно не пошел ни за какие деньги). На мой взгляд и по моему опыту можно почти сразу писать хороший код (в начале допустим прототип с говнокодом, который потом без сожалений нужно выкинуть).
                              0
                              А какие бы вы назвали проекты, которые провалились по причине "заговнокожения" чистых идей? Я без сарказма.
                                +4
                                В отличии от проектов, которые не провалились, такие мало известны. Я, например, видел, как написанный за приличные деньги в течении двух месяцев проект, начал валиться при 6(!) посетителях в минуту. Автор просто отказался что-то менять — "у меня не было задачи делать хайлоад". Все. Проект свернули, так-как переписывать его было уже не было времени и заказчик не хотел терять еще деньги.
                                  +1
                                  А, ну такого навалом, да :) Но может там и нет "чистых идей", которые указал автор. Я, честно говоря, не понял, что это за "чистые идеи", поэтому решил уточнить.
                                    –4
                                    Чистая идея… идея, которая должна быть 100% без рисков попадания метериотом по голове — завершиться.

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

                                    И что мы видим в мире? Треш!

                                    На первом месте написанный на чистом C — nginx, который делает всех вчистую и по скорости, и по масштабируемости.
                                    Дальше видим написанный умными с потоками apache, который конечно тормознутый монстр.
                                    Я не говорю уже про Tomcat на java — перед которым нужно ставить nginx ;-)

                                    Т.е. простая идея, реализуемая на бумаге, превращается в лужу крови с мозгами в реальности… и рынок выбирает лучшее — nginx ;-)
                                      +8
                                      Ну, тут вы причины со следствиями вывернули. Именно apache и был написан "втупую". Создать по потоку на соединение — это вообще самое простое решение, которому учат в любом учебнике.

                                      А вот автору nginx пришлось постараться — асинхронные конечные автоматы, хитрое управление памятью, свои структуры данных...
                                        –2
                                        Сорри. Но я к тому, что человек просто знал хорошо FreeBSD, добавил немного структур данных (видели исходники наверно подробно), написал аккуратно и со вкусом и без выпендрежа. И на этом живет хайлоад всего мира. Победила проста и здравый смысл.
                                          –1
                                          Ну еще из интересного там — обработка сокетов через select/pool. Это старая техника, но эффективная и сложная в реализации. Никаких алгоритмов новых.
                                            +9
                                            Мне кажется, вы делите алгоритмы на "это я знаю, это не ново (для меня)" и "этого я не знаю, это что-то новое неизвестное, да и зачем это учить".

                                            Это вы знаете про select/poll. А для кого-то неблокируемые сокеты — это "вау, ничего себе!". Почему? Потому что он последовал вашему совету и не изучал алгоритмы :)
                                            Кстати, у nginx ещё и sendfile, async io, хеш таблицы с использованием строки кэша процессора и много других алгоритимческих вкусностей.
                                            nginx — это вообще отличный пример, когда просто хорошее знание и применение алгоритмов дало пользу всему человечеству.
                                              +1
                                              Нет, это новая техника. Многопоточный вариант появился раньше.
                                          0
                                          Еще пример чисто идеи — микроядро ОС, о котором спорят Торвальдс с Таненбаумом. :-) И что использую люди — тупо, кондово, монотитно написанный linux. FreeBSD, OpeenBSD,… — писались более умно, правильно, секьюрно — и где они?
                                            +1
                                            На более-менее защищаемых системах встречаются *BSD довольно часто, по моим наблюдениям. Ну, на платежных гейтах и банковской среде, например. И на банкоматах до сих пор встречается NetBSD, если мне память не изменяет.
                                        –3
                                        Названия я не могу сказать, но много лет назад еще до Битрикс часто наблюдал такие кейсы:
                                        1) Ставится очевидно достижимая задача, без новых алгоритмов
                                        2) Ее делает один человек и видно четко, что скоро все закончится
                                        3) Набираются люди
                                        4) Появляются "умники", втыкающие неадекватно сложные-дорогие-ненужные вещи. Ну например вместо записи байтов в сокет ставим либу, которая делает тоже самое через задницу и ООП.
                                        5) Проект никак не может завершится. Сроки сорваны. Люди увольняются. Умники делают черточку в резюме :-)
                                          +11
                                          Понятно. Вы знаете, так получилось, что вы только что сами ответили на вопрос, зачем программисту знать алгоритмы. Просто для того, чтобы понимать, какой алгоритм лучше применить в каждом случае и не тащить вместо этого гору библиотек.

                                          В вашей логике есть один момент, который вы упустили — вы уже знаете алгоритмы и применяете эти знания, не задумываясь об этом. И, пописывая код с этими знаниями, думаете "а надо ли мне было учить вот это все?". У вас есть понимание, когда что можно воткнуть. Это вам помогает больше, чем вы думаете.

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

                                          Поэтому, отвечая на ваш вопрос, "нужно ли знать", ответ "ДА". Необязательно, чтобы их применять, или разрабатывать новые. Но хотя бы для того, чтобы понимать, что происходит.
                                      –2
                                      А когда ты в проектах, они запускаются, приходят клиенты довольные — вот и появляется время почитать "а как оно работает"? :-)
                                      +3
                                      Просто есть разница между прогрессом, развитием области, инструментами и прикладным программированием при разработке конечных продуктов для конкретных заказчиков и асбтрактных домохозяек. «Кодеры» в основном решают последние задачи. А вот когда появляются вопросы про реализацю чего-то кардинально нового, то тут другое дело. Приимерами могут служить различные графические движки, игровые платформы. Да даже масштабирование какой-то интернет-платформы. Качественный продукт может потребовать различных знаний.

                                      А вот вопрос развития области требует, определённо, не простого знания библиотек. откуда появились эти удобные и производительные инструменты? Их кто-то создал.

                                      А изучение базовых дисциплин и принципов, особенно в вузе, позволяет понять область, определить свою степень вовлечённости и интереса, а также отделяет те 0,001%, которые потом создадут что-то кардинально новое. Понятное дело, что немало кто пробился сам, но накапливать знания и узучать суть лучше с теми кто в теме. К.О.
                                      –3
                                      Ты не успеешь скорее всего придумать свой алгоритм, если не занимаешься целенаправленно научной работой. Будешь искать в паперах, в материалах конференций…
                                        0
                                        зависит от места и темпа работы, дедлайна и общей склонности к научной деятельности.

                                        проще, конечно, брать уже готовые (и я чаще так делаю), но рано или поздно приходит момент, когда ни один из готовых не обладает нужной производительностью, в таком случае приходится придумывать что-то кардинально новое или как минимум дополнять/оптимизировать существующие решения.
                                      +8
                                      А нужно ли знать программисту алгоритмы?

                                      Нужно знать теорию анализа и проектирования алгоритмов — чтобы хотя бы понимать, как оценивается сложность вычисления.
                                        –5
                                        там вся теория — две строки по сути
                                          +9
                                          Даже нотацию большого O сложно запихнуть в две строки.
                                            0
                                            Ад, квадрат (тоже ад, но иногда нельзя), линейно-логарифмическая зависимость, линейная. Понимать что значит, что задача просто не решается и требуется перебор (NP, криптография с открытым ключом, разложение на множители и т.п.).
                                              +9
                                              Недостаточно перечислить, надо знать, как это определяется.

                                              Понимать что значит, что задача просто не решается и требуется перебор

                                              И откуда это понимание возьмется?

                                              требуется перебор (NP,

                                              … эээ, а почему перебор — это обязательно NP? Есть задачи, которые можно решить перебором за линейное время.
                                                0
                                                Как научиться понимать — посмотреть в таблицу известных алгоритмов с указанной стоимостью. Возьмем задачку дискретного логарифмирования и попробуем ускорить процесс :-)
                                                  +8
                                                  Как научиться понимать — посмотреть в таблицу известных алгоритмов с указанной стоимостью

                                                  Вот и закончились (давно уже) ваши две строчки. Собственно, получается, что знать-то — надо.
                                                    0
                                                    Да вот поэтому и написал пост. С одной стороны быть компетентным — правильно. Учиться и постигать науку — нужно. Но из практики получается, что требуются знания другого рода, как не парадоксально.
                                                      +11
                                                      Требуются знания обоих родов. И ничего парадоксального в этом нет.
                                                        0
                                                        Чтобы unix знать, нужны годы практики. Либо это будут поверхностные понятия. Я об этом.
                                                          +3
                                                          И вы по каким-то причинам считаете, что для программиста (любого, без уточнений) поверхностные знания в юниксе — это хуже, чем поверхностные знания в алгоритмах?
                                                            0
                                                            Если пишешь код — пойми где и как он выполняется и каким софтом другим. И так по цепочке. Остается мало времени на теорию, к сожалению.
                                                              +5
                                                              И так по цепочке.

                                                              Вплоть до электронов, я надеюсь?

                                                              (нет, вы серьезно считаете, что абстракция — ненужная вещь?)
                                                  0
                                                  По сути, да, нужно просто выучить список того, что уже открыто — 3 страницы. Чтобы пузырьком не сортировать :-)
                                                    +4
                                                    По сути, да, нужно просто выучить список того, что уже открыто

                                                    Мало выучить список, неплохо бы еще понимать, что там зачем.
                                                      +3
                                                      Мало выучить список, неплохо бы еще понимать, что там зачем.

                                                      Понимать — до уровня электронов?
                                                        +1
                                                        Нет, зачем, там есть формальное описание.
                                                          +4
                                                          Разве формальное описание не обязательно понимать? На эту тему есть замечательный отрывок из интервью с Фейнманом — Почему так сложны вопросы "почему"?. Кому-то достаточно знать "формального описания" и принимать его за основу, кому-то недостаточно. Кому-то даже формального описания знать не нужно, достаточно знать что

                                                          O(1) < O(log(N)) < O(N) < O(N*log(N)) < O(N^2) < O(N^3)… < O(a^N) < O(N!)

                                                          и уметь угадать сложность с точностью примерно плюс-минус пару-тройку звеньев. А кому-то покласть на эту сложность, потому что у него по жизни N=3.
                                                            0
                                                            Разве формальное описание не обязательно понимать?

                                                            Обязательно. Но на этом уровне абстракции (псевдоязык и матаппарат) можно остановиться.
                                                              –4
                                                              Можно остановиться и гораздо раньше.
                                                                +2
                                                                Можно. Вам никто не запрещает.
                                                                  –3
                                                                  Про то и речь. А то всё "обязательно", "должен".
                                                                    +6
                                                                    Нет-нет-нет, это не про вас. Вы никому ничего не должны и не обязаны.
                                                                      –3
                                                                      Тогда про кого? А то я что-то упустил нить. Так кто и кому должен и обязан?
                                                                        +3
                                                                        Это совершенно не принципиально. Не принимайте к сердцу.
                                                              0
                                                              Если по жизни N=3, то алгоритмы не нужны, все задачи решаются перебором.
                                                              Вот только у любой базы данных N не имеет верхней границы, и O-нотация внезапно становится важна.
                                                  +11
                                                  Если программист — программист, то достаточно увидеть это:

                                                  O(1) < O(log(N)) < O(N) < O(N*log(N)) < O(N^2) < O(N^3)… < O(a^N) < O(N!)

                                                  90% алгоритмов это перекрывает.
                                                    0
                                                    да!
                                                      +19
                                                      Осталось понять, в какую категорию относится конкретный только что написанный код.
                                                        +1
                                                        Да это тоже просто, каждый цикл обычно дает множитель N. Поиск по упородоченным структурам (дереву, куче, отсортированному массиву) дает множитель log(N). Все остальное можно узнать в описании либ (если используются).
                                                          +10
                                                          Да это тоже просто, каждый цикл обычно дает множитель N.

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

                                                          Поиск по упородоченным структурам (дереву, куче, отсортированному массиву) дает множитель log(N).

                                                          Ох. Поиск по упорядоченному дереву дает O(h), а не O(log n). Я не знаю, что такое "поиск в куче", но получение верхушки в куче (а это та операция, под которую куча "заточена") — O(1) (удаление верхушки — действительно O(log n)).

                                                          Все остальное можно узнать в описании либы.

                                                          Ах если бы.
                                                            –8
                                                            Ох. Поиск по упорядоченному дереву дает O(h), а не O(log n)

                                                            Ахаха, лол, может тогда и вспомните какая функция связывает h и n?

                                                            Но, вообще речь не об этом. Любая дисциплина на 80% состоит из чистых знаний, и 20% смежных. O-нотация это смежные знания, они не делают программиста лучше или хуже. Да, порой это полезно. Но это не ключевой навык. Самого беглого знакомства достаточно.
                                                              +6
                                                              Ахаха, лол, может тогда и вспомните какая функция связывает h и n?

                                                              В общем случае, h <= n. И все.

                                                              O-нотация это смежные знания, они не делают программиста лучше или хуже.

                                                              А какие же знания для программиста в общем случае "чистые"?

                                                              Самого беглого знакомства достаточно.

                                                              Достаточно для чего?
                                                                –6
                                                                Поиск по дереву — O(log n)
                                                                  +11
                                                                  Поиск по дереву — O(log n)

                                                                  По любому, серьезно?
                                                                    –2
                                                                    Да нет, первый раз услышал про сбалансированные деревья :-)

                                                                    Вы откровенно умничаете, неконструктивно жирно троллите и цепляетесь к несущественным мелочам, которые очевидны.
                                                                      +8
                                                                      цепляетесь к несущественным мелочам, которые очевидны.

                                                                      Кому очевидны? Человеку, который первый раз услышал про деревья? Или человеку, который некоторое время потратил на то, чтобы с ними разобраться?
                                                                        +3
                                                                        Но Ваши опасения разделяю. Страшно давать nodejs-разработчику с отрицательными знаниями алгоритммов давать проектировать. Так что лайкнул.
                                                                  –2
                                                                  В общем случае, h <= n. И все.

                                                                  O(h) = O(log n) для почти всех упорядоченных деревьев.

                                                                  А какие же знания для программиста в общем случае «чистые»?

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

                                                                  Т.е. если мыслить дисциплинарно, то программирование в основном строится на общении (психология, риторика), умении составлять тексты, описания, формализировать информацию (логика, диалектика, литературные навыки), умение работать с компьютером (браузер, текстовый редактор, командная строка), освоить что такое переменная, функция, число, строка, массив, таблица, что такое if/for/switch и немного ООП. И все, человек уже может работать программистом.

                                                                  Достаточно для чего?

                                                                  Получить работу программистом, работать программистом, получать за это деньги, двигаться по карьерной лестнице.
                                                                    +5
                                                                    O(h) = O(log n) для почти всех упорядоченных деревьев.
                                                                    Только для сбалансированных. Для обычных упорядоченных ничего больше O(h) = O(n) гарантировать нельзя.
                                                                      –2
                                                                      Смотря что подразумевать под O, худший случай да. В среднем же O(log n).
                                                                        +3
                                                                        Извините, что вклиниваюсь, но сама фараза "смотря что подразумевать под O" просто требует комментария из-за ее абсурдности и противоречивости. Есть конкретное определение O() и не с потолка оно взято. Конкретные свойства делают это определение полезным на практике. И подразумевать под O() что-то другое никак нельзя.
                                                                          0
                                                                          Имелось ввиду, что подразумевается под выражением в целом, а не что такое O. Худшая оценка высоты дерева, да O(n). Средняя O(log n). Я думал это понятно итак, без оговорок.
                                                                            0
                                                                            Оговорки все равно нужны. В данном случае — про способ и порядок построения дерева. Есть задачи, в который построение дерева без балансировок будет стабильно выдавать длинные "сосиски" со средней высотой O(n).

                                                                            Кстати, одна из таких задач очень распространена. Я говорю про индекс в базах данных, построенный по автоинкрементному полю.
                                                                            +1
                                                                            Опять же, не придираясь к фразе, средняя оценка — это если входные данные случайны. А как вам уже ответили — это далеко не всегда так. Кроме того, если сервер можно подвесить каким-то запросом, который является худшим случаем, то это совсем не хорошо.
                                                                              –4
                                                                              Это так, однако qsort до сих пор используется тут и там, причем порой в самом неудачном варианте.
                                                                              Понятное дело, что все кто используют деревья обычно заботятся о балансировке.

                                                                              Но речь то про другое, что все эти знания сомнительной ценности для разработчика. Например на stackoverflow с тегом [alogrithm] около 62.200 вопросов, а с тегом [javascript] 1,073,199 вопросов.

                                                                              Да и в вакансиях я не встречал, что бы указывали желательное знание O-нотации или там умение балансировать деревья. Можно сказать конечно, что эти знания подразумеваются. Но почему тогда тут и там указывают какой-неть git, или "ответственное отношение к работе"? Уж эти требования тогда тем более можно не указывать.

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

                                                                              Другими словами, "прогнило что-то в Датском Королевстве".
                                                                                +4
                                                                                А кого бишь привело к дичайшему фейлу знание алгоритмов?
                                                                            +3
                                                                            Извините что вклиниваюсь во вклинивание, но программисты-практики часто под O подразумевают Θ или даже Ω
                                                                        +1
                                                                        O(h) = O(log n) для почти всех упорядоченных деревьев.

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

                                                                        Все что касается умения анализировать и формализировать задачи из реального мира

                                                                        Ха, а ничего, что вы только что влезли в область работы аналитика?

                                                                        И все, человек уже может работать программистом.

                                                                        Есть некоторая разница между "может работать" и "хороший специалист".

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

                                                                        А, ну если в таких терминах, то да, сколько угодно.
                                                                          +3
                                                                          Да все понятно, что тут спорить. Вопрос — в адекватности :-)
                                                                            +1
                                                                            Ха, а ничего, что вы только что влезли в область работы аналитика?
                                                                            Если не влезать в область работы аналитика — то аналитики такого напридумывают…
                                                                              +1
                                                                              Эту цепочку рассуждений можно продолжать бесконечно, вы же понимаете.
                                                                              –1
                                                                              > Ха, а ничего, что вы только что влезли в область работы аналитика?
                                                                              Область работы аналитика является подмножеством области работы программиста. Это просто следующий уровень специализации в крупной команде.
                                                                                +1
                                                                                Область работы аналитика является подмножеством области работы программиста.

                                                                                Серьезно? Собирать со стейкхолдеров и писать хорошие, полные, непротиворечивые требования — это подмножество области работы программиста? Ну-ну, удачи этому программисту в том, чтобы найти время на программирование.
                                                                                  0
                                                                                  Серьезно. Фразу «следующий уровень специализации» вы недочитали, или намеренно проигнорировали?
                                                                                  Если вы делаете проект (хорошо, назовем его «проектик», а то некоторые начинают воротить нос, если слышат слово «проект» в отношении работы, которая делается командой меньше десяти человек и стоит меньше пары миллионов денег) в одиночку, вы будете собирать полные и непротиворечивые требования, и никуда от этого не денетесь, потом будете разрабатывать архитектуру, потом будете непосредственно программировать, потом тестировать, потом деплоить на продакшен. И всё это будет вашей работой программиста, и у вас будет время и на первое, и на второе, и на десятое. Когда-то в былые времена только так мы и работали, и ничего, выжили, не помер никто.
                                                                                  Если ваш проектик будет расти, ваша команда тоже, то у вас сначала появится другой программист, который всё это будет делать вместе с вами. Потом вы еще одного наймете, сами при этом сконцентрируетесь на архитектуре, управлении командой и всё еще на сборе требований, и всё еще будете программистом. А через какое-то время уже и девочку в очках с блокнотиком наймете. Как раз на сбор требований.
                                                                                  Специализация, она вот такая. Девочка эта не будет вам писать код, но она будет собирать требования, писать техзадания и формализовать алгоритмы. Вы её будете называть аналитиком, но по сути, она просто будет выполнять коммуникационную/бюрократическую часть работы программиста. Потому что забрать её у разработчиков и сфокусировать их только на написании кода — это таки да, здорово повышает их производительность.
                                                                                    +2
                                                                                    Если вы делаете проект (хорошо, назовем его «проектик», а то некоторые начинают воротить нос, если слышат слово «проект» в отношении работы, которая делается командой меньше десяти человек и стоит меньше пары миллионов денег) в одиночку

                                                                                    … то то, что я делаю, не называется работой аналитика. А называется "сделаю проектик в одиночку".

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

                                                                                    Нет, не буду. Зачем?

                                                                                    (btw, нельзя собрать полные и непротиворечивые требования, можно только создать документ с такими требованиями)

                                                                                    Когда-то в былые времена только так мы и работали

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

                                                                                    Ну и да, если в каких-то командах роли совмещаются, это не значит, что все эти роли являются подмножеством одной области работы. Если я на том же проектике завел себе ИП, беру с людей деньги и веду финансовую отчетность — это никак не значит, что работа бухгалтера тоже является частью области работы программиста.
                                                                                      +1
                                                                                      > … то то, что я делаю, не называется работой аналитика.
                                                                                      Почему это не называется? Именно так и называется. Проводя анализ, вы делаете работу аналитика. Если вы вздумаете пойти и подоить корову на ферме в качестве полезной подработки, вы будете делать работу доярки. А если поведете школьный автобус, то будете делать работу водителя школьного автобуса.

                                                                                      > Нет, не буду. Зачем?
                                                                                      Будете. Потому что без этого вы проект не выполните. Я сейчас не про качество вашей работы (удастся вам собрать всё непротиворечивое или не удастся — дело тридесятое), и не про объем (будет там документ на полгода работы или бумажка с тезисами по итогам одного совещания), а про сам факт выполнения такой работы.

                                                                                      > Я не знаю, какие «вы» только так и работали, а я вот никогда так не работал.
                                                                                      Значит, конкретно «вы» или пришли в эту профессию уже в 21 веке, или изначально попали в какой-то центр космических технологий. Поздравляю. А у нас в _этой стране_ в 1990-е годы такое только-только зарождалось, и было редким исключением, а не правилом профессиональной разработки.

                                                                                      > это никак не значит, что работа бухгалтера тоже является частью области работы программиста.
                                                                                      Это несравнимые вещи. Работа бухгалтера, как и доярки, для написания программы не требуется. А вот системный анализ требуется. И человек на должности системного аналитика по своей профессии, в отличии от бухгалтера, тоже программист.
                                                                                        +3
                                                                                        Почему это не называется?

                                                                                        Потому что далеко не факт, что я не скипну этот этап полностью, как и любой из остальных.

                                                                                        Проводя анализ, вы делаете работу аналитика.

                                                                                        … но вообще, конечно, эта фраза очень показательна. "Делаете работу аналитика". Не работу программиста, а работу аналитика.

                                                                                        Потому что без этого вы проект не выполните.

                                                                                        Почему?

                                                                                        Значит, конкретно «вы» или пришли в эту профессию уже в 21 веке, или изначально попали в какой-то центр космических технологий.

                                                                                        Нет и нет.

                                                                                        А у нас в _этой стране_ в 1990-е годы такое только-только зарождалось, и было редким исключением, а не правилом профессиональной разработки.

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

                                                                                        Работа бухгалтера, как и доярки, для написания программы не требуется. А вот системный анализ требуется.

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

                                                                                        Но представьте себе на минуту, что вы делаете игру. Для нее — иногда — нужен сценарий. Является ли работа сценариста частью работы программиста?

                                                                                        И человек на должности системного аналитика по своей профессии, в отличии от бухгалтера, тоже программист.

                                                                                        А человек на должности художника, рисующего картинки для игры?

                                                                                        Я повторюсь, то, что люди иногда совмещают разные роли, никак не означает, что все эти роли, на самом деле — часть работы программиста.
                                                                                          +1
                                                                                          >> Потому что без этого вы проект не выполните.
                                                                                          > Почему?
                                                                                          Потому что нельзя писать для заказчика программы, не собрав его требований и не вникнув в них. Если вы это не сделаете, заказчик её у вас не купит.

                                                                                          > Нет и нет.
                                                                                          А у вас в профиле написан 1981-й год рождения. Вам было 19 лет, когда начался 21 век. Так что где-то вы врёте. Подозреваю, врёте сейчас, ибо вы-то ввязались в спор, ну а как же человек с тегом «Архитектор» в профиле может согласиться с чужим мнением, будь оно хоть трижды аргументированным? ;)

                                                                                          > «Этой страной» жизнь не ограничивается, если что
                                                                                          Полагаю, ни мне, ни кому-либо из других читателей форума факт вашей эмиграции не интересен. Тем более раз если вас отсюда увезли папа с мамой в юности, и вы не в курсе, как тут велась разработка ПО, то хотя бы на слово поверьте, а не спорьте.

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

                                                                                          > Я повторюсь, то, что люди иногда совмещают разные роли, никак не означает, что
                                                                                          > все эти роли, на самом деле — часть работы программиста.
                                                                                          Конечно же, не означает. Часть работы программиста — анализ, разработка архитектуры, написание кода, тестирование, т.е. все те работы, которые выполняют сотрудники с квалификацией программиста. Рисование картинок и продажа софта, это не часть работы программиста.
                                                                                            –1
                                                                                            Потому что нельзя писать для заказчика программы, не собрав его требований и не вникнув в них. Если вы это не сделаете, заказчик её у вас не купит.

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

                                                                                            А у вас в профиле написан 1981-й год рождения. Вам было 19 лет, когда начался 21 век. Так что где-то вы врёте.

                                                                                            Вы считаете, что люди до 19 лет не работают?

                                                                                            Полагаю, ни мне, ни кому-либо из других читателей форума факт вашей эмиграции не интересен.

                                                                                            А при чем тут эмиграция? Я говорю о том, что практики индустрии формируются не в одной стране.

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

                                                                                            Почему вы считаете, что это системный анализ, а не проектирование?

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

                                                                                            Если сотрудник с квалификацией программиста рисует картинки, является ли рисование картинок частью работы программиста?
                                                                                              0
                                                                                              > Вы не поверите, но можно. Вопрос агрессивности продажи
                                                                                              Скорее вопрос чистоты «на руку» как контрагента. Если вы не планируете решить задачу заказчика, а просто убедить его, получить предоплату, а дальше — хоть трава не расти, то да, можно. И свой собственный проект можно. Только свой собственный — это не для заказчика. Только какое отношение это имеет к вопросу? Конечно же, из сотни задач вы можете найти одну, которую вы напишете сразу, без анализа. Например, потому что вы это решали.

                                                                                              > Вы считаете, что люди до 19 лет не работают?
                                                                                              Не, я читал в детстве книжку «Сын полка». Бывают исключения. Вас сразу после школы куда взяли сыном полка, в Oracle или Microsoft?

                                                                                              > Я говорю о том, что практики индустрии формируются не в одной стране.
                                                                                              Ну так вы не в эмиграции были, а где-то в СНГ? И в 90-е годы? И в 19 лет? И у вас на предприятии использовалась полноценная современная методика разработки? Ну пусть не совсем современная, пусть не эджайл, но хотя бы водопадец?
                                                                                              Я же говорю, врёте. :)

                                                                                              >Почему вы считаете, что это системный анализ, а не проектирование?
                                                                                              О, коллега, вы сейчас вообще удивитесь, наверное. Конечно, если этот разговор завели ради какого-то смысла, а не чтобы переспорить оппонента ради самого «переспорить», что, судя по вашей манере отвечать, вполне вероятно. Так вот, системный анализ это еще и часть процесса проектирования ;)

                                                                                              > Если сотрудник с квалификацией программиста рисует картинки,
                                                                                              > является ли рисование картинок частью работы программиста?
                                                                                              Ему нужна квалификация программиста для рисования картинок?
                                                                                                +1
                                                                                                Только какое отношение это имеет к вопросу?

                                                                                                Да прямое, в общем-то. Речь же шла о том, без чего нельзя выполнить проект.

                                                                                                Вас сразу после школы куда взяли сыном полка, в Oracle или Microsoft?

                                                                                                Ни то, ни другое (заодно и ни третье, ни четвертое, потому что не сразу после школы и не сыном полка). Но вообще, в резюме все написано.

                                                                                                Ну так вы не в эмиграции были, а где-то в СНГ? И в 90-е годы? И в 19 лет? И у вас на предприятии использовалась полноценная современная методика разработки? Ну пусть не совсем современная, пусть не эджайл, но хотя бы водопадец?

                                                                                                Москва, 90-ые годы, 17-18 и далее лет, "водопадец", ага. Учитывая, что водопаду к этому моменту никак не меньше 30 лет (окей, термину — не меньше 20) — ничего удивительного, правда же?

                                                                                                Я же говорю, врёте

                                                                                                Если вы чего-то не видели, это еще не значит, что описывающий врет.

                                                                                                Так вот, системный анализ это еще и часть процесса проектирования

                                                                                                Ага, выстраивается иерархия. Проектирование — часть разработки, анализ — часть проектирования. И все это — обязанности программиста.

                                                                                                Ему нужна квалификация программиста для рисования картинок?

                                                                                                А для сбора и формализации требований с заказчика нужна квалификация программиста?
                                                                                                  –1
                                                                                                  > Да прямое, в общем-то. Речь же шла о том, без чего нельзя выполнить проект.
                                                                                                  Я прошу прощения, но мы же с вами не юридические условия договора обсуждаем. Мне грешным делом подумалось, что вы в состоянии без лишних уточнений с моей стороны понять, что если говорится «нельзя выполнить проект», то речь идет об общем правиле, а не об абсолютном законе. И что, естественно, найти какие-то единичные исключения из любого правила при желании можно. По крайней мере, этот момент очевиден.

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

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

                                                                                                  > А для сбора и формализации требований с заказчика нужна квалификация программиста?
                                                                                                  Нужна, естественно, хотя бы на базовом уровне. Иначе формализация будет такой, что программист там мозг взорвет.
                                                                                                    +1
                                                                                                    Нужна, естественно, хотя бы на базовом уровне.

                                                                                                    Странно, почему в Вигерсовских Software Requirements (я смотрю на второе издание, 2003 год) в списке скилов Requirement Analyst (с. 68-70) есть listening, interviewing/questioning, analytical, facilitation, observational, writing, organizational, modeling, interpersonal и creativity, но нет ничего, связанного с программированием?

                                                                                                    Ну и оттуда же хорошая цитата: "Project managers who lack a dedicated requirements analyst often expect a developer to do the job. Unfortunately, the skills and personality needed for requirements development aren’t the same as those needed for software development." (с. 72)
                                                                                                      0
                                                                                                      Здесь нет противоречий тому, что я говорю. Абсолютно верно, для сбора требований нужны скиллы коммуникаций, и не нужны скиллы знания Java. Моделирование, аналитика — это та самая смежная часть, где требования превращаются в спецификацию, понятную ИТ-разработчку.
                                                                                                      > Unfortunately, the skills and personality needed for requirements development
                                                                                                      > aren’t the same as those needed for software development
                                                                                                      Здесь речь идет о том, что не стоит пересаживать на сбор требований человека из разработки. Это тоже верно и не противоречит вышесказанному.
                                                                                                      А теперь вы лучше скажите, если вам в команду понадобится молодой аналитик с целью «выучить и получить отдачу», где вы его будете брать? Какого он будет профессионального профиля, из какого учебного заведения?
                                                                                                        +1
                                                                                                        Абсолютно верно, для сбора требований нужны скиллы коммуникаций, и не нужны скиллы знания Java

                                                                                                        Так где же квалификация программиста-то в этих скиллах?

                                                                                                        Моделирование, аналитика — это та самая смежная часть

                                                                                                        Аналитические навыки, в терминах Вигерса, совсем не об этом:

                                                                                                        An effective analyst can think at multiple levels of abstraction. Sometimes you must drill down from high-level information into details. In other situations, you’ll need to generalize from a specific need that one user described to a set of requirements that will satisfy many members of a user class. Critically evaluate the information gathered from multiple sources to reconcile conflicts, separate user “wants” from the underlying true needs, and distinguish solution ideas from requirements.

                                                                                                        Это обобщенный навык, не специфически программный. С моделированием, в принципе, аналогично:

                                                                                                        Tools ranging from the venerable flowchart through structured analysis models (data flow diagram, entity-relationship diagram, and the like) to contemporary Unified Modeling Language (UML) notations should be
                                                                                                        part of every analyst’s repertoire. Some will be useful when communicating with users, others when communicating with developers. The analyst will need to educate other stakeholders on the value of using these techniques and how to read them.

                                                                                                        Здесь речь идет о том, что не стоит пересаживать на сбор требований человека из разработки.

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

                                                                                                        А теперь вы лучше скажите, если вам в команду понадобится молодой аналитик с целью «выучить и получить отдачу», где вы его будете брать? Какого он будет профессионального профиля, из какого учебного заведения?

                                                                                                        В идеале, его образование и/или профессиональный опыт должны коррелировать с предметной областью. Если это сложно — а это чаще всего сложно — то любое высшее (я в этой области, к сожалению, сноб) или высшее-в-процессе. CS100 в анамнезе помогает, но не обязателен.
                                                                                                          0
                                                                                                          > Вам это не кажется нелогичным? «Область работы аналитика является
                                                                                                          > подмножеством области работы программиста»
                                                                                                          Нет. Вы каждый раз в упор игнорируете слово «специализация». Вернитесь в начало разговора, и еще раз прочтите тезисы. Разработчик-кодер — это также дальнейшая специализация программиста. После специализации, абсолютно верно, взаимозаменяемость пропадает.
                                                                                                            0
                                                                                                            Разработчик-кодер — это также дальнейшая специализация программиста.

                                                                                                            А почему вы считаете, что Вигерс в приведенной выше цитате под developer понимаете "разработчика-кодера", а не "программиста"?

                                                                                                            И почему, тогда уж, вы считаете, что в треде, в котором вы участвуете (или в заголовке статьи, for that reason) слово "программист" употребляется в том смысле, который вы в него вкладываете, а не в каком-то другом?

                                                                                                            И где и кем определен тот всемогущий программист, способный выполнить любую фазу водопада, на которого вы ссылаетесь?
                                                                      +4
                                                                      Не всегда так. Есть такое понятие "Амортизационный анализ".
                                                                        +1
                                                                        Добавлю: и еще есть убывающие геометрические прогрессии, которые запросто могут множитель в оценке времени "скушать".
                                                                          –5
                                                                          Ну что значит не всегда так -)

                                                                          Речь ведь шла именно об O-нотации. Это намек на то, что для программиста там нет ничего особо сложного, да и полезного тоже мало.

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

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

                                                                          А пришло в программирование это все от того, что большинство computer science-ученых довольно посредственные математики, адекватного инструмента придумано не было, взяли то что учили в университете на первом курсе без особого понимания.

                                                                          В итоге, O-нотация преподносится "алгоритмистами" как какое-то фундаментальное понятие, но в действительности это одна из самых позорных страниц computer science как науки.

                                                                          Да, сейчас многие хотят эту дыру заткнуть какими-то комбинаторными понятиями, амортизационный анализ из той же оперы, но там где начинается комбинаторика, там заканчивается наука.
                                                                            +7
                                                                            А пришло в программирование это все от того, что большинство computer science-ученых довольно посредственные математики, адекватного инструмента придумано не было, взяли то что учили в университете на первом курсе без особого понимания.

                                                                            Это вы сейчас Кнута записали в посредственные математики?
                                                                              –6
                                                                              А вы знаете какие-то известные теоремы доказанные Кнутом?

                                                                              Как ученый Кнут чрезвычайно выдающийся, это бесспорно, но как математик, так се. По сути он даже и не математик.

                                                                              И это не голословные утверждения, из математиков, которые имели отношение к алгоритмам, даже если брать русских Колмогорова и Маркова-младшего. У них чуть ли не каждая теорема — это новая ветвь математики и новая область в computer science.

                                                                              У Кнута ничего подобного мы не наблюдаем, хотя он хорошо классифицировал алгоритмы, и хорошо их придумывал. Но успешность в решении какой-то конкретной задаче, даже очень важной, это не математика.
                                                                                +4
                                                                                А вы знаете какие-то известные теоремы доказанные Кнутом?

                                                                                А это обязательное требование для того, чтобы быть не-посредственным математиком? Вы же говорите о понимании, а не об изобретении нового.

                                                                                Но вообще, так, на минуточку: "a Fellow (first class of Fellows) of the Society for Industrial and Applied Mathematics in 2009 for his outstanding contributions to mathematics [...] a fellow of the American Mathematical Society."
                                                                                  –6
                                                                                  Да это вообще не аргумент, там кого только нет в этих сообществах.
                                                                                    +11
                                                                                    Я боюсь, что для вас ничто не аргумент, кроме вашего собственного мнения.
                                                                                  +8
                                                                                  А ты думаешь, что придумывание алгоритмов и их анализ и доказательство теорем чем-то отличаются?

                                                                                  Попробуй формально докажи, что хеш-таблица имеет время поиска амортизированное O(1). Доказательство не проще центральной предельной теоремы. Кнут доказал теорему о хеш-таблицах.

                                                                                  Ты пользуешься знаниями о вычислительной сложности алгоритмов как будто это само собой разумеющееся. Ты забыл что математики вроде кнута долго доказывали свойства алгоритмов, чтобы ты мог гордо а собеседовании сказать, что сложность быстрой сортировки — NlogN.
                                                                                    –4
                                                                                    Это все доказывается элементарно, сортировка там вообще не сложнее задачи про взвешивание монеток.

                                                                                    У Кнута есть работы по математике, но это комбинаторные работы по числу Лаваса для графов. Но там мутная история, т.к. потом Лавас же получил премию Кнута. (Т.е. рука руку моет.)

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

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

                                                                              Т.е. по вашему комбинаторика не является разделом математики? Боюсь что википедия с вами не согласна. Или что вы хотели сказать этой фразой?
                                                                        –2
                                                                        Кажется, я нашел закономерность в этой формуле: если убрать O(..) она по прежнему верная.
                                                                          +1
                                                                          Про то и речь, что знаний там никаких нет)

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

                                                                          Для практики же полезен бенчмарк, где учитываются статистика данных, реальное количество данных и т.д. Асимптотика вообще может не отражать реальное положение дел.
                                                                            +5
                                                                            Для практики же полезен бенчмарк, где учитываются статистика данных, реальное количество данных и т.д. Асимптотика вообще может не отражать реальное положение дел.

                                                                            Может не отражать. А может и отражать.

                                                                            Рядом со мной сидят веб-программеры, которые одну функцию в одном внутрифирменном сервисе реализовали с квадратичной сложностью, когда данных в базе было мало и всё летало и так. Через год, когда база выросла вдесятеро, а время обработки данных, соответственно, в сто раз, — на этот их сервис чертыхался весь отдел. А уже поздно: на ту структуру данных, которую они выбрали, всё в сервисе завязано, переписывать можно только всё целиком.

                                                                            Естественно, что "реальное количество данных и их статистику" на этапе разработки сервиса предсказать было невозможно: мы и сами тогда не знали, сколько и чего мы в их базу будем пихать.
                                                                            +6
                                                                            Так-то если там убрать O(...), то придется все домножать на константу, которая может быть сколь угодно большой…
                                                                            Простой пример: можно отсортировать массив из 3-х элементов за честных 1 n^2 операций (т.е. за 9 операций сравнения), а можно линейно за 100 n операций (т.е. за 300 операций сравнения)...
                                                                              –1
                                                                              Вы это мне отвечаете? Вы это лучше напишите человеку, который предложил формулу сравнения O(..) выше. Потому что константа играет в любом случае, есть O() или нет.
                                                                            +2
                                                                            А ничего, что это асимптотические оценки и алгоритм со сложностью O(N) может быть хуже, чем O(N*logN) на характерной для задачи размерности данных? А если у двух алгоритмов одинаковая O-сложность, то какой из них предпочтительней? Если программист — программист, то он знает, как алгоритмы грамотно сравнивать. Если программист — дилетант от программирования, то он берет решение наугад, как привык или как посоветовали.
                                                                    +5
                                                                    Думаю, разработчику очень полезно хорошо представлять как пишутся алгоритмы, какие бывают структуры, как они работают, наверное даже без нюансов реализации, т.е. ему не нужно уметь написать реализацию на листочке, но иметь представление важно для абстрактного представления как работает то, чем он пользуется. Для 80% (цифра взята из закона Парето) случаев вообще нечего такого не понадобится (по ощущению же это цифра еще больше, может быть 95% для рядовой разработки), но зато оставшиеся случаи потребуют от разработчика хорошего понимания как работают его инструменты, чтобы сделать правильно/быстро/разобраться с проблемой. Вот здесь-то непонимающий разработчик и потратит 80% своего времени (опять смотрим на Парето) — на что будет потрачено это время? 1) Разработчик всё-таки разберется как что устроено 2) будет пытаться обойти проблему в поисках на стековерфлоу рабочего решения. Как можно догадаться, первый вариант быстро перейдет из непонимающего в понимающего, второй же скорее всего всегда будет пользоваться вторым способом. Отсюда можно сделать вывод, что важно не столько понимать все инструменты, которыми ты пользуешься (а все знать невозможно), но быть мотивированным на их исследование.
                                                                      +2
                                                                      Вы (автор статьи), возможно, имеете ввиду то, что в большинстве отраслей и для большинства задач они не нужны.

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

                                                                      А так, согласен с Вами. С точки зрения практики — зачем досконально знать алгоритмы в прикладных задачах? Это вдоль и поперек изученная теория, прекрасно (хотелось бы верить) реализованная в готовых библиотеках. Например, у JAVA таких библиотек огромное количество.
                                                                        +2
                                                                        Вот да. Теорию и я люблю и трачу на это все свободное время. Но практика и рынок диктую другие правила.
                                                                          +11
                                                                          Вы просто находитесь в части рынка, в которой умение писать алгоритмы, которые лазят по графам и деревьям — это неважно.

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

                                                                          Так что "практика и рынок", если вам нравятся работы такого типа, диктует противоположное.
                                                                            +1
                                                                            Согласен. Я поделился видением со своей колокольни, надеюсь оно будет полезно коллегам.
                                                                        0
                                                                        Нужно ли кому-то что-то знать больше в его профессии?
                                                                        1) Если подумать, почему бы и нет, любые знания всегда хорошо, особенно близкие — буду расти как специалист.
                                                                        2) Но с другой стороны, если я 1С ник, нафига мне машины Больцамана… учиться ловить драконов можно всю жизнь но нафига.
                                                                        3) Получается, нужно плясать от смысла, какую задачу я хочу решить, что я планирую?
                                                                        4) А откуда я знаю что я буду делать завтра? Метеорит упадет и все. Кому нужен этот 1С. Но так как это маловероятно, я буду предполагать что вероятно.
                                                                        5) А вероятно, может быть много чего, жизней не хватит. Все равно цель то не познание вероятности, а максимальный результат от моей деятельности рассчитанный вероятностно. Я же не рассчитываю всю жизнь за учебниками просидеть.
                                                                        6) Похоже цель — деньги, семья, самореализация, отдых и т.п ну да да вот оно и чтобы стабильно и уверенность в завтрашнем дне.
                                                                        7) Так, получается меня толкает на все это экзистенциальный страх неизвестного.
                                                                        8) Если это так то мне просто нужно убрать страх и мне будет хорошо. Можно попробовать химически с помощью там всяких веществ.
                                                                        9) Не ну, вещества это все равно не то, это просто бегство. Вот хочу как у Васи. Я считаю Васю успешным — личностью.

                                                                        Чем отличается личность от индивидуальности? Тем что первая нашла свои машины больцмана или свои рецепты для борьбы со страхом, который никогда не пропадает заставляя нас копаться глубже, так как будущее все равно неизвестно, но благодаря которым, мы не цепенеем как пенсионеры перед смарфоном
                                                                          –1
                                                                          Согласен. Себя нужно научиться уважать и понять, что важное в жизни — устроено просто :-)
                                                                            +3
                                                                            От невозможности определить реальность математически абстракциями и вероятностями (только потому что они не знают че так тоже можно :-) ), многие прибегают к гадалкам и шоу эксрасенсов. Тоже борются с экзистенциальным страхом. Однако, если мы задумаемся, то все важные вещи в нашей жизни были совершенны иррационально.

                                                                            Случайные встречи, случайные связи. Математика это не устраивает — потому что рандом ненадежно, он он все равно вынужденно руководствуется внутренним чутьем. Это в нас как то заложено — магия эта.
                                                                            Касаемо этого, для меня неожиданно, в другом ключе открылся смысл магического мышления,, — определенного дедушкой Фрейдом в "татеме и табу".


                                                                            Монтировал вчера эту лекцию, и мне понравились несогласия с дедушкой Ф.)
                                                                        +13
                                                                        Уважаемые читатели!

                                                                        Было бы обалденно, если бы кто-нибудь рассказал о своих кейсах из рабочей практики. Речь не о том, что они "развивают мышление". Это бесспорно. Расскажите случаи, когда вам действительно очень помогло знание алгоритмов — насколько удалось поднять производительность/сэкономить ресурсов и т.п.

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

                                                                        В условиях хронического недостатка времени приходится делать выбор в пользу развития прикладных знаний.
                                                                          0
                                                                          у меня был кейс, один за 15 лет :-)
                                                                            0
                                                                            А в какой области Вы работаете и какие задачи обычно решаете/решали?
                                                                              +1
                                                                              Мы делали рекомендательную систему и кластеризовали каталог товаров. Много математики, чуть меньше алгоритмов — но классические не работали на больших данных, пришлось копать глубже и переделывать на MapReduce :-) Вот ссылочка.
                                                                            +6
                                                                            Кейс — замаскировать url. Впрочем, я фронт-эндер, задача была не моя, но я помогал решать. Пока бэк-энд пытались придумать супер-убер архитектуру хранения с очисткой старых данных из бд и id, я просто предложил воспользоваться обратимыми алгоритмами хеширования.

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

                                                                            Вообще часто замечаю, что последнее время простенькие задачи пытаются решить сотней-другой гемов (gem), парой БД и диким оверхедом, вместо того, чтобы немного подумать и сделать простое, быстрое и изящное решение. Не то, чтобы не знали алгоритмов, просто забыли и отвыкли их использовать. Слишком уж редко нужно применять в реальности, что невольно первыми в голову лезут идеи найти библиотеку.
                                                                              0
                                                                              Еще один кейс был — хранить большое количество чисел (посещал-не посещал). Покуда это нужно было хранить для каждого пользователя по-отдельности, хранить влоб отвратительная идея

                                                                              Не подскажите ваш вариант реализации этого кейса, хотя бы в общих чертах?
                                                                              +1
                                                                              Думаю, здесь нельзя разделить на такой/нетакой кейс. Конечно, если говорить о кандово-математическом процессе создания алгоритмов, то думаю разработчик который не занимается этим непосредственно может и обойтись без таких знаний и умений. Однако, если говорить о представлении того как работают те алгоритмы и структуры, которыми ты пользуешься, то тут совсем другая ситуация. Потому что каждый раз используя что-то из стандартной библиотеки ты можешь сделать это осознанно, выбирая этот способ и понимая, что за собой это может повлечь, или просто потому что обычно делают так.
                                                                                +12
                                                                                Года три назад, делал систему автоматического определения оптимального передвижения техники по корпусу во время технического обслуживания электролизеров на алюминиевом заводе. По большому счету это NP задача, но она была сведена к достаточно приемлемому алгоритму на базе алгоритма Дейкстры — поиска кратчайшего пути в графе. Работает очень быстро. Так получилось, что из всей команды опыт в алгоритмах был только у меня и делал эту задачу соответсвенно один.

                                                                                Там же занимался базами данных и понимание сложности очень помогало при профилировании запросов к базе / переписывании меделенных sql-запросов.

                                                                                Сейчас на текущей работе участвую в разработке WebGL-приложения. Не сказать, что каждый день используются какие-то хитрые алгоритмы, в основном математика, но буквально вчера коллега реализовал дельта-кодирование вершин, что позволило сэкономить объем передаваемых данных на 30%. Алгоритм простой, но не зная его не получилось бы экономии трафика.

                                                                                Еще друг показывал тестовое задание, которое он решал — по сути это быстрый саггестер для заданного набора строк. Прямолинейное решение O(n) с использованием сбалансированного дерева O(log n).

                                                                                В общем, мое капитанское мнение такое. Не зная алгоритмы можно кодить и кодить довольно хорошо. Но зная алгоритмическую базу, математику, открывается абсолютно новый класс задач, которые программист без профильных знаний решить, увы, не сможет.
                                                                                  +1
                                                                                  Спасибо за кейс!

                                                                                  По поводу нового класса задач идея такая. Время у всех катастрофически ограничено. И ежедневно (а то и чаще) возникает вопрос "что учить, куда развиваться?" И выбор — либо углубиться наконец-то в алгоритмы, либо изучить что-то новое в прикладном плане.

                                                                                  Новый класс задач открывается и при изучении алгоритмов, и при изучении новых прикладных методов (например, новых языков программирования или баз данных).

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

                                                                                  Наверное, так.
                                                                                    +1
                                                                                    Похоже что знание алгоритмов вероятнее всего пригодится при написании специализированного софта. И мало вероятно в задачах "запилите мне сайтик/магазин" (если конечно не грезить хайлоадом)
                                                                                    +4
                                                                                    я сейчас переписываю систему, которая ищет объекты в базе в заданном радиусе от пользователя.

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

                                                                                    Новая версия: выгрузить все гео-объекты в память, положить в RTree, искать в нем. Время сократилось до 0.5мс

                                                                                    не всегда нужно знать, как все работает внутри, но было бы неплохо знать о существовании альтернативных алгоритмов
                                                                                      0
                                                                                      1) В базе использовались индексы?
                                                                                      2) Количество объектов какое?
                                                                                      3) Как часто меняются объекты?
                                                                                        0
                                                                                        конечно, индексы использовались, но все в индекс не запихнешь
                                                                                        ~250к
                                                                                        почти не меняются, иногда добавляются новые, сразу после добавления вероятность изменения больше
                                                                                          +1
                                                                                          А что за база?
                                                                                          С таким временем ответа не уверен, что индексы были задействованы ил были эффективны.
                                                                                          В SQL Server есть geospatial indexes, те же самые RTree.

                                                                                          Если встроенных в базу нет, то имеет смысл свой аналог сделать, дописав в каждой вершине индекс "области" и сделать обычный индекс по областям.
                                                                                            0
                                                                                            postgres, скорее индексы были не эффективны
                                                                                              +1
                                                                                              http://postgis.net/ не использовали?
                                                                                                0
                                                                                                где-то использовали, но точно не в этом месте)
                                                                                                  +1
                                                                                                  создал постгисовский идекс на тестовой базе, простой запрос типа

                                                                                                  select count(*) from geo_table where ST_DWithin(geo_point, ST_Point(user_lng, user_lat)::GEOGRAPHY, 25000)

                                                                                                  выполняется 12мс, с десятком джойнов будет значительно медленнее
                                                                                                    +2
                                                                                                    "Значительно" это сколько? Еще 10мс? Все равно лучше, чем 250.
                                                                                                    И зачем вам десяток джоинов?
                                                                                                      0
                                                                                                      лучше, конечно, чем 250, но все равно в памяти быстрее, да и rtree-либой пользоваться намного проще
                                                                                                      зачем — потому что база большая, нужно кучу инфы собрать
                                                                                                        +4
                                                                                                        А это уже неважно. Все что меньше 100мс для пользователя моментально. При этом база масштабируется получше.

                                                                                                        База может и большая, но для вывода списка ближайших объектов нет необходимости делать 10 джоинов, даже два джоина для такой задачи — перебор.

                                                                                                        rtree-либой пользоваться намного проще

                                                                                                        Проще, чем дописать запрос к базе? Простите, но не верю.
                                                                                        +2
                                                                                        Как-то раз возникла задача попарного сравнения некоторых объектов и поиска определенных пар, сложности, соответственно, О(n^2). Т.к. количество объектов было неприлично большим, то решение в лоб работало слишком медленно. Пораскинув мозгами, сделали вывод, что объекты можно не сравнивать после их получения, а построить нужные пары сразу. Казалось бы, задача свелась аж к NP-полной, но на многих кейсах ускорение было с десятков минут до нескольких секунд. Само решение опирается на Boolean SAT. Где б мы были без теоретической подготовки...
                                                                                          –1
                                                                                          Классный кейс. А мы прикрутили в этом случае LSH.
                                                                                            +1
                                                                                            У нас пары могут состоять из разных объектов. К примеру, как элементы паззла — чтобы проверить, подходят ли друг другу кусочки, нужно вот прям взять их и попробовать соединить. Если все сошлось — сохраняем, если нет — идем дальше. Вот только в нашем контексте в итоге оказалось, что можно сгенерировать не отдельные элементы, а сразу все пары, без дальнейших проверок.
                                                                                        +9
                                                                                        У меня был прикольный случай. Я в 1996-2001 сделал стартап по написанию транслятора из C в Verilog ( https://en.wikipedia.org/wiki/C_Level_Design ), в нем бОльшая часть кода — это всякие алгоритмические преобразования деревьев и графов, все на С++. В некоторый момент я нанял одного товарища, начинающего Java-программиста, писать GUI. К коду транслятора как такового товарищ не прикасался, и когда я через пару лет как-то стал говорить с ним на абстрактные темы, я столкнулся с тем, что он был свято уверен, что я просто использую какой-то "компиляторный API" написанный другими. Конечно, есть всякие вспомогательные тулы от других вендоров (Yacc, Lex, лицензируемые фронт-энды), но они в таких проектах — это типа 5% кода, а самые интересные алгоритмы по работе с структурами данных нужно самому придумывать.

                                                                                        Или например — в 1991-1993 работал в компании в области Optical Character Recognition (распознавание текстов). Там тоже куча алгоритмов самого разного типа — анализ топологии (topological feature extraction) например.

                                                                                        [Сейчас из софтверного инженера стал хардверным инженером по верификации микропроцессора — тут другие проблемы]
                                                                                          +2
                                                                                          Был довольно простой кейс (C#, WinForms). Дерево с фильтром. Если пользователь что-то вводит в фильтре, то остаются только элементы, в названии которых есть такой текст. Остальные скрываются (кроме родительских групп — чтобы было видно структуру дерева). Элементы хранятся в виде обычного списка, у элемента есть его ID и ID его родителя (если не корневой).
                                                                                          Потребовалось вручную просчитывать состояния чекбоксов (3 состояния), т.к. нужно было, чтобы когда пользователь отмечал чекбокс, то отмечались только видимые элементы, а когда пользователь снимал чекбокс, то снимать со всех элементов в том числе со скрытых фильтром.
                                                                                          Делалось это очень просто — в цикле/рекурсии, бегая по списку в поисках родителей/детей для вычисления состояния чекбокса.
                                                                                          Всё работало замечательно пока в дереве были тестовые данные (100-200 элементов). Но когда стали отображаться реальные данные (6000-7000 элементов), то пересчёт чекбоксов стал занимать 300-400 мс, что непростительно долго для простого нажатия на чекбокс.
                                                                                          Переделал пересчёт с использованием хэш-таблицы (HashSet в .NET) — перед рассчётом состояний чекбоксов сначала делался один проход по списку элементов и составлялись хэш-таблицы кто чей родитель и дочерний элемент, кто показывается а кто скрыт фильтром и т.д.
                                                                                          В результате без изменения остального алгоритма время сократилось с 300-400 мс до 1-3 мс.
                                                                                          Кейс не совсем конечно на знание алгоритмов, и даже наверное не на структуру данных, а скорее просто на понимание как это устроено. Но тем не менее.
                                                                                            +7
                                                                                            Расскажите случаи, когда вам действительно очень помогло знание алгоритмов

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

                                                                                            Определение стартового сигнала (писк примерно известной частоты и длительности) в оцифрованном звуке с микрофона.

                                                                                            Система рекомендаций. Есть длинный список товаров с разными признаками, длинный список пользователей с историей (кто какие товары покупал) и функция похожести одного товара на другой (по признакам товара). Реализация в лоб (сравнивать всех со всеми) дохнет при росте размера списков, потому что O(N^2).

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

                                                                                            Кажется, что это стандартные задачи и для них есть готовые решения, но на практике получалось что ни одно из них не подходит (не тот язык, слишком тяжёлое — много зависимостей, не хватает гибкости, слишком сложное — долго разбираться, лицензионная чистота и так далее).
                                                                                              +6
                                                                                              Например, буквально в пятницу писал мутную структуру данных, что-то вроде бинарной кучи, но и еще с протуханием верхнего элемента. То есть один поток пихает постоянно данные в эту кучу, а другой ожидает готового элемента из этой кучи, то есть по ключу меньшего и еще и протухшего. В стандартой библиотеке Java такого не нашел, была только DelayQueue, но это сильно проще, чем мне нужно было.

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

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

                                                                                              Так же я абсолютно всегда смотрю в код реализации сктруктур/алгоритмов перед их использованием. И знание и понимание каких то базовых вещей мне крайне помогает.

                                                                                              Это то, что я сейчас так быстро припомнил, но алгоритмы вообще абсолютно везде. От чем ConcurrentHashMap отличается от HashMap внетри в Java до того как работает Paxos.
                                                                                              +3
                                                                                              Знать — конечно нужно. Но дальше все зависит от языка. На бейсике (это я так называю похапе и прочие скрипты) — глупо не использовать стандартные функции, выполняющие стандартные алгоритмические действия, типа сортировки или работы со строками и тд, так как если выбран бейсик изначально и осознанно — то выбран скорее всего не из-за скорости выполнения программы, а из-за быстроты разработки и широким кругом вхождения (меньше ЗП на программистов). А если скажем речь идет про написание прошивки для микроконтроллера — то тут уже стоит тысячу раз подумать — юзать готовые функции или же написать свой велосипед, который учтет некоторые программно-аппаратные особенности реализации девайса в целом.
                                                                                                0
                                                                                                Вух [Глубокий выдох], спасибо тебе автор за такие слова, успокоение-то какое.
                                                                                                  +22
                                                                                                  А потом получается, что простейшая задача решается с помощью трех десятков слабо совместимых между собой библиотек в соответствии с принципом чайника, из-за чего умудряются тормозить даже на ферме из 20 блейдов не самых чахлых конфигураций. Зато с реактом, редисом и монетизацией через микротранзакции, все как у больших мальчиков.

                                                                                                  До сих пор ситуация в мире разработки напоминала мне *вырезано ибо политика* — любую мало-мальски сложную проблему пытались залить процессорными мощностями, памятью и каналами данных. Они росли и было круто. Теперь они расти перестали и снова пора начинать думать, отсюда все больше требований к математике среди девелоперов.

                                                                                                  Да, конечно, можно и за отпуск собрать мапредьюс в облаке из грязи и веток, однако как же удивляется разработчик, когда понимает, что накладываемый такими решениями оверхед настолько велик, что очищенная от него задача спокойно выполняется на втором пентиуме.
                                                                                                    –3
                                                                                                    Не, я как раз писал акцентируя на поиск простых решений!
                                                                                                      +6
                                                                                                      Простое решение — собрать мапредьюс из грязи и веток и залить процессорами. Развернуть все абстракции, вытащив наружу только то, что реально нужно — решение сложное.
                                                                                                        –4
                                                                                                        За такие "простые" решения — у нас принято брать биту в начале поста и лечить :-)
                                                                                                          0
                                                                                                          Апологеты MVP с вами радикально несогласны. Впрочем, я тоже, так как вначале должен быть proof of concept, а для него допустимо использовать любые средства, вплоть до вероятностных алгоритмов.
                                                                                                            0
                                                                                                            То есть не для пруф оф концепт вы не будете использовать быструю сортировку (типичный случайный(вероятностный) алгоритм)?
                                                                                                    +8
                                                                                                    Положительнейший эффект российского образования — это получение навыка думать. Казалось бы, зачем кодерам все эти матаны, поверхностные интегралы и критерий Рауса-Гурвица. Очевидно, эти знания будут не нужны в 99% случаев. Дело не в знаниях, а в получении навыка поиска, понимания, отождествления связанных вещей и системного анализа. Знания оставлены в университете, навык сохранён и уже дальше развивается в ваших других областях. Люди, которые развивались в университетские годы по какой-то причине узко — будут такими же узко(лобыми) и на работе. На первой же нестандартной ситуации — пык-мык, не знаю, пойду домой. Или, например, нежелание понимать область коллеги по работе — "не, я узкий специалист". Университет (ну или то что вы причисляете к науке) от этого отучивает. Нисколько не ученых готовят университеты, а закаляют к дальнейшей эффективной жизни.
                                                                                                      +4
                                                                                                      Изучение матана и "навык думать" в общем случае не связаны.

                                                                                                      Или, например, нежелание понимать область коллеги по работе — «не, я узкий специалист». Университет (ну или то что вы причисляете к науке) от этого отучивает.
                                                                                                      Проводил собеседование десятков вчерашних студентов ведущих вузов. К сожалению универ не отучивает от такой модели. Непонятно за счет чего он должен отучивать.
                                                                                                        0
                                                                                                        А они как вообще, выпустились, с какими результатами, легко ли? Как экзамены сдавали, быстро или медленно готовились? Надо оценить, как человек проходил этот квест. Если это для него не квест, а каторга — ну что ж. Универ — отличный фильтр. Те, кто застревает в такой вот узкой модели — это (на моей памяти, сам собеседовал десятки) обычно такие ребята, которые ходят на все лекции и повторяют за профессором, а потом ещё и сдают на 4. Смышленые, скоростные — они иногда и профессора-то не видели до экзамена, но сдают с блеском, т.к. к вопросу подошли не зубрежкой и повторением, а собственным пониманием.
                                                                                                        –2
                                                                                                        А вот вопрос. Возьмем врачей. Одни изучают ухо, вторые — анус. На западе это разделение четкое и тебе просто не дадут лезть в ухо, если ты посвятил себя проктологии. И это правильно. А у нас как-то наоборот. Тебя учат всему, а потом сидит человек и тупит неделю в консоли юникс.
                                                                                                          0
                                                                                                          Вообще это одна из самых популярных баек. "На Западе" по некоторым параметрам ширина охвата покруче, чем у нас. Конкретно в сфере IT можно почитать рекомендации ACM/IEEE по содержанию вузовского образования. И надо иметь в виду, что ни в одном приличном вузе нельзя получить диплом, набирая курсы только в рамках major subject, всегда будут предметы общего характера или по дополнительной (minor subject) специализации.
                                                                                                            +3
                                                                                                            "На Западе" вузы, абитуриенты и работодатели уже начинают различать специальности "Computer Science" (т.е. наука) и "Software Engineering" (т.е. софтописательство), а "на Востоке" всё ещё мешают в одну кучу всё, где есть слово "computer" в названии.
                                                                                                              0
                                                                                                              А вы посмотрите на том же сайте рекомендации по изучению Software Engineering.
                                                                                                        +1
                                                                                                        Троллинг зачётный, но, судя по оценкам, не менее половины принимают вбросы (тезисы автора) всерьёз (которые поставили минусы). Нужна ещё шкала оценок качества троллинга, и тут — однозначный плюс.
                                                                                                          +5
                                                                                                          Непонятно, в чем суть такого троллинга. Автор понаписал глупостей, замусорил пространство хабра, на котором и так качественного контента не хватает, подтвердил стереотипы о программистах 1С и битрикса, которые и так интеллектуалами не слывут.
                                                                                                          Ну, может, немножко повеселился, да. А может, все-таки веселиться лучше идти на пикабу?
                                                                                                            0
                                                                                                            Ну зря так. Да, мы больше практики, много программируем, делаем 4 релиза в год. Но алгоритмы — учим, математику — любим, unix знаем на отлично на уровне C. Бигдата у нас тоже есть со сложной математикой, хайлоадом, java и Spark. Но пост о другом — о простоте и ограниченности времени.
                                                                                                            +1
                                                                                                            Спасибо! Если честно, задумка была просто поделиться опытом, плохим-хорошим, какой есть. Знание алгоритмов, истоков, отцов основателей, C, математики — безусловно, БЕЗУСЛОВНО нужно!!! Но не всем. Либо знай это хорошо, либо просто не лезь и не страдай комплексом неполноценности, пей пиво и используй готовое — и будешь полезен человечеству.
                                                                                                            +7
                                                                                                            Когда не пишешь нифига, знания не нужны. У меня друг (не программист вообще и не математик) сказал "зачем программировать, если все программы можно в интернете скачать?". Он просто не понимает, что такое программа, которой нет в мире и в которой всё есть.
                                                                                                            Я видел, как люди, знающие только регулярки, не могли исправить баги в своих собственных веб-приложениях, потому что там надо было знать грамматики и конечные автоматы, а у них мозгов хватило только на регулярки (уровень средней школы), которыми ничего не сделаешь.
                                                                                                              0
                                                                                                              Да, нужно постоянно писать код, согласен. Иначе наступает интеллектуальная импотенция и начинаешь бредить.
                                                                                                              +4
                                                                                                              Думаю, очевидно, что есть задачи в области программирования, связанные со знанием алгоритмов и оценкой их сложности и не связанные.

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

                                                                                                              Если задачи не связаны с алгоритмами, алгоритмы знать не надо. Тем не менее, это тоже программирование.

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

                                                                                                              Если задачи, связанные с алгоритмами, появляются в работе постоянно, алгоритмы знать надо.

                                                                                                              Также бывают задачи на нестандартные алгоритмы либо на нестандартное применение стандартных алгоритмов. Для таких задач алгоритмы знать надо, причем очень хорошо.
                                                                                                                0
                                                                                                                Вот. Имея базовые знания, тратишь недельку другую на деревья и потом аккуратно реализуешь. Вряд ли придется придумывать алгоритм — на них у ученых жизни уходили и дисеры. А вот найти готовый и знать где — разумно.
                                                                                                                +5
                                                                                                                ниже пример = 7000 долларов в месяц, переезд в штаты, возможно пересмотр зарплаты по результатам собеседования

                                                                                                                http://hh.ru/vacancy/15925548?query=%D0%B0%D0%BB%D0%B3%D0%BE%D1%80%D0%B8%D1%82%D0%BC%D0%B8%D1%81%D1%82

                                                                                                                значит спец в своей области востребован даже если это алгоритмы, и такая позиция не одна, математик вполне может получать больше среднего кодера. При ситуации в которой идет все большая специализация часть программистов медлено превращаются в роботов по набиванию кода.
                                                                                                                  0
                                                                                                                  В чем-то согласен… есть такое. Я хотел в посте лишь поднять важность прикладных знаний, дающих нередко 95% отдачи.
                                                                                                                    +3
                                                                                                                    На период работы, предшествующий переезду (время оформления документов для переезда в США) зарплата — 80,000-120,000 рублей в месяц. Начальная зарплата после переезда в США — $85,000 в год

                                                                                                                    Это оттуда же. Что-то мне подсказывает, что средненький фулстэк, который путает бинарное дерево с большим О в нотации второго закона Ньютона, может рассчитывать на большее. И в Москве, и в штатах. Это если речь о деньгах.
                                                                                                                      –1
                                                                                                                      Да, если порыться по американским вакансиям, то обычно там требования в стиле "experienced, independent, self-motivated developer with good сommunication skills
" плюс пару топовых технологий типа node.js, какой-неть nosql, которые учатся за пару вечеров.
                                                                                                                        +6
                                                                                                                        пару топовых технологий типа node.js, какой-неть nosql, которые учатся за пару вечеров.

                                                                                                                        Восторг.
                                                                                                                          +1
                                                                                                                          За пару часов, чего уж там.
                                                                                                                      +1
                                                                                                                      Иногда полезнее быть узкоспециализированным, но глубоким в своей специфике специалистом, иногда полезнее быть специалистом широкого профиля без особых требований к глубине познаний. И на всё это нужно время. И ответственность за выбор своей судьбы (ну, или какого-то отрезка карьеры) лежит на каждом человеке, не получится написать статью, которая позволит программистам сделать себе лоботомию и жить не напрягаясь по инструкции. Полезная статья в этой теме — это статья, предлагавшая бы критерии оценки «широты» и «глубины» специализации и ориентирования на текущем рынке по этим параметрам. А сферически в вакууме рассуждать о том, кем лучше быть — пекарем или трактористом, — бессмысленно.
                                                                                                                        0
                                                                                                                        Ну мы не в сферическом вакууме рассуждаем же. Каждый где-то работает, что-то кодит, что-то изучает, что-то зарабатывает. В посте хотелось поднять важность с одной стороны прикладных знаний, а с другой — подчеркнуть ограниченность времени и сил. Когда-то я для себя решил так: разберись с основами, с принципами — дальше будет проще:

                                                                                                                        • Таненбаум: железо, ОС
                                                                                                                        • Стивенс, Вахалия: юникс изнутри
                                                                                                                        • Стивенс, сетевые протоколы
                                                                                                                        • С
                                                                                                                        • java, с++ чтобы быстро что-то поднять из готового
                                                                                                                        • php,python — чтобы в вебе развернуться
                                                                                                                        • математика, базовое машиное обучение, матстат, тервер — ну чтобы было лучше понятно что происходит
                                                                                                                        • горстка придуманных человечеством алгоритмов, ну чтобы не придумывать заново

                                                                                                                        А дальше — практика, практика...
                                                                                                                        +1
                                                                                                                        Саш, недавно была статья в тему — Чем плохо быть fullstack-ом. Я думаю, что ты примерно про то же самое пишешь. Хорошо или плохо — очень зависит от контекста, условий, окружения, требований.
                                                                                                                          0
                                                                                                                          Ну у меня детское желание — найти серебряную пулю :-)
                                                                                                                            0
                                                                                                                            Пулю против чего?
                                                                                                                            • UFO just landed and posted this here
                                                                                                                                0
                                                                                                                                Продаются наборы. Там ещё святая вода в бутыльках и чеснок.
                                                                                                                            +2
                                                                                                                            По мне там самый лучший коммент от MTonly https://habrahabr.ru/post/278467/#comment_8793335
                                                                                                                            Про Full StackOverflow developer. Хохотали час, не уточняйте детали, пожалуйста :-))
                                                                                                                            +5
                                                                                                                            Сама постановка вопроса, какая-то странная. Конечно надо алгоритмы знать.
                                                                                                                            У нас в чисто финансовой(!) компании используются следующие алгоритмы:

                                                                                                                            • Имитация отжига;
                                                                                                                            • Монте-Карло;
                                                                                                                            • Стеганография в частотной и пространственной области;
                                                                                                                            • SIFT-дескрипторы;
                                                                                                                            • Перцептивные хеши;
                                                                                                                            • Т