Open source проекты: Media Player Classic и SharpDevelop. Первые впечатления

в 15:49, , рубрики: c++, media player classic, open source

Нечто невообразимое творится в мире разработки: популярные программы, фундаментальные библиотеки выкладываются в open source. У обычных разработчиков появляется возможность вносить изменения в известные продукты. Вот и я, устав от ежедневной рутины, решил попробовать что-то новое, почувствовать полёт творческой мысли и приобщиться к великому. Говоря более простым языком, решил подключиться к какому-либо open source проекту.

Почему именно open source? Меня привлекает:

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

В этой статье я хотел бы описать первый опыт работы с двумя проектами: Media Player Classic — Home Cinema и SharpDevelop. Хотелось бы дать общие рекомендации по работе с open source проектом на начальном этапе. Статья не содержит полноценного анализа исходного кода или рекламы новой функциональности, в ней описаны лишь первые впечатления о работе с проектами. Возможно, статья привлечет внимание разработчиков к описанным в ней проектам и к разработке open source в целом.

Media Player Classic — Home Cinema

Первым делом я заинтересовался программой Media Player Classic — Home Cinema (MPC-HC), свободным проигрывателем аудио- и видео-файлов для Windows. До сих пор считаю плеер одним из самых быстрых и удобных. Программа написана на C++, интерфейс разработан с помощью библиотеки MFC.

Исходный код программы находится на github’е, список активных задач ведется на отдельном багтрекере под управлением системы Track. Кроме того, можно в реальном времени пообщаться с командой разработчиков по IRC каналу. Для этого нужно учесть время, так как большинство разработчиков находятся в странах Европы (Германия, Франция, Нидерланды и др.).

Исходный код: github.com/mpc-hc/mpc-hc
Трекер задач: trac.mpc-hc.org
IRC чат разработчиков: webchat.freenode.net/?randomnick=1&channels=mpc-hc-dev&prompt=1&uio=d4
Официальный сайт: mpc-hc.org

Просмотрев список задач, я выбрал задачу #4328: нужно было добавить кнопку закрытия программы на основную панель программы для людей с ограниченными возможностями. Потратив пару часов, я добавил новую кнопку, проверил работу программы и создал pull request.

В комментариях к pull request’у разработчики написали, что такая кнопка не нужна. На вопрос, почему такая задача висит на трекере, мне ответили, что на трекере висит огромное количество задач, которые команда не смотрела из-за нехватки времени. Затем, прямо в комментариях развернулось обсуждение того что можно добавить к плееру: кнопку выхода из полноэкранного режима или окно предпросмотра на полосе прокрутки (а-ля плеер Youtube). К сожалению, обсуждение так и не дало конкретных результатов.

Как я понял, у проекта есть сформированный костяк из разработчиков, которые ведут активную разработку над своими задачами. Большинство задач, которые висят на трекере, находятся в неактуальном состоянии. В основном это feature request’ы от пользователей. На вопрос, какую задачу можно выполнить новому участнику, разработчики дать ответ не готовы, однако, если предложить новый функционал для плеера, разработчики могут привести аргументы против. Можно самостоятельно выбрать и выполнить любую задачу, однако, не будет никаких гарантий, что задача окажется актуальной и изменения будут смержены с основной веткой. Так что новому участнику подключиться к проекту весьма сложно.

Кстати, на компьютере так и осталась одинокая версия плеера с дополнительной кнопкой закрытия программы.

image

SharpDevelop

После неудачной попытки работы с MPC-HC, мой взгляд упал на SharpDevelop, открытую среду разработки для языков программирования на базе .NET. Проект разработан на C# .NET 4.5. Интерфейс программы разработан с помощью WPF и WinForms. На Хабре о возможностях программы написано уже достаточно много, не буду повторяться.

Исходный код продукта находится на github’е, список активных задач ведется там же. Можно написать письмо разработчикам на отдельном форуме, ответ приходит достаточно быстро, в течении 1-2 дней. Кроме того, есть build-сервер, с которого можно скачать актуальные бинарники программы или установочный пакет. Сборка выполняется с интервалом 2-3 дня.

Исходный код: github.com/icsharpcode/SharpDevelop
Форум: community.sharpdevelop.net/forums
CI сервер: build.sharpdevelop.net/BuildArtefacts
Официальный сайт: www.icsharpcode.net/OpenSource/SD

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

