Комментарии 15
Зависит от размера проекта и предметной области. Например, парсеры и компиляторы зачастую стоит оптимизировать
Ага, а потом прилетит SRE/DevOps, у которого будет зад в огне, когда увидит, что ради простоты , разработчик решил не батчами селекты/апдейты делать, а просто так, без оптимизаций, в результате чего простой не оптимизированный код насилует всю огромную таблицу с I/O 1,5 гиг в секунду
Тут вопрос не в новых задачах, а в том, чтобы не лезть в то, что уже принято и работает, до того, как это сами попросят. А Ваш пример принять не должны изначально, если только задача изначальная не была на 10 строк данных. А вот если была, тогда через какое-то время, при попытке загрузить кучу данные все будет очень медленно работать и вот тогда надо будет оптимизировать)
Заниматься оптимизацией может заставить только бизнес и только когда уже есть корректно работающий функционал
Бывает и наоборот, когда заниматься оптимизацией вынуждает функционал, уже некорректно работающий при возросшей нагрузке.
Дай мне мужество чтоб отрефакторить баги которые критичны,
дай мне смирение чтоб не трогать то что работает,
дай мне мудрость чтоб отличить одно от другого.
Изначально плохо поставлен вопрос. Любое изменение без цели несёт вред, повышает энтропию и приближает тепловую смерть вселенной. Заказчиком оптимизации выступает почти всегда эксплуатация, а не бизнес. Просто потому что мало где умеют считать стоимость инфраструктуры в разрезе сервиса/транцакции.
Нужна или нет оптимизация неплохо считается в деньгах. Например, если команда из 10 человек пишет сервис который занимает 1 сервер, разработка стоит дороже эксплуатации. А если сервис занимает уже 2-3 стойки, то зарплата разработки на порядок меньше расходов на инфраструктуру. Получается, что на начальном этапе развития сервиса на оптимизацию можно забить, что потом вылезет под нагрузкой. Это не отменяет, что разработка, в лице архитектора должна думать на шаг вперед, правильно строить архитектуру, выбирать стэк, ревьювить решения соизмеримо нагрузке планируемой.
То есть вы предполагаете выкатить в прод не оптимизированный код, дождаться когда юзеры начнут жаловаться на тормоза и отказы, чтобы менеджер пришел и сказал что очень надо оптимизировать и только потом начать думать как все это заставить работать у реальных пользователей, а не у себя локально?
Этот тезис про преждевременную оптимизацию только как отмазку используют.
Можно заранее понять, что именно нужно оптимизировать, по крайней мере многие места в которых оптимизация нужна.
Не надо такое советовать. Эту статью прочитают сотни недомидлов и радостные продолжат говнокодить ещё больше.
Думаю, что говоря о преждевременной оптимизации, обычно имеют ввиду не стандартные хорошо понятные способы написания оптимального кода, такие как запросы в базу батчами, кеширование приходящих из медленного хранилища ответов, ретраи запросов в ненадежные каналы, подбор подходящих структур данных и т.п. Всё это можно и нужно использовать, это можно предусмотреть и встроить заранее, но все это и не ухудшает архитектуру.
А когда говорят о преждевременной оптимизации, обычно имеют ввиду т.н. хардкорную оптимизацию, вроде прямого доступа к памяти в managed-языках, манипуляции указателями, патчи на виртуальные машины для применения нестандартных параметров, директивы компилятора для отключения проверок типизации, нестандартные приведения типов и пр. В особо сложных случаях крупные компании даже пишут свои компиляторы для интерпретируемых языков. Вот такие оптимизации уже имеет смысл применять только в тех случаях, когда это действительно нужно, и когда иными способами требуемого прироста уже не добиться.
Согласен. Думаю важно на берегу в команде договориться, что считать и самое главное что не считать преждевременной оптимизацией.
говоря о преждевременной оптимизации, обычно имеют ввиду не стандартные хорошо понятные способы написания оптимального кода, такие как запросы в базу батчами, кеширование приходящих из медленного хранилища ответов, ретраи запросов в ненадежные каналы, подбор подходящих структур данных и т.п
Какие-то вещи может не вывозить команда, просто вследствие недостатка квалификации.
Про преждевременность оптимизации я периодически слышу даже от джунов, пытающихся прикрыть перед менеджерами это популярной фразой свои откровенные ляпы. Ещё могут вернуть что-нибудь про business needs. Звучит смешно и грустно одновременно.
Помимо преждевременной оптимизации есть и преждевременная пессимизация -- когда пишется код, который заведомо хуже, чем он мог бы быть при приложении относительно небольших усилий.
Оптимизация - модификация системы для улучшения её эффективности.
Или
Оптимизация - приведение программы от состояния «не устраивает», в состояние «пойдёт», по параметрам производительности.
Оптимизация -- это улучшение системы по какому-то из заданных параметров (скорость, потребление памяти и т.д.) в ущерб другим параметрам (скорость, память, читаемость, сопроводимость, кроссплатформенность, и т.д.) Именно поэтому она является злом, хоть и вынужденным. Все остальное -- это рефакторинг (общее улучшение системы без особого ущерба отдельно взятым параметрам). Недостаток рефакторинга только в том, что он требует затрат, не привнося новой функциональности (но, как правило, затраты окупаются в долгосрочной перспективе).
Из-за того, что многие не понимают разницы и путают эти понятия, рефакторинга боятся так, как стоило бы бояться оптимизации. Как следствие -- вынуждены прибегать уже к вынужденному злу оптимизации в уже сильно запущенном случае.
Сразу вспомнилось выражение Д. Кнута: "Преждевременная оптимизация - корень всех зол". Но не все вспоминают контекст:
There is no doubt that the grail of efficiency leads to abuse. Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil
Иначе говоря, оптимизация зло - когда мы оптимизируем эти 3%. (Чем грешу порой и сам)
Ссылка на статью: https://cowboyprogramming.com/files/p261-knuth.pdf
del - не туда комментарий
Оптимизация или почему прод в огне