Здравствуйте, vdimas, Вы писали:

V>О да!
V>Знаешь, ты скорее говоришь о ситуации, когда люди увлекаются некоторыми подробностями и за деревьями им становится не видно леса. Но это совсем из другой оперы, оптимизация именно быстродействия чего-либо тут вовсе не при чем. Даже если и прозвучало "мы просто хотели сделать оптимальнее" — это обычная отмазка неопытного разработчика, которому хочется быстрее попрограммировать и быстрее увидеть результат. Стоит ли эту отмазку огульно приписывать всем остальным?

Да я и не приписываю.
Может я и не прав, но у меня есть свое определение оптимизации: "оптимизация, это ухудшение качества кода с целью повышения его быстродействия".

V>Как бы тебе это сказать потактичнее...

Потактичнее не надо. Я на правду-матку не обижаюсь.

V>Когда все делается "как положено", то еще на стадии анализа многие узкие места могут быть увидены и проверена их реальная "узость" в технических экспериментах.

Я занимаюсь разработкой игр. У нас почти никогда не делается "как положено". Извините, наболело. Под лозунгом повышения быстродействия прокатывают совершенно нереальные по своему убожеству архитектурные решения.

V>Точно так же может стать понятно, насколько гибким должен быть дизайн. За гибкость ВСЕГДА приходится платить, поэтому преждевременная гибкость — это такая же разновидность преждевременной оптимизации. Да, чем хуже формализованы требования, тем большая гибкость требуется относительно реализации каждого такого требования, но это лишь говорит о том, что ни о какой безусловности твоего лозунга не может быть и речи. Например, требуется ли эта "гибкость дизайна" при разработке кодека по устоявшемуся алгоритму или при реализации TCP протокола?

Не поспоришь.

V>Могу лишь согласиться с тем, что упомянутая тобой разновидность желания "сделать все лучше" не так тяжела в последствиях, как "битовыжимания", ибо наиболее вероятно такой код не придется выкидывать полностью. Но насколько получится его повторно использовать? В 99% не получается, кроме вот этого одного целевого приложения, поэтому вся эта заведомая гибкость лишь добавляет необоснованных трудозатрат.

Согласен. Я неоправданно распространил свои задачи на всю индустрию. По себе же скажу — сейчас разрабытаваю игровой движок, фактически технологию или фреймворк, называй как хочешь. Здесь приходится балансировать на острие ножа между требованиями производительности и гибкостью, так как повторное использование предполагается в нескольких проектах.

V>Вообще о гибкости говорить странно в эпоху продвинутых сред, анализа кода и мощнейшего рефакторинга, где внести лишнюю асбтракцию или перегруппировать имеющиеся — это как два пальца. Единственный универсальный критерий только один — это чтобы на каждом уровне проектирования/программирования было вменяемое кол-во задействованных сущностей.

Не совсем. Вопрос в стоимости рефакторинга. Я уже говорил о том, что неумное оптимизирование приводит к масштабному переписыванию кода. Это как раз об этом. Если требуется рефакторинг, затрагивающий, например, 25% кода приложения, как это назвать? Катастрофа.

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

Согласен, но. Если код библиотек измеряется миллионами строк, то без хорошо продуманной архитектуры обойтись невозможно.

V>В плане же быстродействия (раз о нем речь) заниматься полной отрицаловкой, как тут некоторых заносит, тоже не стоит, ибо это попахивает инженерным идиотизмом.

Ни в коем случае. Если с моих слов создается такое впечатление, то прошу прощения за то, что непреднамеренно ввел в заблуждение. Вопросами производительности занимаюсь практически постоянно, но не отношу их к оптимизации (см. определение).

V>Достаточно не забывать о правилах хорошего тона. Например, если серверное приложение долго стартует, то это никого не интересует, но крайне раздражает пользователей в случае клиентских приложений. И не только во время старта — пользователей всегда раздражают случаи демонстрирования "тормознутости" программы. Но опять же, здесь не требуется выжимать разницу в миллисекунды, ибо юзер эту разницу не заметит все-равно... но когда с помощью лишней пары строк кода можно улучшить отклик в десятки раз (как раз обсуждалось), и не заставлять клиента нервничать несколько минут, то это сделать надо непременно. Я не призываю начинать разработку с этого (см. начало моего сообщения), но перед тем, как отдать клиенту — обязательно. И заметь, твоему лозунгу это никак не противоречит.

V>Вообще-то смешно видеть, когда коллеги сами себе противоречат в непререкаемом тоне. Не так улыбают замеченные противоречия, как пафос при их декларации...

Это не пафос. Я просто хотел потаскать за рога священную корову Павла Дворкина. Но он опытен и не поддался

V>Суммируя вышенагенеренный мною спам: оптимизация бывает не только по быстродействию — сей лозунг всего-навсего предостерегает от любых лишних трудозатрат, оправданность которых сугубо умозрительна.