Пол Букхейт: Секрет облегчения работы: избегайте трудных проблем

Перевод эссе Paul Buchheit The secret to making things easy: avoid hard problems

Это может показаться очевидным, но, по моему опыту, большинство инженеров предпочитают сосредоточиться на трудных проблемах. Работа над трудными проблемами впечатляет других инженеров, но это не лучший способ создания успешных продуктов. На самом деле, это одна из нескольких причин, почему YouTube победил Google Video: Google потратил много времени на решение технически сложных проблем, в то время как YouTube создал продукт, которым люди действительно пользовались (используя PHP и MySQL, что, я думаю, совсем не впечатляет технически).

Для меня наиболее эффективным методом быстрого решения задач является обман (технически), использование множества коротких путей и поиск более легкого способа обойти проблему (и прежде чем кто-то вскочит с комментариями о безопасности или банковских операциях, очевидно, есть несколько исключений). Вам нужно только думать наперед, чтобы не загнать себя в угол, или иметь правдоподобный план выхода из него. Всегда есть более легкий путь - работайте ленивее, а не усерднее. Обратите внимание, что это не исключает того, чтобы делать вещи, которые КАЖУТСЯ трудными - легкие решения важных проблем, которые ВЫГЛЯДЯТ действительно трудными, являются лучшими.

Я вспомнил об этом, отвечая на комментарии на news.yc в ответ на мой пост о дисках и базах данных. Всякий раз, когда кто-то упоминает о возможности не использовать обычную базу данных, многие люди сразу же отвечают, что базы данных решают множество очень сложных проблем, и что не стоит прилагать много усилий, чтобы изобретать колесо. Эти люди, конечно, правы.

Но дело в том, что многие из этих сложных проблем неактуальны для 99% продуктов. Например, "настоящие" базы данных могут обрабатывать транзакции, которые слишком велики, чтобы поместиться в памяти. Возможно, в 1980 году это было действительно важной особенностью. Сегодня вы можете купить компьютер с 32 ГБ памяти примерно за $5000. Как вы думаете, сколько транзакций объемом в ГБ выполняет Twitter? Мое предположение - ноль. Я подозреваю, что средний размер транзакции ближе к 0,0000002 ГБ (сообщения ограничены 140 символами).

Я хочу прояснить одну вещь: я не советую вам отказаться от базы данных! Если ваша база данных работает достаточно быстро, то проще всего, вероятно, "ничего не делать", и именно это я и советую вам сделать. Однако если ваша база данных работает медленно или перегружена, то вам нужно сделать две вещи:

1. Понять проблему

2. Устранить проблему

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

Хотите пример "простого, но менее надежного"? Вот один из них (в один или два простых шага):

1. Все обновления поступают в Memcached, но не в базу данных.

2. (опционально) Фоновый процесс периодически копирует записи из memcached в базу данных. Без этого значения будут полностью потеряны при перезапуске Memcached.

За перевод спасибо Muhammadjon H. (автор канала Road to Google)

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