Найти кратчайший путь. Нужна ли программисту математика?

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

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

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

Дать в системе строить карту/схему коридоров и лифтов/пандусов, по которым пылесос может передвигаться между этажами.

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

Самое интересное, что во время решения данной задачи на математическую часть мне вообще не пришлось потратить время.

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

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

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

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

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

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

Разработчики, решающие математические задачи, должны либо уже быть в теме, либо быть способными быстро обучаться.

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