2009-05-11 7 views
5

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

Вот некоторые вещи, о которых я могу думать, вы можете предложить других?

  • хранилище контроля версий (что вы используете, чтобы объяснить соответствующие метки/филиалы? Внешний README файл?)
  • включить в коде соответствующих open-source license
  • включают расфасованный исполняемый JAR-файл, в том числе номера версии в имени файла
  • какой-то файл README, который объясняет внешние зависимости, необходимые для создания/запуска программного обеспечения (существует ли общее соглашение о том, какое имя файла и где его поставить?)
  • веб-страница проекта, с ссылкой на нее в исходном коде и/или ex в случае, если кто-то сначала получит исходный код или исполняемый файл (а не через веб-страницу)

ответ

0

Создайте ChangeLog из комментариев для проверки. Отдельно создайте примечание к выпуску, объясняющее, что вы исправили/добавили в каждую версию.

+0

примечания разработчика от комментариев разработчиков бесполезны. Они бессмысленны, если вы не разработчик. Если да, то система SCM должна сообщить вам информацию. –

6

Одна вещь, которую вы обязательно должны сделать (потому что это Java) - генерировать Javadocs для вашего кода. Это означает комментирование классов и методов с использованием нотации Javadoc для упрощения чтения для других.

3
  1. План разработки определенного типа веб-сайта. Если ваш код включает веб-программное обеспечение, люди действительно удивляются, если вы используете его как часть своего сайта.

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

  3. Наличие вики-настройки, позволяющей людям писать идеи и рецепты, является определенным плюсом. (Я рекомендую MediaWiki).

  4. Форум, посвященный идеям, темам дискуссий, т. Е. Форуму сообщества, также хорош.

  5. Настройте список рассылки и призывайте людей присоединиться.

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

1

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

Вы можете так же использовать Vulcan или так для непрерывного inetgration, так как известно whetaher текущая версия действительно работает или нет.

5

Вы также можете использовать Maven для выпуска кода. С ним довольно легко создать сайт для вашего проекта, указать зависимости, оптимизировать выпуски ... Например, проекты Commons в Apache используют Maven.

4

В принципе, вы хотите, чтобы ваш проект работал «из коробки». Когда люди выбирают правильный проект с открытым исходным кодом для задачи, они загружают кучу проектов, которые говорят, что поддерживают эту задачу, и используют лучший. Если для проекта требуется значительная работа по настройке (например, загрузка 20 JAR-зависимостей из 20 разных сайтов), большинство людей будут либо пытаться использовать это как последнее средство, либо просто игнорировать его.

Repository: Вы можете попробовать новый репозитарий двигатель - как Mercurial или Git. Они облегчают развитие и облегчают слияние филиалов. Важно отметить, что выберите двигатель, который поддерживается вашей средой.

Зависимости: Вы должны использовать риде для государственных зависимостей, но этого не достаточно, либо использовать Maven для управления зависимостями, в этом случае вам просто нужно включить pom.xml файл, или включать в себя JARs, что вы в зависимости от вашего распределения. Во втором случае делят зависимости на mandatory, optional, compiletime и test. Примером дополнительной зависимости являются инструменты генерации байт-кода для Hibernate.

Сайт: Maven может create a site, связанный с конкретной версией вашего программного обеспечения (никогда не использовал это).

Documenation - JavaDoc: Документ все, и попытаться провести в жизнь политику, которая обеспечивает высокое качество Javadocs:

/** 
    * Sets the cost 
    * @param decimal cost 
    */ 
public void setCost(BigDecimal decimal){ 

бесполезно. Лучше:

/** 
    * Sets the cost, cost is in currency setted by #setCurrency. 
    * @param decimal cost, precision shoule be at least three places 
    */ 
public void setCost(BigDecimal decimal){ 

Документация: Javadoc не достаточно. Дайте некоторую отправную точку - предпочтительный учебник (и я не имею в виду учебник со многими скриншотами диалогов eclipse;)). Пример кода тоже в порядке или, по крайней мере, где-то писать - «Чтение javadoc класса EntryPoint - хороший способ начать использование этой библиотеки». Если у вас есть только javadocs, любой, кто рассматривает возможность использования вашей библиотеки, будет представлен список всех кланов и пакетов и не будет знать, с чего начать.

Bugtracking Software: Вы не будете помнить больше о трех ошибках за раз (и забудете о них) - также это поможет вам управлять задачами и новыми желаемыми функциями. Вы можете попробовать:

  • FogBugz - его хорошо, но стоит денег. (Бесплатно для двух разработчиков).
  • Bugzilla - красивый, популярный и бесплатный

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

  • dotProject - бесплатно и OK.
  • FogBugz - снова отлично работает.

Попробуйте пройти Joel test

процесс сборки: Сделайте процесс сборки одним щелчком мыши. Например, скрипт ant, который увеличивает номер версии, запускает maven-сборки, развертывает сайт и так далее. Стоит усилий!

: Хорошая идея, поможет поддержать.

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

1

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

Также: в аналогичной вене, создавая баннеры OSGi bundles - это просто означает добавление нескольких записей манифеста, ничего сложного - это еще одна хорошая вещь.

Оба этих элемента помогают другим легче добавлять зависимости к вашему пакету (если применимо) и могут помочь в принятии.

Некоторые больше вещей, чтобы рассмотреть следующие вопросы:

  • Явной схема номера версии (основная версия шишка для несовместимых изменений; младшей версии для дополнения с обратной совместимостью, или что-то подобное)
  • держать хороший релиз отмечает
  • Используйте систему отслеживания ошибок, если вы можете использовать ее легко (Codehaus, dev.java.net, SourceForce и т. Д. Все это предлагают)
  • Простая вики проекта для документации
  • Списки рассылки для обсуждения
Смежные вопросы