6 уроків, які я отримав під час розробки проектів з відкритим кодом

Погляд дослідника даних

Відкритий код – це така дивовижна концепція! Об’єднавши джерела, навички та знання цілої спільноти, можна створити інструменти, які ми не змогли б створити окремо. Інструменти, які є результатом цієї співпраці, справді є більше, ніж сума їх частин.

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

Протягом останніх кількох років мені пощастило бути залученим до open-source і мав можливість розробити та підтримувати кілька пакетів!

Розробка відкритого вихідного коду — це більше, ніж просто кодування

За цей час було багато перешкод, які потрібно було подолати, і уроків, які потрібно було вивчити. Від хитрих залежностей і вибору дизайну API до спілкування з базою користувачів.

Робота з відкритим вихідним кодом, як автор, супроводжувач чи розробник, може бути дуже складною! У цій статті я ділюся деяким своїм досвідом у цій галузі, який, сподіваюся, допоможе тим, хто хоче розвивати відкрите програмне забезпечення.

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

Однак не варто недооцінювати вплив документації на зручність використання вашого пакета! Ви можете використовувати його, щоб пояснити складні алгоритми, надати розширені навчальні посібники, показати випадки використання та навіть дозволити інтерактивні приклади.

Особливо важко зрозуміти програмне забезпечення, пов’язане з наукою про дані, якщо воно включає складні алгоритми. Підхід до цих пояснень як до історії часто допомагав мені зробити їх більш інтуїтивно зрозумілими.

Повірте мені, написання якісної документації – це вже сама по собі навичка.

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

Однак створення документації — це більше, ніж просто її написання. Візуалізація вашого алгоритму або програмного забезпечення значною мірою робить його інтуїтивно зрозумілим. Ви можете багато чому навчитися Джей Аламмар коли ви хочете візуалізувати алгоритмічні принципи у своїй документації. Його візуалізації навіть потрапили в офіційну Пустотливий документація!

Ваша база користувачів, спільнота, є важливою складовою вашого програмного забезпечення. Оскільки ми розробляємо open-source, можна з упевненістю сказати, що ми хочемо, щоб вони брали участь у розробці.

Залучаючись до спільноти, ви спонукаєте їх ділитися проблемами та помилками, а також надсилаєте запити на функції та чудові ідеї для подальшого розвитку! Усе це допомагає створити щось для них.

Спільнота з відкритим кодом — це справді більше, ніж сума її частин

Багато основних функцій у BERTopic, наприклад моделювання теми онлайн, були впроваджені, оскільки вони були дуже затребувані його користувачами. Як наслідок, спільнота є досить активною та надає величезну допомогу у виявленні проблем і розробці нових функцій.

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

Також існує величезна можливість отримати знання від взаємодії з самою спільнотою. Саме вони підказують, який дизайн їм подобається, а який ні. Часом я бачив, як одна й та сама проблема виникала кілька разів протягом кількох місяців. Це означає, що мені слід переглянути дизайн, оскільки він не був таким зручним для користувача, як я очікував!

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

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

Це безперечно допомагає, якщо у вас є внутрішня мотивація, але все одно потрібно досить багато часу, щоб переконатися, що все тримається разом.

На щастя, ви можете звернутися до своєї спільноти, щоб допомогти вам, відповідаючи на запитання, демонструючи випадки використання тощо.

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

Знання того, як часто використовується ваш пакет, надзвичайно допомагає зрозуміти, наскільки він популярний. Однак багато хто все ще використовує зірки Github, щоб прирівняти пакет до якості та популярності.

Як дослідники даних, ми повинні спочатку зрозуміти, що саме ми вимірюємо. Зірки GitHub — це не що інше, як користувач, який дає зірочку пакету. Це навіть не означає, що вони використовували програмне забезпечення або що воно справді працює!

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

Наприклад, чудово, якщо ваші пакунки будуть представлені Hacker News але він не повідомляє вам, чи він постійно використовується.

Як психолог я, як правило, приділяю значну увагу дизайну своїх упаковок. Це включає такі речі, як документація та навчальні посібники, але це навіть перекладається на те, як я кодую.

Переконайтеся, що пакет простий у використанні та інсталяції, що значно спростить впровадження. Особливо коли ви зосереджуєтеся на таких філософіях дизайну, як модульність і прозорість, деякі пакети стають приємними для використання.

Розглядаючи погляди психолога під час розробки нових функцій, було набагато простіше знати, на чому зосередитися. Що шукають користувачі? Як я можу кодувати таким чином, щоб пояснити алгоритм? Чому користувачі насправді використовують цей пакет? Які головні недоліки мого коду?

Витрачення часу на те, щоб зрозуміти середнього користувача, стимулює прийняття

Все вищезазначене часто призводить до основного, але важливого правила;
Будьте надзвичайно простими

Особисто я вважаю, що новий пакет важко встановити та використовувати, я з меншою ймовірністю прийму його в своєму робочому процесі.

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

Усі зображення без джерела були створені автором

6 уроків, які я навчився під час розробки проектів з відкритим вихідним кодом Перепубліковано з джерела https://towardsdatascience.com/6-lessons-i-learned-from-developing-open-source-projects-4617e26f247c?source=rss—-7f60cf5620c9—4 через https://towardsdatascience.com/feed

<!–

->