Створення успішних проектів Python

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

Співпраця чи кооперація?

На конференції DjangoCon-2011 Девід Івз (David Eaves) виступив з доповіддю, в якій красномовно висловив думку про те, що хоча співпраця (collaboration) та кооперація (cooperation) мають схожі визначення, між ними є тонка відмінність:

«Я б сказав, що за співпраці, на відміну від кооперації, учасники проекту мають вирішувати проблеми разом».

Згодом Івз присвятив цілу замітку тому, як GitHub став рушійною силою інновацій у роботі спільноти open source — зокрема, аспекту організації спільноти. У статті "Як GitHub врятував OpenSource" (див. розділ Ресурси) Івз стверджує:

«Я вважаю, що проекти open source працюють краще, коли учасникам надано можливість маловитратної кооперації, а високовитратнеспівробітництво зведено до мінімуму. Ідея open source полягає в тому, що від групи не потрібно загального обговорення кожного питання та колективна робота над вирішенням завдань, а навпаки».

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

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

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

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

Майстерність

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

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

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

Стиль листа та перевірка

В основу вашого проекту Python має лягти (або принаймні спрямовувати стиль проекту) докладний посібник зі стилю Python: Python Enhancement Proposal (PEP) 8 (див. розділ Ресурси). Не обов'язково зводити PEP 8 догму, але чим ближче ваша робота до PEP 8, тим легше буде іншим Python-розробникам вносити чисті доповнення, виконані в стандартному стилі спільноти Python.

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

У розділі Ресурси є посилання на ці інструменти.

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

Особливо кориснийлінтер - pyflakes. Він має багато можливостей, знаходить і виділяє помилки, але в той же час не перевантажений малозначущими функціями. Ось приклад сеансу з використанням pyflakes у Python-проекті:

Інструмент відразу вказує на друкарську помилку в операторі імпорту. Заглядаючи в kaleo/forms.py, бачимо:

. тобто рядок 1 треба замінити на from django import forms .

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

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

Документація

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

Використовуючи такі інструменти, як Sphinx та Read the Docs (див. розділ Ресурси), можна публікувати відповідні сучасним вимогам документи, які виглядають фантастично. Користуватися цими інструментами так само легко, як писати слова та відправляти комміти. Візьміть у звичку фіксацію змін у документації за допомогою комітів за кожного зручного випадку.

Супровід

Деякі речі ви вирішите не робити та запропонуйте обхідні шляхи; але щось треба буде виправити у документації та/або в коді. Застосовуючи розподілену систему управління версіями (DVCS), таку як git, і часто випускаючи пакети для розробника, можна зробити супровід набагато меншою рутинною роботою.

Управління вихідним кодом

Існує безліч варіантів DVCS, включаючи git та mercurial (див. розділ Ресурси). Яку б систему керування версіями ви не вибрали, переконайтеся, що вона дозволяє керувати вихідним кодом, так щоб користувачі мали можливість клонувати ваш проект і працювати над помилками самостійно.

Запити на внесення змін

Запит на внесення змін (pull request) - це повідомлення, направлене в інші гілки - зазвичай батьківську гілка - репозиторія, з пропозицією власнику цього репозиторію прийняти пакет змін або коммітів. Процес запиту на внесення змін сприяє кооперації та скорочує витрати на співпрацю, тому цикл інновацій може прискоритися.

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

Версії для розробників

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

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

Створення IRC-каналу, такого як freenode, - дуже гарна ідея. Я створив для свого проекту канал Nashvegas; і хоча там рідко зустрічається користувач, крім мене, мій IRC-клієнт працює непомітно у фоновому режимі. Коли випадковий користувач ставить запитання, я можу реагувати з малими транзакційними витратами і набагато швидше, ніж електронною поштою.

Список розсилки

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

Висновок

Написання програмного забезпечення з відкритим вихідним кодом та участь у роботі спільноти Python може бути цікавою та корисною справою. Зосередившись на скороченні дорогої співпраці за одночасного розширення можливостей для маловитратної кооперації, можна забезпечити зростання свого проекту завдяки активним учасникам. Open source ― це велика свобода для творчості під час роботи над своїм проектом: користуйтеся цим та насолоджуйтесь. Послідовне дотримання стилю кодування, надійні тести та добре складена документація підвищатьшанси на ухвалення вашого проекту користувачами та іншими розробниками. На додаток до цього застосовуйте DVCS, будьте уважні до запитів на внесення змін та часто публікуйте версії для розробників. Нарешті, інтерес до свого проекту та темпи його зростання можна підвищити ще більше, надавши кілька каналів підтримки та дозволивши спільноті допомагати вам у наданні цієї підтримки.