Меня очень забавляет маниакальное желание некоторых разработчиков писать максимально производительный код во всех задачах. И это я считаю даже более вредной привычкой, чем написание быдлокода и сейчас постараюсь объяснить, на чем основано мое мнение.
Первое, это время. На создание более производительного решения необходимо на порядок больше времени, что совершенно не выгодно для бизнеса. А учитывая, что мы живем во времена, когда капитализм правит баллом, это определенно плохо. Еще худе ситуацию делает тот факт, что зачастую это является абсолютно бесполезной тратой ресурсов (времени и денег), потому что в этом нет никакой нужды. Конечный пользователь может даже не заметить прирост в скорости вычислений в несколько секунд, если весь процесс занимает минуту. Да даже если бы вычисления начали выполняться в разы быстрее, далеко не факт, что это стоит затраченных усилий.
Следующий главный минус – это уменьшение читаемости кода. Зачастую простое решение в лоб, является вполне оптимальным по производительности и при этом остается очень легко поддерживаемым, потому что код достаточно прост и понятен на интуитивном уровне. Однако, если мы стремимся все оптимизировать, это с большой долей вероятности приведет к усложнению алгоритмов вычислений, и другому разработчику или даже тебе через полгода придется несладко разбираться в запутанных решениях. А внесение правок (которые скорее всего будут) потребует еще больше сил, ведь даже небольшие изменения в сложном алгоритме могут быть далеко не самой простой задачей. А это очередной удар по бизнесу – еще больше съеденных ресурсов без видимой выгоды.
При этом, современных компиляторы показывают себя далеко не плохо в плане оптимизации производительности и могут обходить большинство узких мест самостоятельно. А вот хитроумные манипуляции могут произвести прямо противоположный эффект. Поэтому нужно всегда лишний раз задуматься, а действительно ли нужна оптимизация?
К решению данного вопроса я всегда подхожу достаточно просто. На начальном этапе разработки я использую наиболее прямолинейный и простой подход для решения задачи, при этом не забывая о достаточно хорошей декомпозиции на отдельные методы. И только после получения минимального жизнеспособного продукта и демонстрации его заказчику при необходимости приступаю к поиску способов увеличения скорости работы. При этом, декомпозиция позволяет достаточно просто заменять один алгоритм на другой для сравнения результатов. Но достаточно часто получается так, что это даже не требуется, скорость вполне устраивает заказчика и я могу спокойно переходить к следующим задачам. Руководство довольно, а код остается достаточно простым и лаконичным.
Таким образом, я хочу лишний раз напомнить, что оптимизация ради оптимизации – очень плохая практика. Получается, что работодатель должен оплачивать твое желание потешить свое самолюбие и ждать пока ты напишешь свой идеальный код вместо того, чтобы решать проблемы заказчика? Это не выход. Чем быстрее будет решена поставленная задача – тем лучше для бизнеса. Оптимизируй только тогда, когда это действительно нужно.
Большое спасибо за прочтение! Пожалуйста, поставь лайк и подпишись на канал, чтобы не пропустить свежие статьи. Этим ты очень поможешь развитию блога!
Также рекомендую прочитать статью Как обучаться быстрее