Порой наши попытки что-то оптимизировать и принести пользу бизнесу оборачиваются нам дополнительной работой, а бизнесу - убытками. Оптимизация - модификация системы для улучшения её эффективности.ИлиОптимизация - приведение программы от состояния «не устраивает», в состояние «пойдёт», по параметрам производительности. Следует помнить, что состояния «хорошо» мы никогда не добьемся. Так как клиент всегда будет не доволен. А вот состояния «пойдёт» - можно добиться почти всегда.   Производительность может измеряться как в количестве потребляемых ресурсов приложением, например сколько оно потребляет ОЗУ, насколько сильно напрягает CPU, или вообще, специфичной, для домена, метрике. Например: максимальное количество выданных займов в одну единицу времени.Или сколько мы можем обрабатывать заказов в пиковые праздничные дни.   Это критическая часть кода, которая потребляет значительное количество ресурсов. Будто временны́х или ресурсов самой машины, на которой запущено приложение. Часто бывает и то и другое. Обычно проблемы в рамках всего приложения создают именно bottleneck'и. Чтобы их отследить, необходимо использовать профилировщики и / или бенчмарки. Отличными примерами bottleneck'ов являются любые http запросы и ожидания ответа от каких-то внешних (и внутренних порой!) сервисов. Работа с базой данных, например вызов хранимой процедуры или выполнение сложного запроса. Если как-то на работу базы мы можем повлиять, то на ожидания ответа от другого сервиса - обычно не можем. Оптимизация - это далеко не про создание перфоманса из воздуха. Зачастую приходится выбирать из нескольких зол. Например:Добавить cache и не слать запросы в базу данных, тем самым избавляясь от бутылочного горлышка и разгружая базу. Взамен получить ошибку переполнения кучи, если данных, которые мы закэшировали оказалось, неожиданно, слишком много. Конечно, обычно можно настроить размер cache, но увеличенное потребление ОЗУ все-таки может стать проблемой. Tradeoff - выбор самого оптимального, в рамках вашего контекста, решения. Контекст может быть таким, что необходимо уменьшить потребление ОЗУ у сервиса, при этом про увеличение производительности может речи не идти. Если требования по оптимизации неизвестны - необходимо их узнать.Иначе уже на этапе анализа задачи вы совершите свою первую ошибку. Желательно никогда.   Заниматься оптимизацией может заставить только бизнес и только когда уже есть корректно работающий функционал.   А если все-таки такой запрос от бизнеса пришёл - необходимо помнить следующее:   Я на это намекал, когда писал про tradeoff. Оптимизировать можно бесконечно и что угодно. Стоит ли оптимизировать несколько дней определённый участок кода ради прироста в несколько миллисекунд?Ответ: да. Если этого требует ваш бизнес.В остальных случаях не стоит.   Чтобы часто не задаваться вопросом: «А стоит ли этот код оптимизировать?».Необходимо знать, что именно необходимо оптимизировать.Возможно объект оптимизации находится в сервисе, которым занимается другой сотрудник. В таком случае, скорее всего, можно избежать работы полностью или частично. «Лучший код тот, который не был написан»  Пользоваться данным откровением из книги «Чистый код" вы сможете только в том случае, если вы знаете, какой результат вы хотите достичь. Проблема преждевременной оптимизации возникает тогда, когда вы хотите «сделать бизнесу хорошо», до того как он это попросил. Когда вы это делаете - вы уже нарушаете принципы YAGNI и скорее всего KISS. Следуя которому вы стараетесь писать максимально простой код. А оптимизация это зачастую не про простой код. Сложный код сложнее тестировать, поддерживать, а если этот код появился в результате попытки что-то преждевременно оптимизировать - то ещё и в разы дороже. Если не знать чего хочет бизнес и при этом заниматься преждевременной оптимизацией - можно расстроить как бизнес, так и коллег, которые будут тратить свое время, чтобы понять, почему «прод в огне». Бизнесу особенно обидно, потому что он хотел как лучше, а в итоге снова оказался недовольным.Поэтому необходимо помнить, что:   Если не нужно оптимизировать - не делай этого.Если делать то, чего тебя бизнес делать не просил - бизнес этого скорее всего не оценит.   И возможно, вы будете оптимизировать собственный код, который был написан при попытке «что-то преждевременно оптимизировать». Если три правила активно нарушать, то рано или поздно случится следующее:  Пишу код который иногда работает