«У 99% команд старый код и коробочные решения, нет бюджетов и DevOps, а мы слушаем инфлюенсеров из Facebook» Статьи редакции

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

Пересказ колонки основательницы фирмы-разработчика ПО Akita Software Джин Янг.

Бессерверные вычисления, язык запросов GraphQL, распределённая трассировка, DevOps-методологии — обо всём этом всё чаще говорят «технари». Однако эти и другие расхожие в 2020-х понятия не всегда отражают реальность, в которой работает 99% программистов, пишет основательница компании-разработчика ПО Akita Software Джин Янг.

По её словам, основной шум вокруг технических и продуктовых решений создают так называемые инфлюенсеры-разработчики — специалисты из быстрорастущих компаний вроде сервиса бронирования жилья Airbnb и финтех-стартапа Stripe или техгигантов биржи Nasdaq: Facebook, Amazon, Apple, Netflix и Google. Для последних даже придумали акроним — FAANG.

Многие в индустрии считают, что абсолютно все компании должны так или иначе стремиться стать хотя бы мини-версией этих технологических «китов». Однако эта философия в корне неверная, заключает Янг. У проектов поменьше совсем иные потребности, а ещё наверняка есть legacy-системы — устаревшие методы, технологии и код. Такое наследство обычно нелегко адаптировать к изменениям и масштабировать.

При этом компании, в которых работают эти «невидимые» 99% разработчиков, так их называет программист Microsoft Скотт Хансельман, необязательно бедствуют. Они строят сервисы и приложения для сфер страхования, медицины, торговли, банкинга, просто делают это тихо.

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

Зачастую на крупных отраслевых конференциях, в популярных блогах и социальных сетях высказываются технические специалисты из больших компаний вроде Facebook, Netflix, LinkedIn, Google и Amazon. Они говорят о том, какими бюджетами управляют и какие высокотехнологичные решения придумывают для проблем, с которыми однажды наверняка столкнётся малый или средний бизнес.

Однако у последних, как правило, другие потребности и возможности. У них может не быть целого штата тестировщиков, а также экспертов по наблюдаемости (observability) и эффективности разработчиков. И задачи, за которыми в компаниях вроде Facebook и Google закрепляют сразу несколько профильных команд, заниматься будут инженеры без нужных навыков.

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

То же касается и масштабирования. Facebook ежедневно генерирует 4 петабайт данных в день — это 1 млн Гбайт. И, конечно, чтобы хранить эти информационные массивы, компания построила свои цифровые склады Tao и Hive. А Neflix, чтобы эффективно работать сразу с несколькими облачными инфраструктурами, построила сервис непрерывной доставки Spinnaker, чтобы множеству команд было проще работать над одним кодом.

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

Разработчики из крупных технологических проектов нередко публично хвалятся своими успехами. Рассказывают, какие безупречные юнит-тестирования проводят и какой чистый у них код. Говорят, что их staging-среда — пространство, где обкатывают функции перед релизом, — на 100% повторяет основной продукт. И что придраться к их процессам реагирования на инциденты — например, кибератаки — просто невозможно.

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

А стриминговый сервис Spotify признал, что его гибкая методология разработки перестала работать, когда компании нужно было масштабироваться. За каждой областью функций она закрепил ответственную команду, формируя автономный мини-стартап. Руководил им менеджер по продукту, он же «гендиректор». Инженеры-разработчики при этом привязаны к одной группе не были, и ни в одной из команд не было технического директора, который бы мог следить за их работой.

Google может сколько угодно говорить, что образцовое покрытие кода — когда тестирование запускает сценарии в коде — только 90% и более. Но чаще всего добиться высоких показателей невозможно, ровно как предсказать, как «поведёт» себя код в итоге.

Как сказала соучредительница фирмы-разработчика ПО Honeycomb Чарити Мейджорс, после развертывания ИТ-отдел тестирует не код, а сложную систему — из пользователей, самого кода, окружающей его среды, инфраструктуры и временных отрезков.

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

По её словам, проекты часто рассчитывают перейти на новую систему в условном «следующем квартале и лишь потом понимают, что процесс это продолжительный — даже для слаженных команд. А для тех «невидимых» 99% он может в принципе тянуться вечность — если речь о переходе, например, на микросервисную архитектуру.

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

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

#программирование #продукт