Поддержка системы контроля версий Subversion реализована в отдельном подключаемом модуле SubversionAddIn.dll, работа с Subversion выполняется с помощью библиотеки SharpSvn. Поддержка git также вынесена в отдельный модуль GitAddIn.dll, однако, работа с системой контроля версий уже выполняется через командную строку git.

Поддержка различных языков программирования также разнесена по отдельным подключаемым модулям: CppBinding.dll, CSharpBinding.dll, FSharpBinding.dll, VBBinding.dll.

Логика синтаксического разбора исходного кода вынесена в отдельный полноценный проект NRefactory. К сожалению, в отличие от проекта Roslyn, библиотека NRefactory не реализует компиляцию IL кода и разбор кода VB.NET.

Для начала я выбрал из списка задач ошибку под номером #606. После закрытия окна “Configuration Editor” (окно настроек конфигурации и платформы решения) выбранная конфигурация Debug или Release не становилась активной для всего решения. Исправив ошибку буквально одной строчкой кода, я создал pull request. Через пару дней мои изменения были применены к основной ветке проекта одним из разработчиков.

Затем я выбрал более интересную задачу под номером #96: необходимо было добавить окно для редактирования файла AssemblyInfo.cs по аналогии с Visual Studio. Теперь в свойствах проекта SharpDevelop появилась новая вкладка “Assembly Info” с полями ввода данных о свойствах сборки. По сравнению с диалоговым окном Visual Studio есть даже несколько нововведений: кнопка “New GUID” для генерации нового guid’а сборки и возможность включать/отключать JIT оптимизацию для сборки.

Работу с исходным кодом файла AssemblyInfo.cs я выполнил с помощью библиотеки NRefactory, упомянутой выше.
Через несколько дней мои изменения были смержены с основной веткой продукта без дополнительных комментариев. Меня это немного насторожило, так как я ожидал услышать замечания или пожелания по новой вкладке. Боюсь, что любой человек может замусорить проект: продублировать функционал или внести логику, отличающуюся от основной логики программы. Надеюсь, что это не так, и изменения разработчиков всё таки проходят какую-то проверку.

Ниже показан скриншот новой вкладки “Assembly Info”, которая уже появилась в бета-версии продукта 5.1.0.4954.

image

Общие рекомендации

Напоследок немного полезных советов начинающим open source разработчикам.

Выбор первой задачи

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

Оформление кода

Если говорить о правилах оформления кода C#, то они в основном нам уже давно продиктованы настройками ReSharper’a по умолчанию. Однако в разных проектах, по каким-то причинам, то и дело встречаются небольшие различия. Вот некоторые из них:

  • оформление приватных полей: префикс “_” или без префикса;
  • оформление констант: стиль UPPER_CASE или Паскаль;
  • using до объявления namespace’a или после;
  • повсеместное использование var.

Комментарии

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

Тексты лицензии

Если это необходимо, добавляем тексты лицензии в файлы с кодом. Для проекта SharpDevelop, например, начиная с 5 версии файлы с исходным кодом содержат текст лицензии MIT, а для проекта Media Player Classic — текст лицензии GNU GPL.

Отступы

В различных проектах также может различаться оформление отступов в коде: для Media Player Classic это пробелы, а для SharpDevelop — символы табуляции.

Общая логика работы программы

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

Проверка перед созданием pull request’а

После завершения работы над задачей и перед созданием pull request'a рекомендую выполнить тщательную проверку своих изменений.

Список измененных файлов

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

Сборка проекта

В идеальном случае нужно выкачать отдельную папку с решением из своего fork-репозитория и скомпилировать заново. Visual Studio со встроенной поддержкой git пару раз подводила меня: новые файлы с исходным кодом не добавлялись в список измененных файлов. Удостовериться в корректности изменений можно было только собрав проект из отдельно скачанной папки.

Сборка и выполнение тестов

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

Работа программы на различных операционных системах

Если Вы не уверены на все 100%, что написанный код будет работать на всех поддерживаемых операционных системах, лучше проверить работу программы на виртуальных машинах.

На этом у меня всё. В результате поиска и работы с open source проектами мне удалось не только найти новое увлечение, но и узнать для себя что-то новое. Дальше думаю продолжать работу с проектом SharpDevelop или же “брать штурмом” Media Player Classic. Возможно даже имеет смысл посмотреть в сторону других проектов, ведь их достаточно много: Roslyn, .NET Core, Entity Framework и многие другие.

Автор: RaTyS

Источник

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js