Разработка на основе DevRel

DevRel Driven Development (разработка на основе DevRel) стимулирует разработку программного обеспечения благодаря адвокатской деятельности по защите интересов разработчиков, такой как создание документации, написание сообщений в блогах и изготовление видео. Адвокаты разработчиков (дев-адвокаты) часто выявляют недостатки публичного интерфейса при создании контента. Они могут тесно сотрудничать с разработчиками, создавая наиболее интуитивно понятные API и предоставляя конечным пользователям лучший опыт разработки.

При правильном подходе DevRel Driven Development создает симбиотическое сотрудничество между основными разработчиками, дев-адвокатами и конечными пользователями. Такой плодотворный цикл мотивирует разработчиков и радует конечных пользователей. Разработчикам нравится создавать элегантные API, которые быстро осваиваются пользователями. Хороший дев-адвокат поможет разработчикам создать подходящий интерфейс.

В этом посте объясняется, как осуществлять DevRel Driven Development, и приводятся реальные примеры, чтобы вы могли увидеть процесс в действии.

Создание и улучшение документации

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

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

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

Если у проекта нет документации, то вы можете задать вопрос следующим образом:

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

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

Скорее всего, после нескольких итераций вы добавите в документацию новые разделы и реорганизуете содержание. В конечном итоге вы обнаружите некоторые пробелы и неинтуитивные API, и именно тогда вы сможете начать предлагать новые функции.

Исправление ошибок (фиксинг багов)

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

Давайте посмотрим на реальном примере, как DevRel Driven Development может быстро устранить ошибки и добавить новые возможности.

Я просматривал документы delta-rs и создал блокнот Jupyter, для того, чтобы другие разработчики могли легко следовать за мной.

Я попытался создать Delta Lake с delta-rs, но столкнулся с неожиданной ошибкой при чтении Delta Lake. Я подал отчет об ошибке, и разработчик delta-rs исправил проблему в течение дня. Оказалось, что тестовый пакет проверял только абсолютные пути, а код не работал для относительных путей. Я переключил блокнот на абсолютные пути и продолжил создание демонстрационного блокнота.

Демо-блокнот помог мне понять, что некоторые фичи еще не реализованы.

Заполнение пробелов

Delta Lake допускает принудительное применение схемы, что предотвращает добавление файлов с другой схемой в Delta Lake.

Я заметил, что в демонстрационном блокноте принудительное применение схемы не работает, и сообщил об этом разработчикам delta-rs в Slack. Они заметили, что произошла оплошность, создали соответствующую задачу и быстро исправили ошибку.

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

Предложение интерфейсов

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

Я попытался очистить Delta Lake с delta-rs и обнаружил, что нет способа обойти проверку срока хранения. Вы можете обойти это ограничение с обычным Delta Lake, установив config("spark.databricks.delta.retentionDurationCheck.enabled", "false") при создании SparkSession. Один из разработчиков delta-rs предложил добавить параметр enforce_retention_duration=True в DeltaTable.vacuum(). Я возразил в ответ, предложив добавить этот параметр как retention_duration_check_enabled=True, чтобы мы соответствовали вордингу Delta Lake.

Результатом здравого обсуждения оптимального интерфейса, вероятно, станет API, интуитивно понятный для пользователей.

Дев-адвокаты могут перейти на новый уровень, подавая пул-реквесты для реализации своих предложений.

Пул-реквесты DevRel

Я пишу книгу Dask: The Definitive Guide и создаю множество небольших Dask DataFrames в примерах книги.

Я создавал Dask DataFrames следующим образом:

import pandas as pd

pandas_df = pd.DataFrame(
    {"num1": [1, 2, 3, 4], "num2": [7, 8, 9, 10]},
)
df = dd.from_pandas(pandas_df, npartitions=2)

Этот синтаксис сбивает пользователей с толку. Они удивляются, что им необходимо выполнить  import pandas для создания небольшого Dask DataFrame.

Я предложил добавить следующий интерфейс, чтобы избежать импорта pandas:

import dask.dataframe as dd

ddf = dd.DataFrame(
    {"num1": [1, 2, 3, 4], "num2": [7, 8, 9, 10]},
    npartitions=2,
)

Публичный интерфейс Dask DataFrame разработан для имитации API pandas, и один из основных разработчиков Dask предложил метод класса from_dict, как в pandas:

dd.DataFrame.from_dict(
    {"num1": [1, 2, 3, 4], "num2": [7, 8, 9, 10]}, npartitions=2
)

Я создал пул-реквест, чтобы добавить эту возможность. Мне не довелось внести значительный вклад в Dask, и в итоге я объединился с одним из основных разработчиков Dask, чтобы довести пул-реквест до состояния, пригодного для мерджинга.

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

Дев-адвокаты, конечно, могут принести большую пользу проекту, даже если они не пишут никакого кода.

DevRel поддержка

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

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

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

Теперь перейдем к основному преимуществу дев-адвокатуры - стимулированию использования и внедрения.

Стимулирование использования с помощью контента

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

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

Инженеры с гораздо большей вероятностью поддержат DevRel Driven Development, если почувствуют, что дев-адвокаты добавляют ценность проекту. Вы можете активно делиться показателями работы дев-адвокатов (просмотры страниц, клики по кнопкам и т.д.) с разработчиками, чтобы помочь им оценить ценность вашего вклада в проект.

Заключение

DevRel Driven Development - это отличный способ для дев-адвокатов установить прочные связи с разработчиками основных библиотек и конечными пользователями и стимулировать внедрение технологий. Это более активный тип адвокатской деятельности, который требует от вас приложить собственные усилия, вместо того чтобы подбадривать со стороны.

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

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

Инженеры-программисты могут оказаться в ловушке, когда 99% своего времени тратят на программирование и только 1% - на создание README, документации и SEO-оптимизированного контента для конечных пользователей. Трудно привлечь пользователей, если материалы и сообщения не соответствуют требованиям. DevRel Driven Development способствует тому, что инженеры тратят немного больше времени для создания потрясающего пользовательского опыта, а это отличная возможность, которая поможет клиентам влюбиться в их замечательный код.

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

• Зарегистрироваться на бесплатный вебинар