Создавайте инструменты для 99% разработчиков

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

Стоит ли переходить на serverless? Станет ли GraphQL решением ваших проблем с API? Нужно ли следовать новому плану DevOps для повышения надёжности системы? В мире технологических инструментов много ажиотажа. Однако он не всегда отражает повседневную реальность программистов.

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

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

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

Наши пользователи говорят нам (иногда несмело), что их рабочие процессы совершенно не походят на то, как они «должны» выглядеть. Для этих «разработчиков из тёмной материи», как их называет Скотт Хансельман из Microsoft, принятые в Facebook или Pinterest процессы работы не имеют никакого смысла. Потребности их пользователей отличаются, как и потребности их команд.

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

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

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

Просачивание инструментария сверху вниз

Миф

Из-за того, что непропорционально большое количество кода и инструментария возникает в компаниях наподобие Facebook, Netflix, LinkedIn, Google и Amazon, многие люди предполагают, что существует эффект просачивания технологий сверху вниз: великолепные инженеры из компаний, имеющих огромные ресурсы, придумают качественные решения проблем, которые рано или поздно появятся у всех. Рано или поздно обычный малый/средний бизнес или компания из списка Fortune 500 столкнётся с теми же проблемами, что и Amazon или Facebook.

Реальность

Компания уровня FAANG по множеству параметров отличается от малого бизнеса и компаний из Fortune 500, в том числе по необходимости масштабирования, дилеммой между созданием собственных и покупкой чужих технологий, а также по структуре команд разработчиков. 

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

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

Что с этим делать

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

У большинства компаний нет проблем с задержками, хранением данных и другими аспектами, которые бы вынудили их писать собственные компоненты и инструменты инфраструктуры, как, например, сделал Facebook с его хранилищем данных Tao и инструментом хранения данных Hive, и, скорее всего, у них не будет таких проблем, которые бы заставили их использовать подобные инструменты.

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

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

Большие технологические компании вкладывают много временных ресурсов во внутренние команды своих платформ, которые редко встречаются в других компаниях.

Пример: команда разработчиков мобильной платформы Uber выявили медленно работающие тесты, написанные моей командой и сообщили нам, что мы должны их исправить.

Задумайтесь об этой ситуации… https://t.co/gEZFVzvflW — Гергели Орош (@GergelyOrosz)

Золотого стандарта для среды разработки не существует

Миф

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

Реальность

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

Например, Spotify признала, что её хвалёный подход к DevOps невозможно было масштабировать после того, как размер команды достиг определённого уровня. Также мы видим примеры компаний, осваивающих новые популярные технологии, а затем возвращающиеся к старым, когда всё идёт не так, как запланировано — например, Segment вернулась от микросервисов к монолиту.

Что с этим делать

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

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

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

Ещё один маленький секрет: многое из того, что говорит большинство «разработчиков-инфлюэнсеров», достаточно умозрительно.

Их собственные компании не всегда делают всё так красиво, как эти инфлюэнсеры рассказывают другим.

Особенно справедливо это для крупных компаний, где культура в разных организациях/командах может сильно отличаться — Синди Сридхаран (@copyconstruct)

Цель — развитие, а не идеал

Миф

Слишком многие считают, что стремление к высокому качеству ПО означает, что вам нужно полностью освоить соответствующую новую технологию, будь то микросервисы, GraphQL или distributed tracing. Процесс не завершён, пока вы полностью не перешли на идеальную технологию.

Реальность

Сегодня из-за несоответствия состояния команд «реальных разработчиков» и популярных советов многие не знают, с чего начать процесс улучшения качества кода или надежности системы. БОльшую часть кода 99% разработчиков никогда не придётся масштабировать для организации из тысяч человек или для миллиардов пользователей. 

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

Цель — это не идеальный код, а код насколько надёжный и безопасный, насколько это возможно с учётом других ограничений. Например, если ваша компания не работает со множеством облаков и не деплоит сотни изменений в день, то система continuous delivery наподобие Spinnaker компании Netflix, скорее всего, окажется ненужной.

Что с этим делать

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

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

Но для большинства мелких и более молодых компаний реальное покрытие тестами будет гораздо меньше несмотря на показатели, к которым компания стремится. А благодаря развитию сервисоориентированных архитектур и внешних API (которые гораздо сильнее распространены за пределами Google) вполне приемлемой альтернативой традиционным техникам юнит-тестирования и интеграционного тестирования может оказаться тестинг в продакшене, где разумной может быть концепция «покрытие кода».

