Оптимизация — всего лишь фича: почему разработчик не должен думать о производительности

«Преждевременная оптимизация — корень всех зол». Это цитата Дональда Кнута, автора книги «Искусство программирования». На своем YouTube-канале основатель школы программирования FoxmindEd Сергей Немчинский рассказал, почему он полностью согласен с Дональдом Кнутом и когда не стоит оптимизировать приложения.

Highload публикует этот материал текстом.

Начнем с терминов: что такое оптимизация и когда она преждевременная

• Оптимизация — это работа по улучшению программного кода. Она приводит к его ускорению, снижению сложности алгоритма, снижению потребляемых ресурсов и т.п.
• Преждевременная оптимизация — это оптимизация, проведенная раньше, чем нужно.

Чтобы ответить на вопрос «А когда нужно?», стоит рассмотреть, что такое разработка в целом.

Разработка — это про деньги. Она может быть хобби или любимым делом, но если вы работаете программистом — значит то, что вы делаете, вы делаете для кого-то и за эту работу вам платят.

Source: Rounders

Соответственно, самая важное в вашем коде — это то, решает ли он проблему бизнеса: завоевывать новые ниши или быть лучше конкурентов.

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

Другими словами, оптимизация — это такая же фича, как какая-нибудь кнопка: ее делают, только если она непосредственно запрошена бизнесом.

Почему бизнесу невыгодно делать оптимизацию с самого начала

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

Таким способом мы получили, например, далеко неидеальный Facebook. Он был достаточно удобным: со своими багами и глюками, но пользоваться им было можно. А теперь уже никто не будет переходить на новую соцсеть просто потому, что все привыкли к этой. Вот это «достаточно» и означает, что дальше оптимизировать будет уже не оптимально.

Source: Curb Your Enthusiasm

Цена преждевременной оптимизации запредельна и определяет, вы на рынке или вне рынка.

Это же кстати, причина, почему легаси-код — признак успешного проекта. Потому что вот как такие проекты делаются:

1. Собирается proof of concept, чтобы показать потенциальному заказчику, что вы вообще можете это сделать и как это будет выглядеть. Если заказчику понравится, то это сразу может пойти на рынок.
2. Первые несколько лет вы забиваете на оптимизацию. Вам нужно гнать фичи быстро, забывая о техническом долге и юнит-тестах.
3. Потом, через несколько лет, когда проект зарекомендовал себя и у него миллионы пользователей, наступает период стабилизации и наведения порядка: рефакторинга, юнит-тестов и пр.

Если сейчас вы думаете, что «злой капитализм заставляет меня писать говнокод», то посмотрите на это с другой стороны: что для вас, как для пользователя, важнее — уже сегодня поиграть в новую игру или ждать еще пару лет, пока ее сделают идеальной?

Как делать оптимизацию, чтобы она не была преждевременной

1. Пишем приложение так, чтобы оно работало.
2. Когда у нас появляется возможность (если мы не на этапе proof of concept), наводим в приложении порядок: делаем рефакторинг, причесываем, изменяем названия и т.д.
Онлайн-курс "2D Animation" від Skvot.
Покроково та з фідбеком від лекторки увійдіть у 2D-анімацію через вивчення софтів, інструментів та створення кейсу у портфоліо.
Програма курсу та реєстрація
3. Запускаем, проводим измерения времени работы и спрашиваем бизнес: «Вам окей по скорости?»
   Вы будете смеяться, но очень часто бизнесу будет окей. Например, вы будете волноваться из-за нажатия кнопки, которое занимает десять минут, а бизнес скажет: «Ничего, ей все равно редко пользуются».
4. Если бизнесу окей — алгоритм заканчивается на предыдущем шаге. Если НЕ окей — вы получили запрос от бизнеса. Но идти и оптимизировать пока рано — в 80% случаев вы начнете исправлять совсем не то, что нужно. Как узнать, что нужно?
5. Запускаем профайлер. Находим нужное место и исправляем его.
6. Измеряем скорость снова и отправляем запрос заказчику. Если ему окей, алгоритм заканчивается, если нет — начинается снова с предыдущего шага.

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

Еще раз, напоследок: только бизнес решает, нужна ли оптимизация и когда она достаточная.