Хабрахабр

[Перевод] Не пытайтесь предугадать завтрашние проблемы

Ну или начните делать это правильно.

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

«Нам нужно реализовать решение , несмотря даже на то, что есть значительно более простое и подходящее нам сейчас решение {Y}, ведь когда в будущем произойдёт {Z}, то {X} сработает гораздо лучше, чем {Y}».

При этом точной информации о вероятности наступления события {Z} нет и быть не может.

Вот пара примеров:

  • Нам нужно использовать kubernetes и docker! Да, с текущей нагрузкой отлично справляется один сервер и его легко настроить и поддерживать, но ведь когда нам нужно будет дюжина серверов — будет легче их разворачивать с kubernetes и docker.
  • Нам нужна архитектура распределенной обработки данных! Да, пока со всем справляется один средненький ПК, но когда у нас будет решение промышленного уровня и заказчики потребуют аптайм в пять девяток после запятой в SLA — мы будем к этому готовы.
  • Нам нужно нанять команду разработчиков и создать сайт с нуля, не смотря на то, что значительно быстрее было бы развернуть что-то на базе wordpress, ведь когда у нас будет в 100 раз больше клиентов, чем сейчас, то wordpress станет не так удобен.
  • Нам нужно использовать наследование вместо композиции, ведь через 5 лет кодовая база разрастётся так, что без этого будет никак.
  • Нам нужно написать вот этот код на С++, не смотря на то, что на Python это будет в разы быстрее, ведь спустя годы он будет обрабатывать терабайты данных и Python может здесь не справится.

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

Достижение успеха более сложно, чем жизнь с уже достигнутым успехом

Каждый человек порой фантазировал о том, как бы всё было, будь он кем-то другим. Кем-то богатым, знаменитым, сильным, наделенным властью. Размышлять об этом достаточно интересно и происходит это как-то само по себе, непроизвольно. Вот ты увидел фото на обложке журнала — и задумался, а что бы я делал на месте этой знаменитости? Ох, вот я бы деньги потратил на это, а если потом сделал бы вот то. И ещё это. А если бы ещё уметь летать и обладать суперсилами! Да, было бы отлично!

Вот, значит, Фейсбук построил свою платформу на таких-то технологиях и она масштабируется на миллиард пользователей… Ну мы же не хуже, и технологии доступны, давайте тоже всё делать хорошо, с заделом на миллиард пользователей (хотя пока их сотня). Разработчики ПО — тоже люди, и они тоже поддаются фантазиям. Она была в способности дать людям нужный продукт в нужное время и в нужном месте. Но магия Фейсбука была не в технологии масштабирования на миллиард пользователей. Он создался лишь тогда, когда стал нужен и лишь таким, каким был нужен. Софт, способный отмасшабироваться на миллиард юзеров, был побочной и менее важной частью компании.

У медали есть две стороны:

а) Достижение роста — более сложная задача, чем поддержание достигнутого масштаба
б) Большинство исключительно квалифицированных и талантливых программистов работают над продуктами, которым необходимо хорошее масштабирование

Подумайте сами — из всех когда-либо созданных софтварных компаний лишь, наверное, около 0. Пункт «а» легко осознать. Остальные рухнули раньше или удостоились меньшего. 05% достигли уровня миллионов пользователей и миллиардных прибылей.

05% компаний. Так вот, большинство фантазий на счёт необходимых в будущем фич ПО обычно сводятся именно к попытке решения проблем вот этих 0. Нет, вам не понадобится. «Вот будет у нас команда из 1000 разработчиков, 10 миллионов пользователей и с десяток больших корпоративных клиентов со своими сложными требованиями и вот тогда нам понадобится...». 95%. С вероятностью в 99.

Приходится переставать представлять себя владельцем нового Амазона и возвращаться к сегодняшним проблемам. Но сказать НЕТ столь заманчивым идеям тяжело — ведь это рушит веру в те самые доли процента вероятности успеха. Да, осознание текущего состояния дел может демотивировать. А сегодня у вас есть 50 пользователей, из которых 30 это семья и друзья.

Понятное дело, что лучшие программисты работают в топовых компаниях. Пункт «б» тоже не помогает справится с наваждением. Принцип Парето работает здесь против нас: лучше программисты пишут книги, выступают с докладами, проектируют лучшие системы. Либо потому, что создали их благодаря своему таланту, либо потому, что топовые компании способны нанять лучших программистов. Но большинству из нас не нужно думать о том, как построить такой кластер в нашей компании здесь и сейчас. Каждый из нас слышал от них эти захватывающие истории о распределённых на тысячи узлов отказоустойчивых кластерах, обрабатывающих петабайты данных с помощью ПО, оптимизированного до каких-то невероятных цифр производительности. Он просто не нужен.

Неужели нужно просто перестать думать о будущем? Так что же, закрыть глаза и представить свою компанию через 5 лет большой — не поможет?

Думать о будущем полезно. Конечно, нет. И проектировать ПО с заделом на будущее тоже полезно, но делать это нужно правильно.

Проектировать гибко, реализовывать неидеально

Лучше сделать меньше, но хорошо. Очень немногие продукты на самом деле удовлетворяют нужды своих покупателей. Такого, чтобы вы сделали А и 90% ваших пользователей было нужно именно А — никогда не будет. 90% ваших потенциальных пользователей нужно какое-то Б, а ваше А просто ближайшая альтернатива к Б, а самого Б никто не делает и не продаёт, так что какая-то часть покупателей удовлетворится синицей в руке.

