Преждевременная оптимизация — это процесс оптимизации кода или системы, который выполняется на ранних стадиях разработки, до того как будут понятно, где на самом деле находятся узкие места и насколько они критичны. Термин стал популярен благодаря цитате Дональда Кнута: "Преждевременная оптимизация — корень всех зол" (в оригинале: «Premature optimization is the root of all evil»).

________________________________________________________________________________________________
### Почему оптимизация может быть проведена раньше положенного?

1. Перфекционизм: Разработчики иногда стремятся написать идеально оптимизированный код с самого начала, стремясь к максимальной эффективности.

2. Навыки и привычки: Некоторые разработчики, особенно с опытом работы в системах, где производительность имеет приоритет, по привычке могут пытаться оптимизировать всё.

3. Ложные предположения: Интуиция или экспертное мнение могут подсказывать, что определённые участки кода могут стать узкими местами, даже если фактических доказательств этого нет.

4. Неопытность: Менее опытные разработчики могут переоценить или недооценить важность оптимизации на ранних стадиях.

________________________________________________________________________________________________
### Минусы преждевременной оптимизации:

1. Напрасные усилия: Возможно, значительное время будет потрачено на оптимизацию тех частей кода, которые на практике не будут узкими местами.

2. Сложность и запутанность кода: Оптимизация часто делает код более сложным, что затрудняет его поддержку, тестирование и понимание для других членов команды.

3. Увеличение количества багов: Сложный и оптимизированный код может быть менее устойчивым и более подверженным ошибкам.

4. Отвлечение от основной задачи: Вместо концентрации на основных функциях и разработке продукта, команда может быть отвлечена на оптимизацию.

5. Меньше времени на реальные улучшения: Фокус на раннюю оптимизацию может отнимать время от более важных аспектов разработки, таких как архитектура системы, пользовательский интерфейс и возможности.

6. Невозможность предугадать узкие места: Без реального использования и нагрузки сложно точно определить, где именно возникают проблемы с производительностью. Часто они проявляются в неожиданных местах.

________________________________________________________________________________________________
### Подход к оптимизации:

Лучший подход к оптимизации — это частичная оптимизация и профилирование:

1. Сначала функционал: Сначала реализовать функциональные требования проекта.

2. Профилирование кода: Использование инструментов профилирования (замер производительности), чтобы точно определить, где находятся узкие места.

3. Избирательная оптимизация: Оптимизация конкретных участков кода, которые действительно требуют улучшения производительности на основе данных профилирования.

________________________________________________________________________________________________
Таким образом, разумный подход к оптимизации заключается в том, чтобы сначала разработать работающий продукт, а затем определить и исправить реальные проблемы с производительностью.

Железом задавим. Железо дешево.

У меня раньше тоже была преждевременная оптимизация, но работа во франче её вылечила))

Этак и стандарты 1С можно отнести к вредным советам.

"Концепция организации процесса разработки, ориентированной на максимально быстрое получение результата в условиях сильных ограничений и proof-of-concept" - наше все.

(0) автор ИИ?

Ситуация с которой я часто сталкивался.
Заказчик: Ну как работает?
Программист: Типа того, только ту еще подшлифовать кувалдой надо, да там...
Заказчик: Отлично! Запускаем! Мне как раз для новой сделки на сто тыщь хренлиардов надо!
Пользователь: А!!! А у меня все хреново!! Тут криво и там никак...
Заказчик: Программист потом все доделает! Поехали!!!
Через пол-часа после запуска.
Программист: Тут оптимизацией надо заняться...
Заказчик: Пофиг, и так сойдет. У меня новая идея нового модуля появилась. Срок - позавчера уже позарез надо. А пользователь как-нить привыкнет.
(тихий плач пользователя в темном углу)

(6) Ну и правильно, кто заказывает музыку- тот девушку и танцует. А пользователь? а что пользователь? Кому до него есть дело. Он зарплату получает в конце концов.

(5) Вы так говорите, как будто промт-инженер и оформитель вообще не участвовали. Вот так вдруг появилась статья из недр нейронки и выдалась на форум? Это так не работает.

(6) программист же не тупой инструмент, в зависимости от чувства прекрасного, самоуважения и стремления делать хорошо может сказать: нет, не готово, надо еще 3 часа.
99% заказчиков в этот момент убегут парить мозг кому-то еще. А половина из них вернется даже не через 3 часа, а послезавтра или через неделю.

(9) Пойдут искать другого программиста.

(8) справедливости ради, именно такого результата от ИИ не добился. Стандартный ответ от ИИ на 4-, тот что в (0) - реально на 5.

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

(10) ветер в спину. Значит это не наш клиент

(12) С играми другая ситуация. Статья в сабже больше ориентирована на программистов 1С.

(13) Так и без клиентов остаться можно.

(15) без 1% неадекватов с шилом в жопе? это же замечательно, надо соблюдать гигиену

У меня две проблемы - перфекционизм и боязнь Гены, он делает с перфекционистами что-то страшное.

С трудом заставляю себя не оптимизировать, пока не отлажен функционал.

(0) В СССР было модно проводить оптимизацию. Потом вносишь рационализаторские предложения как ускорить код, за счет использования ресурсов. Получаешь премию. Потом вносишь рационализаторское предложение, как оптимизировать использование ресурсов (отменяешь старый код). Опять получаешь премию.

(12) Это так и есть. На UE5 можно склепать "симулятор ходьбы" относительно быстро, но оптимизация и геймплей - уже довольно сложные материи. Примеров, кроме "Смуты", немало.
Кстати, да, UE5 - отраслевой стандарт.

Ну да, в программировании на первом месте кнут (деньги и сроки).
Пряники - потом.

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

(17) А чего его бояться-то? Он программировать не умеет.

"Он программировать не умеет." Поэтому вдвойне страшней.

все не читал

Если человек работает "фиксиком" то оптимизация вообще редко бывает нужна. Ну, если человек не пишет уж совсем неэффективный код.

Вот решает он задачу. Если он её не сделает или сделает слишком поздно - значит кто-то будет это всё делать руками.
А если сделает быстро - пользователи прокричать "Ура !", подождут лишние 5 минут что работает не очень эффективный алгоритм - и дадут новую задачку. Ну и будут смотреть на тебя как мой кот смотрит на холодильник :-)

А к той задачке они могут вернуться через полгода - и опять подождут лишние 5 минут.

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

Так что просто зависит от области.

(0) +1

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

Как и всегда нужен баланс.

Если выбор - сделать тяп ляп за 1 день, или за неделю сделать  красиво. И функционал редко используемый и не критичный. То совесть меня не будет мучать))
Или если заранее известно, что это прототип, который 100 раз поменяется.

Если вмешиваешься куда-то в передзаписью, какого-то популярного документа, которых по 1000 в день. То тут конечно 7 раз отмерь, один раз отрежь.

Я не сторонник оптимизировать то, чего ещё нет. Сначала в ОЭП, и по результатам под протокол с фиксацией узких мест. Иначе нафиг ибо не фиг.
Хотя... если немного подумать, и учесть базовый метод разработки в среде 1С (ХХП), то вопрос становится нетривиальным, и, возможно, в исключительных случаях, коих, безусловно, подавляющее большинство, указанная в сабже хрень имеет право на существование.

изучить опыт аналогичных решений у других

Капитаны очевидности в треде.

Любое слепое следование Clean Code это верная смерть проекта.

(31) Это мне напомнило, буквально сегодня на Хабре читал:

Реализация принципа единственной ответственности на Python
https://habr.com/ru/companies/otus/articles/818667/

На мой дилетантский взгляд, мягко говоря, спорная интерпретация одного из принципов Мартина.

Всё должно быть в меру.
Грубые ошибки надо исключать сразу.
Докапываться "до мышей" - только при необходимости.

(32) Ещё в копилку:
Принцип программирования DRY (Don’t repeat yourself, «не повторяйся»)
wiki:Don’t_repeat_yourself

Игра слов: "dry" - сухой, т.е. программный код освобождён от "воды" (лишнего дублирования), является "сухим".

(21) Вот с этим, пожалуй, соглашусь. Чаще, если уж наткнулся на совсем плохой код, то он не оптимизируется, а полностью переписывается...

(22) Он людей перепрошивает за один комментарий на форуме, это ли не программирование?

(36) Я согласен, он крут: может и стихами зарядить, и цитаткой по башке стукнуть. Но Вы держитесь! Отступать некуда, впереди 1С:ERP...

(32) Читал тоже на хабре
"Напрасные усилия" и "Сложность и запутанность кода" самое главное.
Нужно стремиться к оптимизации, но не до фанатизма.

"Мы за все хорошее, и против всего плохого". Все эти принципы хороши, когда проект создается целиком с нуля. А когда на уже живую конфигурацию, на дюжину ранее написанных (и тоже рабочих) модулей, надо натянуть сверху еще один,и учесть все что в них было наваяно за предыдущие годы (а иногда и десятиления), то все эти благопожелания о "правильном" коде оказываются неприменимыми. Потому что иначе надо все сносить и строить все заново.
Я когда-то поддерживал программу, написанную для расчета зп на швейном предприятии. Так там необходимо было учитывать не толь ко современные требования законодательства, но и, например, норму СовНарКома от 1928 года, о повышающих коэффициентах расценок за ткани разных цветов (на ярких глаза быстрее устают и нормы должны быть снижены)... И эта программа была написана еще в конце 80-х, и жива до сих пор (потому что вручную просчитать все заложенные в нее сотни коэффициентов, типа "повышающий коэффициент для беременной надомницы за срочную переработку в выходные и праздники в зимний период" уже нереально).

(28) >> "всегда нужен баланс"

Золотые слова.

Проблема преждевременной оптимизации действительно существует.
Негативные последствия она может приносить именно в тех случаях, которые описаны в (0). Прежде всего это ошибки определения узких мест, избыточное усложнение и запутывание кода, и неоптимальное расходование усилий разработчика на оптимизацию в ущерб другим ключевым задачам.

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

Где находится искомый баланс - должен решать руководитель проекта. Он же определяет приоритеты - что важнее функциональность, оптимизация или что-то ещё, и очерёдность.
Что касается таких универсальных решений, которыми являются конфигурации 1С, то тут зачастую разработчик может только догадываться об узких местах, которые могут потребовать оптимизации. Уж насколько Бухгалтерия Предприятия (БП) является растиражированной конфой, в которой казалось бы код должен быть вылизан. Но нет - даже там встречаются места, где без дополнительной оптимизации работать невозможно (видимо разработчики решили на оптимизацию вообще забить, предположив, что она не нужна).