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

Патрик T. Альтман, вице-президент по технологиям, Eldarion

Photo of Patrick AltmanПатрик Альтман (Patrick Altman) — главный разработчик Pinax, принимавший участие во многих других проектах с открытым исходным кодом. В настоящее время он является вице-президентом по технологиям компании Eldarion. До этого был главным инженером-программистом StudioNow, проданной впоследствии компании AOL. В настоящее время живет в Нэшвилле в штате Теннесси с женой и тремя детьми.



04.12.2012

Экосистема проектов ПО с открытым кодом на языке 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.

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

  • pyflakes
  • pylint
  • pep8

В разделе Ресурсы есть ссылки на эти инструменты.

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

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

$ pyflakes kaleo
kaleo/forms.py:1: 'form' imported but unused
kaleo/forms.py:4: undefined name 'forms'
kaleo/forms.py:6: undefined name 'forms'

Инструмент сразу указывает на опечатку в операторе импорта. Заглядывая в kaleo/forms.py, видим:

1: from django import form
2: 
3: class InviteForm(forms.Form):
4:    email_address = forms.EmailField()

...то есть строку 1 надо заменить на from django import forms.

Тесты

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

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

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

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

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


Сопровождение

После выпуска первой версии Python Package Index (PyPI) и объявления о нем во всевозможных твитах и блогах проект начнет привлекать пользователей, и вам придется к своей творческой деятельности добавить работу по сопровождению. Пользователи будут сообщать об ошибках, спрашивать о функциональных возможностях, задавать вопросы, не освещенные в документации, и т.п.

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

Управление исходным кодом

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

Запросы на внесение изменений

Запрос на внесение изменений (pull request) ― это сообщение, направленное в другие ветви — обычно родительскую ветвь — репозитория, с предложением владельцу этого репозитория принять пакет изменений, или коммитов. Процесс запроса на внесение изменений способствует кооперации и сокращает расходы на сотрудничество, так что цикл инноваций может ускориться.

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

Версии для разработчиков

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


Поддержка

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

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

IRC

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

Список рассылки

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

Twitter

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


Заключение

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

Ресурсы

Научиться

Получить продукты и технологии

  • Существует множество линтеров. В число наиболее популярных входят pyflakes, pylint, а также контролер стиля Python pep8.
  • Существует несколько онлайн-инструментов, облегчающих работу по составлению документации к проекту. Два из них – это Sphinx и Read the Docs.
  • Замечательные DVCS: git и Mercurial.

Обсудить

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



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

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Open source
ArticleID=848513
ArticleTitle=Создание успешных проектов Python
publish-date=12042012