Однажды заполучив покупателей, вы можете всё-таки попробовать понять, что же им было нужно на самом деле и со временем реализовать именно это. Что хорошо в этом сценарии? Пользовательская база помогает вам изучать рынок, находить на нём ниши и заполнять их. Ну или чуть лучшую альтернативу этому. Как только вы нащупываете эту нишу, начинаете работать в ней — тут и начинается ваш рост.

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

И вот на этом пути — чем меньше изначально была ваша кодовая база, тем легче её приспособить к чему-то новому.

«Я ненавижу код и хотел бы видеть как можно меньше его в нашем продукте» — Jack Diederich

Если вы сделали что-то идеально работающим — вы сделали это не верно. Вам пришлось по пути пойти на слишком большие жертвы. Возможно, это были затраты времени или денег, возможно, вы отказались от гибкости, возможно что-то ещё. Идеал не достигается бесплатно.

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

Оптимистический дизайн архитектуры ПО — будущее может приятно вудивить

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

Одним из общих страхов, ведущих к созданию подобных систем, является боязнь того, что в какой-то момент один ваш сервер не будет способен обслужить всех ваших пользователей. Давайте я расскажу об одном конкретном примере: проектировании распределённых систем в рассчёте на то, чтобы быть готовым к любому росту. Иногда. И это правда случается. Кроме того, большинство людей, пишущих софт в 2018 году, почему-то уверены, что он будет работать на серверах, созданных в 2005 году. Но не в маленьких компаниях, не в стартапах. Компьютеры становятся лучше с каждым годом и хорошие сервера можно арендовать не так дорого.

Давайте я опишу такой-себе начальный «настоящий» сервер:

  • Two Xeons E5–2680v4 (28cores & 56 threads, cloking at 2.4GHz to 3.3GHz)
  • 512 Gigabytes of DDR4–2400 RAM
  • 2 NVMe SSDs of 1.2TB each (~3GB/s read and ~1.5GB/s write each).

Да я готов поспорить, что половина существующих в мире распределённых систем запустится на этом сервере полностью, со всеми своими компонентами и зависимостями, обслуживая в штатном режиме всю их имеющуюся пользовательскую базу. А это далеко не самый крутой на сегодняшний день сервер. Такой можно взять за цену от 800 до 1300 долларов в месяц (смотря где брать). Вы можете арендовать десяток таких за зарплату одного квалифицированного инженера в Лондоне.

Что ещё хорошо в этом сервере, так это то, что цена его же аренды через 2 года упадёт в 2 раза.

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

А подумайте о всём том софте, который появляется и развивается вокруг. Но это мы говорим о железе. И посмотрите на сегодняшний мир — «окей, Гугл», «привет, Алекса», «какая сейчас погода, Сири?». Мало кто 20 лет назад всерьёз думал о голосовом управлении чем-то. Тот, кто начал писать голосовой фронтенд в 2016-ом году — как-раз успел к 2018-ому.

Ах, если бы я знал 🙂 Это что-то, что уже появилось на горизонте, но ещё не стало настолько большим, чтобы затмить собою солнце. Что же начинать писать в 2018-ом? Посмотрите вокруг, возможно, заметите что-то такое?

Совершенно незаметно с приходом WASM браузеры стали универсальными виртуальными машинами. Прогресс в ПО невероятен. И оно запустится везде. Через 2 года вы сможете собрать универсальное, сложное и высокопроизводительное приложение, скомпилировав его под ровно одну платформу: web assembly.

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

И некоторые из них весьма неплохи. Новые языки программирования появляются постоянно. В следующие 2 года я ожидаю увидеть, как Julia внесёт свою лепту в научное программирование. Лишь за последние 8 лет мы получили Go, Rust, Scale и D — все нашли свою нишу. Общая сумма технологий и знаний поражает неимоверно. И это только то, что волнует лично меня и за чем я слежу.

Но я отвлёкся...

Вдохновляться будущим относительно легко. Но, честно говоря, кроме линейного прогресса роста производительности — тяжело предположить, что случится через 2 или 5 лет. В воздухе витают какие-то идеи, команды работают над разными программными и аппаратными проектам, но что из этого «выстрелит»?

Что хорошо в настоящем — оно уже есть, оно наблюдаемо, измеряемо. Всё же, если вы хотите подготовить ваш софт к будущему, нужно для начала осознать настоящее. Сделать ваш софт соответствующим хотя бы сегодняшнему дню — уже неплохая идея. И оно ещё продержится некоторое время. Но софт, написанный с подходами, актуальными для 2018 года, может вполне себе неплохо работать и в 2020. Вы не будете готовы к реалиям 2020 года, используя подходы 2000-го.

Просто делайте это более правильно. Так что не отказывайте себе в удовольствии разрабатывать софт с заделом на будущее. Всё, что может быть спроектировано гибко, должно быть спроектировано гибко. Прикидывайте не только развитие вашего будущего продукта, но и развитие окружающей его экосистемы. И это убережет вас от затрат времени на подготовку к тому, чего никогда не случится. Это даст вам возможность манёвра в тот момент, когда вы узнаете в какую сторону этот манёвр должен быть совершен.

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

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

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

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

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