The root of all evil
Вначале программисты оптимизировали все что ни попадя. Глядя на то безобразие, которое у них получалось, Кнут в сердцах воскликнул: хватит уже заранее оптимизировать! Сначала хотя бы померяйте, какой код работает большую часть времени, и уже его оптимизируйте!
А что, мужик дело говорит - решили программисты. Да и вообще, зачем мы паримся, если частота CPU растет вдвое каждый год? И забили оптимизировать. И несмотря на нынешние гигагерцы и терабайты, написать программу, которая выведет пользователя из себя, мы по прежнему могём.
С оптимизацией связано два антипаттерна: premature optimization и premature pessimization. Они пародируют две крайности, а крайности, как известно, редко доводят до добра. Правда же в том чтобы соблюдать некий баланс.
Когда возникает вопрос, нужно ли вот прямо сейчас применить некую оптимизацию, первым делом надо подумать: а усложняется ли от этого код?
Если код не усложняется, то оптимизировать нужно и сразу. Даже если этот код один раз на старте исполняется. Даже если пользователь не заметит тех микросекунд, которые вы ему сэкономили. Дело не в пользователе, а в прокачке скилла "пиши быстрый код на автомате". Потому что речь обычно идет о том, чтобы выбрать ArrayList или массив[]. Ну или чем то подобном. Если ArrayList реально не требуется, написать вместо него [] много времени не отнимет. Зато будет развиваться чутье на быстроту кода.
Также бытует мнение, что вот посмотрим в профилировщик, найдем там пик и его заоптимизируем. Однако такой пик - это как мешок с песком в корзине. Выкинуть его нетрудно. А дальше то что? А дальше равномерно размазанная каша, написанная адептами premature pessimization. Расхлебывать эту кашу - долго и нудно. Так может лучше стараться не заваривать?
Если же стоит выбор оптимизация против простоты, то в 99% случаев надо выбирать простоту. Усложнить код вы еще всегда успеете.
Но, опять же, бывают случаи, когда надо делать предварительную оптимизацию в ущерб простоте. Случаи эти характеризуются двумя признаками:
1. Неотвратимость. То есть заведомо понятно, что без подобной оптимизации программа будет работать неприемлемо медленно. И вам рано или поздно придется ее делать.
2. Фундаментальность. От слова "фундамент". То есть оптимизация - это не что-то сбоку подкрутил, а на нее слишком много завязано. Фактически это и не оптимизация даже, а часть базовой схемы работы. И если ее сразу не ввести, то потом слишком много придется переделывать.
Если оптимизация неотвратима, но не фундаментальна, то ее можно отложить. Например, чтобы побыстрее получить работающий прототип.
Если оптимизация фундаментальна, а вопрос с неотвратимостью непонятен, то следует крепко подумать. Посоветоваться с коллегами. Еще раз подумать. Чтобы не попасть на переделки, если она все таки наступит. Или не делать лишнего, если не понадобится.
Вышесказанное выглядит банальным, но в реальной жизни правильный баланс выдержать не так то просто. Людей обычно заносит в ту или иную сторону. Впрочем, если premature optimization сейчас уже встречается достаточно редко, то premature pessimization - сплошь и рядом.
А что, мужик дело говорит - решили программисты. Да и вообще, зачем мы паримся, если частота CPU растет вдвое каждый год? И забили оптимизировать. И несмотря на нынешние гигагерцы и терабайты, написать программу, которая выведет пользователя из себя, мы по прежнему могём.
С оптимизацией связано два антипаттерна: premature optimization и premature pessimization. Они пародируют две крайности, а крайности, как известно, редко доводят до добра. Правда же в том чтобы соблюдать некий баланс.
Когда возникает вопрос, нужно ли вот прямо сейчас применить некую оптимизацию, первым делом надо подумать: а усложняется ли от этого код?
Если код не усложняется, то оптимизировать нужно и сразу. Даже если этот код один раз на старте исполняется. Даже если пользователь не заметит тех микросекунд, которые вы ему сэкономили. Дело не в пользователе, а в прокачке скилла "пиши быстрый код на автомате". Потому что речь обычно идет о том, чтобы выбрать ArrayList или массив[]. Ну или чем то подобном. Если ArrayList реально не требуется, написать вместо него [] много времени не отнимет. Зато будет развиваться чутье на быстроту кода.
Также бытует мнение, что вот посмотрим в профилировщик, найдем там пик и его заоптимизируем. Однако такой пик - это как мешок с песком в корзине. Выкинуть его нетрудно. А дальше то что? А дальше равномерно размазанная каша, написанная адептами premature pessimization. Расхлебывать эту кашу - долго и нудно. Так может лучше стараться не заваривать?
Если же стоит выбор оптимизация против простоты, то в 99% случаев надо выбирать простоту. Усложнить код вы еще всегда успеете.
Но, опять же, бывают случаи, когда надо делать предварительную оптимизацию в ущерб простоте. Случаи эти характеризуются двумя признаками:
1. Неотвратимость. То есть заведомо понятно, что без подобной оптимизации программа будет работать неприемлемо медленно. И вам рано или поздно придется ее делать.
2. Фундаментальность. От слова "фундамент". То есть оптимизация - это не что-то сбоку подкрутил, а на нее слишком много завязано. Фактически это и не оптимизация даже, а часть базовой схемы работы. И если ее сразу не ввести, то потом слишком много придется переделывать.
Если оптимизация неотвратима, но не фундаментальна, то ее можно отложить. Например, чтобы побыстрее получить работающий прототип.
Если оптимизация фундаментальна, а вопрос с неотвратимостью непонятен, то следует крепко подумать. Посоветоваться с коллегами. Еще раз подумать. Чтобы не попасть на переделки, если она все таки наступит. Или не делать лишнего, если не понадобится.
Вышесказанное выглядит банальным, но в реальной жизни правильный баланс выдержать не так то просто. Людей обычно заносит в ту или иную сторону. Впрочем, если premature optimization сейчас уже встречается достаточно редко, то premature pessimization - сплошь и рядом.