Хабрахабр

[Перевод] Хватит разрабатывать софт с запасом

Если выбрать одну идею, которая убивает больше всего продуктов, то это создание запаса на будущее (future proofing).

Обычно идея проявляется по схеме.

Нам нужен , и хотя сделать {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% пользователям нужен сервис Z. Вряд ли возможно совпадение, что вы предоставляете сервис A и 90% пользователям нужно именно это. Однако 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 ГБ/с запись)

Могу поспорить, что у большинство распределённого программного обеспечения требует рабочую нагрузку менее чем в половину от мощности этого любительского сервера.

Вы можете взять десяток за зарплату опытного инженера DevOps в Лондоне. Такой сервер стоит от ~800 до $1300 в месяц в зависимости от местоположения.

Ещё приятнее, что сервер вдвое подешевеет через два-три года.

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

Тем не менее, люди продолжают разрабатывать ПО для аппаратных спецификаций и цен начала 2000-х, хотя в 2018 году нужно разрабатывать софт для машин 2019 года.

Если хотите подумать о будущем, подумайте обо всех будущих периферийных устройствах. Это касается не только серверов. Я уверен, что ребята, которые предусмотрели для своего устройства голосовой интерфейс в 2016 году, вполне счастливы в 2018-м.

Чёрт его знает. К какой периферии готовиться в 2018 году? Когда она станет популярной, то поможет вам занять монопольное положение на рынке, потому что вы уже адаптировали для неё свой софт. Но я знаю, что она ещё не стала популярной.

С появлением WASM браузеры становятся универсальными виртуальными машинами. И речь не только о железе, прогресс в программном обеспечении абсолютно удивителен. Через два года вы сможете собрать высокопроизводительное приложение, скомпилировав его для единственной платформы: WebAssembly.

Они используют Babel, хотя у 99%+ пользователей браузеры с поддержкой ES6. Несмотря на это, люди по-прежнему создают софт для домашних компьютеров образца 2012 года.

Только за последние 8 лет появились Go, Rust, Scala и D, которые полностью изменили парадигму системного программирования. Постоянно появляются новые языки, а некоторые из них очень хороши. В ближайшие два года мне кажется, что Julia произведёт такую же революцию в научных вычислениях… и это только области, которыми я лично занимаюсь, а общее количество будущих удивительных вещей просто невероятно.

Легко радоваться будущему. Но реально никто не знает, что произойдёт через год-два-пять лет. Есть некоторые прогнозы, но они, естественно, не идеальны.

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

Софт с запасом на 2020-й год, сделанный в духе начала 2000-х, ничем вам не поможет.

Просто начните планировать правильно.

Проектируйте с учётом не только своего продукта, но и всей окружающей экосистемы.

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

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть