[Перевод] Хватит разрабатывать софт с запасом
Если выбрать одну идею, которая убивает больше всего продуктов, то это создание запаса на будущее (future proofing).
Обычно идея проявляется по схеме.
Нам нужен {X}, и хотя сделать {Y} гораздо легче, но при наступлении {Z} первый вариант упростит нам жизнь.
Где {Z} — событие, которое может произойти в далёком будущем.
Вот несколько примеров:
- Для инфраструктуры нужны Kubernetes и Docker, хотя один большой сервер гораздо проще, но когда придётся масштабироваться до 11-ти серверов, это упростит нам жизнь.
- Для обработки данных нужен распределённый дизайн, хотя централизованное решение гораздо проще, но когда клиент потребует 99,999% безотказной работы в SLA, это упростит нам жизнь.
- Нужно набрать команду разработчиков и создать собственное программное обеспечение, хотя Wordpress и Shopify гораздо проще, но когда клиентская база вырастет в 100 раз, это упростит нам жизнь.
- Нужно использовать дизайн на основе наследования типов, хотя композиция гораздо проще, но после 5 лет увеличения кодовой базы это упростит нам жизнь.
- Нужно написать код в C++ с кэшированием представлений, хотя Python-скрипт с прямыми запросами к Postgres гораздо проще, но при большом увеличении объёма данных это упростит нам жизнь.
Недавно я написал статью о воображаемых проблемах, которые люди придумывают себя со скуки, а не для пользы. Создание запаса на будущее обычно относится к этой категории. Я бы даже сказал, что это самая популярная ошибка в большинстве маленьких компаний.
Но это стоит дальнейшего обсуждения, потому что создание запаса на будущее может действительно помочь продукту, есть сделать всё правильно. Тем не менее, большинство людей делают ошибки и вредят работе.
Как бы странно это ни звучало, я думаю, что одна из главных причин происходящего — культ знаменитостей.
У людей странная одержимость — ставить себя на место кого-то более успешного. Затем они строят планы с этой позиции, а не думают по-своему.
Каждый фантазирует, что бы сделать с той удивительной силой, которой у него нет. Словно он президент страны, миллиардер, знаменитость, виртуозный исполнитель или супермен со сверхчеловеческими способностями.
Проблема разработчиков в том, что они слишком потакают этим фантазиям. Программное обеспечение может написать каждый. Не только Facebook способен создать медиаплатформу, которая поддерживает миллиарды пользователей, но вы зря потратите время. Магия Facebook состояла в том, чтобы привлечь эти миллиарды пользователей, а масштабирование системы — лёгкая часть.
Здесь два аспекта:
- a) Достичь роста намного сложнее, чем технически обеспечить его.
- б) Самые выдающиеся и известные инженеры работают над продуктами, которым требуется масштаб.
Первый пункт очевиден, если подумать. Сколько софтверных компаний потерпели неудачу, когда достигли миллиардного дохода или миллионного количества пользователей? Может, 80%… если определить «неудачу» очень строго.
Тем не менее, из всех когда-либо созданных софтверных компаний, возможно, только 0,05% когда-либо достигали такого масштаба.
Проблема с созданием запаса состоит в том, что он обычно создаётся для сценариев, которые никогда не воплощаются в жизнь. Будь то рост до 1000 сотрудников, 10 000 000 пользователей или 10 крупных клиентов с драконовскими требованиями.
И трудно отказаться от таких планов, потому что это мешает мыслям об успехе. Мешает людям фантазировать, как они побеждают Amazon, а вместо этого возвращает к реальности. А в реальности у вас 50 клиентов, половина из которых — родственники и друзья.
Второй пункт лишь ухудшает ситуацию. Вполне естественно, что лучшие программисты получают лучшие места в ведущих компаниях. Они либо помогли их создать, либо там платят миллионы за поддержку.
Принцип Парето работает против нас, поскольку лучшие программисты пишут большинство книг и дают большинство лекций. Мы постоянно слышим о распределённых сервисах на тысячах машин, которые обрабатывают петабайты данных и борются за каждый процент производительности. Но большинству из нас не придётся думать, какого масштаба или надёжности требуют системы вроде Facebook или Google.
Так если фантазии о будущем не помогают, значит, не нужно планировать?
Нет, конечно. Думать о будущем важно. Следует закладываться на него, но делать это правильно.
Когда дело доходит до размышлений о будущем, то лучше меньше, да лучше.
Очень редкие продукты точно соответствуют потребностям пользователей, остальные подстраиваются на ходу.
Вряд ли возможно совпадение, что вы предоставляете сервис A и 90% пользователям нужно именно это. Обычно вы предоставляете сервис A, а 90% пользователям нужен сервис Z. Однако A — ближайшая альтернатива Z и никто не предоставляет Z… поэтому некоторые клиенты решают смириться.
Это хорошо. Когда клиенты решают смириться с вашим продуктом, то вы можете изменить его в соответствии с их точными потребностями. По сути, пользователи помогают определить нишу на рынке. Как только вы сможете лучше заполнить эту нишу, то начнёте расти.
Это продуктивная парадигма мышления, потому что она поощряет подход «лучше меньше, да лучше» в отношении будущего развития. Запас на будущее предполагает не увеличение сложности, а наоборот — максимальное упрощение. Чтобы иметь возможность адаптироваться.
Чем проще ваша кодовая база, тем легче её настроить для выполнения другой задачи.
«Я ненавижу код и хочу, чтобы его было как можно меньше в нашем продукте». — Джек Дидерих
Идеальный дизайн требует жертв. Обычно они связаны с гибкостью.
Зачастую именно несовершенный софт решает мировые проблемы, поскольку несовершенное более гибко. Несовершенство по определению оставляет возможности для улучшения.
Ещё важно помнить, что мир вокруг не статичен.
Будущие проблемы нужно решать будущими технологиями.
Многие люди не только не думают о будущих инструментах, но вообще пользуются инструментарием десятилетней давности. Они накладывают на себя ограничения, которые давно сняты.
Поясню на конкретной проблеме: проектирование распределённого программного обеспечения. Одна из распространённых причин, почему разрабатывают такой софт — потому что единственный сервер не сможет масштабироваться до требуемых спецификаций. Хотя в некоторых ситуациях это верно, но трудно поверить в такие перспективы большинства проектов, особенно стартапов, у которых почти нет клиентов.
Думаю, частично причина в том, что большинство разработчиков в 2018 году всё ещё думают о серверах 2005 года. Но компьютеры с каждым годом улучшаются, и многие провайдеры продают дешёвые выделенные серверы.
Например, вот дешёвый большой сервер:
- Два Xeon E5–2680v4 (28 ядер, 56 потоков, тактовая частота от 2,4 ГГц до 3,3 ГГц)
- 512 гигабайт DDR4–2400 RAM
- 2 NVMe SSD по 1,2 ТБ (у каждого ~3 ГБ/с чтение, ~1,5 ГБ/с запись)
Могу поспорить, что у большинство распределённого программного обеспечения требует рабочую нагрузку менее чем в половину от мощности этого любительского сервера.
Такой сервер стоит от ~800 до $1300 в месяц в зависимости от местоположения. Вы можете взять десяток за зарплату опытного инженера DevOps в Лондоне.
Ещё приятнее, что сервер вдвое подешевеет через два-три года.
Компьютеры продолжают улучшаться, и они будут делать это линейно до конца 2020-х годов. Кто знает, какие появятся изобретения. К тому времени мы даже можем увидеть революцию открытого железа.
Тем не менее, люди продолжают разрабатывать ПО для аппаратных спецификаций и цен начала 2000-х, хотя в 2018 году нужно разрабатывать софт для машин 2019 года.
Это касается не только серверов. Если хотите подумать о будущем, подумайте обо всех будущих периферийных устройствах. Я уверен, что ребята, которые предусмотрели для своего устройства голосовой интерфейс в 2016 году, вполне счастливы в 2018-м.
К какой периферии готовиться в 2018 году? Чёрт его знает. Но я знаю, что она ещё не стала популярной. Когда она станет популярной, то поможет вам занять монопольное положение на рынке, потому что вы уже адаптировали для неё свой софт.
И речь не только о железе, прогресс в программном обеспечении абсолютно удивителен. С появлением WASM браузеры становятся универсальными виртуальными машинами. Через два года вы сможете собрать высокопроизводительное приложение, скомпилировав его для единственной платформы: WebAssembly.
Несмотря на это, люди по-прежнему создают софт для домашних компьютеров образца 2012 года. Они используют Babel, хотя у 99%+ пользователей браузеры с поддержкой ES6.
Постоянно появляются новые языки, а некоторые из них очень хороши. Только за последние 8 лет появились Go, Rust, Scala и D, которые полностью изменили парадигму системного программирования. В ближайшие два года мне кажется, что Julia произведёт такую же революцию в научных вычислениях… и это только области, которыми я лично занимаюсь, а общее количество будущих удивительных вещей просто невероятно.
Легко радоваться будущему. Но реально никто не знает, что произойдёт через год-два-пять лет. Есть некоторые прогнозы, но они, естественно, не идеальны.
Тем не менее, если вы действительно хотите создать запас на будущее, то сначала поймите, что предлагает настоящее. Ко всему прочему, так вы сделаете более точный консервативный прогноз на основе реальных данных.
Софт с запасом на 2020-й год, сделанный в духе начала 2000-х, ничем вам не поможет.
Просто начните планировать правильно.
Проектируйте с учётом не только своего продукта, но и всей окружающей экосистемы.
Проектируйте для гибкости, а не для совершенства. Гибкость в конечном счёте поможет адаптировать программное обеспечение для будущего. Она помогает принять новые вызовы, а не защищает от воображаемых.
