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

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

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

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

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

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

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

Недавно я писал статью ^[1] о воображаемых проблемах — тех, решением которых люди развлекают себя, ведь их решать интереснее, чем реальные. Сюда же можно отнести и вот эти попытки предвидеть будущее. Даже можно сказать больше — это любимая воображаемая проблема большинства маленьких начинающих компаний.

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

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

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

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

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

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

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

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

Но сказать НЕТ столь заманчивым идеям тяжело — ведь это рушит веру в те самые доли процента вероятности успеха. Приходится переставать представлять себя владельцем нового Амазона и возвращаться к сегодняшним проблемам. А сегодня у вас есть 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. И оно запустится везде.

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

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

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

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

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

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

Автор: tangro

Источник ^[2]