6 уроков, которые я извлек из разработки проектов с открытым исходным кодом

Взгляд специалиста по данным

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

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

За последние несколько лет мне посчастливилось заниматься открытым исходным кодом, и у меня была возможность разработать и поддерживать несколько пакетов!

Разработка открытого исходного кода — это больше, чем просто кодирование

За это время пришлось преодолеть множество препятствий и извлечь уроки. От сложных зависимостей и вариантов дизайна API до общения с базой пользователей.

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

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

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

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

Поверьте мне, написание хорошей документации — это само по себе навык.

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

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

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

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

Сообщество открытого исходного кода — это действительно больше, чем просто сумма его частей.

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

Независимо от того, будет ли ваш пакет использоваться миллионы раз или всего несколько раз, его создание — это отличная возможность узнать больше об открытом исходном коде, MLOps, модульном тестировании, проектировании API и т. д. Я узнал больше об этих навыках при разработке открытого исходного кода. чем я бы это сделал в своей повседневной работе.

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

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

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

Это определенно помогает, если у вас есть внутренняя мотивация, но все равно требуется немало времени, чтобы убедиться, что все держится вместе.

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

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

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

Как специалисты по данным, мы должны сначала понять, что именно мы измеряем. Звезды GitHub — это не что иное, как пользователь, дающий звезду пакету. Это даже не означает, что они использовали программное обеспечение или что оно действительно работает!

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

Например, будет здорово, если ваши пакеты будут представлены на Hacker News но он не говорит вам, постоянно ли он используется.

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

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

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

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

Все вышесказанное часто приводит к простому, но важному правилу;
Держите это очень просто

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

Если вы, как и я, увлечены искусственным интеллектом, наукой о данных или психологией, пожалуйста, добавьте меня в список. LinkedIn или подписывайтесь на меня Twitter. Вы также можете найти часть моего контента на моем Персональный сайт.

Все изображения без указания источника созданы автором.

6 уроков, которые я извлек из разработки проектов с открытым исходным кодом https://towardsdatascience.com/feed

<!–

->