Я часто слышу о том, как важно уметь решать сложные алгоритмы в программировании. На собеседованиях могут спрашивать про алгоритмы с графами и т.д., которые в работе встречаются довольно редко.
В современных проектах для среднестатистического бизнеса условно сложнее циклов может ничего не встретиться в коде. При этом продукт будет один из лидеров в своем сегменте и пользоваться успехом у пользователей. Да кода много, но много ли сложных алгоритмов? Нет.
Я говорю про часто встречающиеся проекты, которых большинство: личные кабинеты, CRM, системы учета, мобильные приложения, интернет-магазины, сайты, программы автоматизации и т.д. То есть то, что покрывает огромную часть разрабатываемого софта.
Сегментов, где нужны "олимпиадники" и сложные алгоритмы, очень мало. Гораздо больше проектов с обычным софтом.
Дело в том, что для разработчиков все написано и придумано. Нужно знать, где искать нужную информацию и уметь грамотно ей пользоваться. Например, нужно что-то зашифровать и расшифровать, пожалуйста, используй инструмент. Нужны какие-то манипуляции с массивом, зачем самому писать алгоритм, используй готовые функции. Подавляющее большинство алгоритмов уже написано и зашито в готовых функциях языка и библиотеках.
Более того, можно написать свою нейронную сеть, не написав при этом ни одной математической формулы! Неожиданно. Просто используя готовую библиотеку на Python Keras.
На мой взгляд, важнее продукт, который должен получиться, для этого мы и пишем весь код, разве не так? Крайне важна скорость разработки, возможность ее легкой поддержки и расширяемости, а это совсем не про написание алгоритмов.
Подход
Я считаю, что наиболее важным является сам подход к задаче. То есть придумать каким методом, какими инструментами мы будем решать задачу. Где мы можем срезать углы.
Пример
На веб странице нужно сделать сортировку перетаскиванием мышкой. Нашли плагин, подключили. И новые отсортированные данные необходимо как-то передавать на сервер. Для этого нужен код на JavaScript. Начали искать в документации плагина, оказалось, что нет описания, как получить новое состояние сортированных плашек. Мы помучались около часа, написали в поддержку. Это прямой подход, и, по сути, верный, но так как ситуация тупиковая, я решил его изменить. Плагин меняет разметку HTML в форме. Мы можем подложить в каждую плашку скрытое поле input в виде элемента массива. И в форме данные летят именно в том порядке, в котором плагин выстроил в HTML после перетаскивания. Это решает нашу проблему, при этом в данном подходе ноль написанных нами строчек кода на JavaScript.
Итого поменяв подход, нам даже не пришлось вообще писать алгоритм. Понимаете?
Это сильно сэкономило время разработки и скорость работы программы.
Нужно быть аккуратным в выборе подхода и инструмента. Т.к. ошибка может оказаться болезненной: если будет много надстроек, сложно будет потом их просто убрать.
Другими словами, программист, который подберет хороший подход, выиграет у программиста с плохим подходом, но хорошим локальным алгоритмом.
Подход важнее алгоритма, но есть еще что-то важнее подхода.
Вроде очевидная вещь, но не всем почему-то.
Понимание
Понимание задачи важнее подхода, нужно хорошо вникнуть в суть задачи. Нужно понять какую проблему мы хотим решить. Почему мы делаем эту задачу. Чего хочет бизнес? Что нужно получить в результате, и т.д. И может выйти так, что сама задача отпадет, и на ее месте появится другая, которая решит проблему быстрее. Или можно использовать другие доработки. Или решить задачу сторонним софтом. Понимаете?
Если у программиста нет четкого понимания задачи, он уже не может правильно написать код. И ему не поможет ни подход, ни алгоритм.
Пример
При постановке задачи говорят, что в Экселе есть данные, нужно написать код на Python, что бы сделать сводные данные. Спрашиваем, как часто это нужно делать? Сказали что очень редко. Открываем Эксель и просто делаем сводную таблицу за 5 минут и отдаем обратно. Специалист, который не вникнул в задачу, просто возьмет и будет ее делать. Потратит кучу драгоценного времени программиста.
Еще пример
Нужно сделать копию нашего продукта, где нужно посчитать данные, которые выбиваются из общего продукта. Делать несколько копий и поддерживать их в актуальном состоянии очень и очень затратно, данные должны сходиться. Но задача звучала строго именно так. В ходе обсуждения данной задачи выяснилось, что достаточно одного небольшого отчета и еще одну таблицу данных. Один раз написали дополнительный функционал в основном продукте и забыли.
Повторюсь, понять, что от тебя хотят на выходе крайне важно. От этого зависит успешное выполнение. Нужно уметь язык менеджеров переводить в язык айтишников.
Итоги
Важные слои написания кода от самого важного, к менее важному:
Понимание
Подход
Алгоритм
Часто бывает наоборот. Пишем алгоритм, что-то не получается. Понимаем, что подход не очень, меняем подход. А в итоге вышло, что на выходе от нас ждали вообще другого.
Пойми задачу. Найди подход решения. Пиши алгоритм.