По словам соосновательницы Honeycomb Черити Мейджорс, для многих современных систем справедливо следующее: «После деплоя больше не нужно тестировать код, нужно тестировать системы — сложные системы состоят из пользователей, кода, окружения, инфраструктуры и времени».

Хорошее демо не является показателем качества инструмента

Миф

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

Реальность

Империи инструментов для разработчиков строятся на гифках и видеоклипах. Команды начинают вкладывать свои усилия в инструменты (иногда на долгие годы) спустя несколько минут демо. Инвесторы вкладывают деньги на основе демо. Разработчикам продукта говорят, что демо и первые 60 секунд его использования — переломные моменты в его судьбе. Однако хорошие результаты демо могут говорить о том, что продукт хорошо проявит себя в повседневном использовании, эти аспекты не всегда коррелируют.

Для вас не должно быть неожиданностью то, что основной основные мучения разработчика связаны не с тем, что происходит в первую минуту взаимодействия с инструментом. Во-первых, интеграция с повседневными рабочими процессами (например, с анализом имеющегося кода, процессами CI/CD и способами совместной работы) лучше показывает, окажется ли продукт хуже, чем его демо. 

К примеру, создателям инструментов для разработчиков хорошо известно, что интеграция с GitHub и GitLab поможет существенно повысить полезность и привлекательность инструмента.

Во-вторых, существуют целые классы инструментов, истинная проверка эффективности которых не происходит в первый день. Например, это отладчики. Инструментарий отладки является более критичным фактором для качества работы разработчика, чем среда разработки и среда CI/CD. 

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

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

Что с этим делать

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

• Воздержаться от восхваления инструментов исключительно на основании впечатлений от первого для использования.

• Воздержаться от использования новых инструментов в больших проектах, прежде чем вы или ваша команда разработчиков не приобретает длительный опыт повседневной работы с ними.

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

Благодаря этому появится гораздо больше возможностей для повышения простоты и скорости разработки.

От гетерогенности никуда не деться

Миф

Люди часто считают, что популярный новый язык или фреймворк — это всё, что существует в чужой системе. Разработчики и инфлюэнсеры превозносят новые инструменты как будто это единственные применяемые инструменты: например, микросервисные архитектуры, GraphQL или трассировка на основе OpenTelemetry. Евангелизм «единственно верного фреймворка» подразумевает, что организации могут полностью переключиться на этот новый язык, инструмент или фреймворк.

Реальность

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

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

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

Некоторые из этих организаций не ожидают, что смогут преобразовать всю свою кодовую базу. (Например, они планируют сохранить свой легаси-монолит наряду с микросервисами, или конечные точки REST и gRPC наряду с конечными точками GraphQL.) 

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

Что с этим делать

Покупатели ПО (разработчики, директоры или CIO) знают о существовании гетерогенности. Однако им стоит полностью осознать, что же это значит:

• Признать, что миграции будут медленными. Я сталкивалась со многими командами, считавшими, что их проблемы решатся, когда они завершат миграцию с устаревшего инструмента X на новый хайповый инструмент Y, каждый из которых существует с собственной экосистеме решений. К сожалению, миграция на инструмент Y может не закончиться, пока новым хайповым инструментом не станет Z, и теперь мы снова сталкиваемся с проблемой двух экосистем.

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

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

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

Например, инструмент, обеспечивающий удобство только для API GraphQL, возможно, будет не так просто расширить на другие виды API, особенно потому, что GraphQL содержит гораздо больше информации, чем REST или gRPC.

Другие типы инструментов разработки с лёгкостью расширяются на новые языки и фреймворки. SaaS-инструмент, который просто должен иметь возможность вызова из разных языков программирования, поддерживает гетерогенность языков, поскольку его базовые компоненты ядра не нужно преобразовывать для поддержки каждого нового языка.

Чтобы начать избавляться от недостижимых стандартов ПО, нужно сделать следующее:

• Перестать воспринимать ПО как решение исключительно представленное небольшой группой нетипичных компаний.

• Честнее рассказывать о «реальных процессах разработки ПО».

• Требовать решений практических задач!