Пол Букхейт: Оптимизация

Перевод эссе Paul Buchheit Optimizing everything: some details matter a lot, most don't

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

Как и всё остальное, оптимизация - сложная тема, поэтому я собираюсь упростить ее до трех простых шагов:

• Составить список проблем ("профилирование")
• Отсортировать список в соответствии с соотношением выгоды от исправления к затратам на исправление ("ROI")
• Устранить проблемы в порядке от наибольшего соотношения выгоды/затраты к наименьшему.

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

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

Это также те действия, о которых я писал в своем посте "Трата времени на вещи, которые на самом деле не имеют значения". Дело не в том, что нет никакой разницы между двумя немного разными способами тестирования на пустую строку, просто у вашего продукта, вероятно, есть 100 000 более серьезных проблем, и поэтому время, потраченное на беспокойство о подходах к обнаружению пустой строки, - это время, НЕ потраченное на устранение этих более важных проблем. Другими словами, сначала устраните все остальные проблемы, а потом спорьте о пустой строке.

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

Сравнение методов тестирования на пустую строку — это, очевидно, небольшая деталь, и есть соблазн подумать, что не стоит беспокоиться о таких мелких деталях, но это тоже большая ошибка. Еще один важный урок оптимизации заключается в том, что небольшое количество деталей может определять большую часть результата. Обычно это называют правилом 80/20 или 90/10, которое гласит, например, что "90% времени тратится на 10% кода", но с таким же успехом это может быть 99/1 или что-то подобное (а для кода, который уже был хорошо оптимизирован, правило 80/20 может не работать — это просто эвристика). В коде это может быть всего несколько строк во "внутреннем цикле", или, возможно, это процентная ставка по вашей ипотеке ("что такое несколько процентов?"). Однажды я профилировал сервер Google и обнаружил, что около 90% времени тратится на одну строчку кода: вызов sscanf (повторяющийся миллионы раз), который кто-то протащил в код скоринга (это правило 99999/1).

Определение того, какие детали имеют большое значение (а какие нет), также является ключом к разработке успешных продуктов. В ставшем уже классическим сообщении об iPod на slashdot от 2001 года они вынесли вердикт недавно выпущенному iPod: "Без беспроводной связи. Меньше места, чем у Nomad. Отстой".

История показывает, что это были не самые важные детали, поскольку сейчас 2007 год, а iPod до сих пор не имеет беспроводной связи (по крайней мере, до 29-го числа), и большинство iPod имеют объем памяти меньше, чем первоначальные 5 ГБ. Тем не менее, компания Apple правильно сфокусировалась на нескольких очень важных деталях: на iPod легко записать музыку, он вмещает "достаточно" музыки (в отличие от первых флэш-плееров) и легко помещается в карман (в отличие от первых CD-плееров).

Как же определить, какие детали важны? Наблюдения (и некоторые суждения, но я думаю, что они в основном формируются через наблюдения). Если вы оптимизируете приложение, обратите внимание на то, каких ресурсов не хватает или какие вызывают задержки (это не всегда CPU - часто это запросы к жесткому диску), а затем посмотрите, где эти ресурсы расходуются. Если вы пытаетесь оптимизировать деньги, сначала понаблюдайте, куда уходит и откуда приходит большая их часть. Чтобы оптимизировать дизайн продукта, понаблюдайте, какие вещи являются наиболее "полезными", а какие - наиболее неприятными или раздражающими (как правило — это ожидание или принуждение к размышлению).

Если вы займётесь действительно важными делами и сделаете их, вы будете настолько впереди всех остальных, что остальные детали, вероятно, не будут иметь значения. Но помните, что ваше время ограничено, поэтому время, потраченное на неважные детали, — это время, не потраченное на важные! Большинство инженеров очень ориентированы на детали, и это хорошо, так как они могут действительно сосредоточиться на важных деталях, и плохо, потому что также они могут сосредоточиться и на неважных! Я считаю, что научиться различать эти два типа деталей действительно будет стоить затраченного времени.

Кстати, чтобы завершить больше полезных дел, уменьшите затратную часть уравнения выгоды/затраты, чтобы вы могли делать больше вещей за меньшее время (находя более простые решения, избегая бесконечных дебатов и т.д.).

За помощь с переводом спасибо Vladimir Gaylun

Следите за новостями Мировоззрение Y Combinator в телеграм-канале.

• Серендипность тебя найдет
• Мировоззрение хакера
• Мышление миллиардера из Кремниевой долины: как принимать решения, связанные с риском
• Три типа идей: и почему плохие идеи часто оказываются лучшими
• Мой стартап путь
• Не в деньгах счастье же
• Дар
• Восемь лет назад
• Я - ничто
• Как быть правым 90% времени, и почему я лучше буду ошибаться
• Трата времени на вещи, которые на самом деле не имеют значения
• Секрет облегчения работы: избегайте трудных проблем
• Туннельное зрение