Как студенту может помочь участие в Open-source проекте

Автор статьи: Илья Дубинин
Редакция: Даниил Ярославцев, Роман Иванов

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

Как студенту может помочь участие в Open-source проекте

Перед современными выпускниками ВУЗов стоит актуальная проблема: без опыта работы сложно найти работу для получения того самого опыта. Для программистов есть путь выйти из этого круга - участие в небольшом open-source (далее просто OS) проекте.
Я не буду заниматься изобретением совершенно нового велосипеда о том как получить опыт, просто покажу, что это не сложно на своем опыте.

Итак, как участие в OS проекте помогло мне в изучении java и принципов программирования вообще.

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

Рассмотрим же полезность данного метода само(хотя и не совсем)-обучения.

<HABRA_CUT>

1) Критика

Первым пунктом опишем постоянную процедуру code-review. Это, понятное дело, стимулирует писать более приемлемый код (в университете, при выполнении курсовых и лабораторных работ, к сожалению, всем глубоко наплевать на то, какой код Вы пишете), так как данная процедура предполагает постоянную критику (которая, разумеется, полезна) и всегда хочется писать лучше и лучше, и получать её всё меньше и меньше. Следовательно человек запоминает уже изученные грабли и перестает на них наступать. Со временем.

2) Не хочется выглядеть глупым

OS сам собой предполагает, что Ваш код будут видеть люди. Возможно один человек, а может быть и тысячи. Кто знает, чего Вы добьетесь (и, соответственно, каким будет размер вашей “аудитории”). Сомневаюсь, что хоть кому-то хочется выглядеть глупым и показывать своё непонимание некоторых методов решения проблемы. Приходится лезть в книжки, разбираться более глубоко в используемых средствах, особенностях языка и способах применения того или иного инструмента.

3) Мотивация

Конечно, большинству людей хочется чего-то добиться. Участие в OS проекте дает Вам возможность попасть в список разработчиков того или иного проекта. Пусть это будет мотивировано тем, что Вы сможете предъявить на дальнейшем собеседовании в приличную фирму, желанием похвастаться перед друзьями, или просто удовольствием от того, что Вы чего-то уже добились - в любом из случаев это располагает к участию в проекте. Также (особенно для тех, кто сейчас возможно приготовил камень и прицелился, так как программированием занимается ТОЛЬКО ради удовольствия) нельзя забывать о том чувстве, которое по-началу возникает, когда принимают Ваш  pull-request.

4) Изучение технологий

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

5) полученный опыт в практике написания кода

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

6) Работа в команде

В каждом, даже самом простом open-source проекте обязательно присутствует такой полезный фактор, как работа в команде. Полезный по нескольким причинам:

Во-первых, работа в команде помогает научиться грамотнее объяснять свои действия (либо помогает научиться писать такой код, чтобы он был понятен без необходимости вообще что-либо объяснять)

Во-вторых, только при командной работе можно по-настоящему научиться использовать и “прочувствовать в работе” различные средства облегчения совместного труда разработчиков: системы сборки / контроля версий / анализа кода и т.д.

Если работать приходится в OS проекте, то и средства для его разработки приходится выбирать open-source-ные (ну, или, хотя бы, просто бесплатные).

Благо, что OS сообществом для “бесплатного” программирования предоставляется уйма полезных систем, таких как, например, Maven и VCS. Поэтому остается только получить опыт командной OS разработки для того, чтобы стать первоклассным, и, что самое главное - “бесплатным” (по части используемых технологий) специалистом. 

Знание и умение применять любые средства и технологий в жизни программиста приходит ТОЛЬКО с личным опытом, причем, намного быстрее - с КОМАНДНЫМ опытом. Опыт работы в команде, таким, каким он должен быть, не даст ни один современный  университет. Поэтому возможность получить такой опыт дорогого стоит, особенно, если ты студент )

7) Учимся читать чужой код и работать с ним

Немаловажным плюсом является возможность изучать чужой код, знакомиться с решением проблемы различными способами, предложенными людьми, которые имеют больше опыта. Также доступ к коду всего проекта дает возможность разобраться в его работе, пошагово просмотрев его выполнение (ну у или не всего проекта, а какой-нибудь его части, работу которой Вам интересно было бы разобрать глубже) даже если вы пишете маленький и очевидный модуль к большому проекту.

Итак, что же можно получить (что получил я) от работы с OS проектом:

- я являюсь автором моего кода, моё имя в javadoc

- проект простой, отличный старт для начинающих

- понимание и практика VCS (git)

- опыт работы в команде, несколько студентов делают изменения в одно время

- всё это я могу делать в удобное для меня время не мешая учебе и личной жизни

- работу с куратором проекта

- code-review и ответы на вопросы “почему надо именно так?” в skype/mail

- UTesting (100% покрытие кода тестами) и ручное тестирование на реальных проектах (Spring, Hibernate, ...)

- изменение wiki страничек проекта для помощи новым членам команды

- получение опыта вклада в проект

- работа с issue tracking system (SourceForge, GitHub)

- работа полностью осуществляется под Linux (Ubuntu), куратор, при необходимости, помогает с возникшими при миграции с Windows вопросами. Дополнительно возможны советы по использованию Eclipse

- теперь у меня есть что приложить к моему резюме(CV). Я не боюсь показать мой код для оценки стиля написания и моего опыта (доказательство, глава "Код, Блог, Статьи, Книги ")

- я начинал с начального уровня знаний Java, руководитель проекта помог мне сфокусироваться на нужных книгах, статьях. Я могу задавать вопросы на интересующие меня темы. Также руководитель может задавать интересные вопросы, чтобы копнуть глубже

- мой код не применяют к общему репозиторию, пока руководитель видит его неидеальным - всё просто

- Во время автоматизации я запомнил на всю жизнь (как на доске в 3-м классе прописать одно предложение много много раз) как не надо писать код, но теперь я помогу себе, как и другим людям не делать ошибки. Надеюсь эта работа не пропадет зря.

- я могу использовать свои наработки в других проектах - код открыт

- моя работа используется дальше, а следовательно время потрачено не зря

- надеюсь я могу гордиться моим кодом :)

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

- работа с утилитой статического анализа кода поможет мне избежать “Хорошо известных” проблем, знания о которых я мог бы получить за 3-5 лет опыта

- в моем случае стало возможным работать на проекте во время летней практики университета в офисе с разработчиками компании Reveredata. Это увеличивало скорость решения проблем и ответов на вопросы....пример

- это дало мне материал для написания данной статьи на Habrahabr для получения доступа к ценному ресурсу.

Небольшое описание тех немногочисленных чеков, которые сделал я:

AvoidDefaultSerializableInInnerClasses - предостерегает Вас от реализации интерфейса Serializable во внутренних нестатических классах без переопределения в них методов readObject() и writeObject().

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

ForbidCCommentsInMethods - уведомляет при нахождении многострочного комментария в теле метода (большое количество текста внутри метода может отвлекать от чтения его сути, и зачастую показатель того, что метод не правильно структурирован, либо кто-то использует комментарии вместо GIT, пишет слишком много, что тоже может указывать на неполное понимание автором того, что он пишет).

В заключение хотелось бы сказать, что Open Source - это круто. Он помог мне в повышении моего уровня знаний и умений.  Не бойтесь участвовать и помогать развиваться проектам. Кто если не Вы? Наш проект - http://sevntu-checkstyle.github.com/sevntu.checkstyle/ . Если у вас нет опыта - не проблема, вашего желания должно хватить. Даже маленький модуль будет очень полезен - ваша помощь нужна. Хватит сомневаться и стесняться - выбери проект и сделай что то полезное!

Предыдущие статьи разработчиков нашего проекта: тут, тут, тут.

PS: прошу в комментариях не советовать посмотреть на  FindBug, PMD, Sonar, Eclipse (Java>Compiler>Error\Warnings) ... я умышленно опустил их упоминание, чтобы не раздувать статью. В добавок эти проекты не просты для понимания человеком без опыта, а мне как раз нужно было что-то простое.

habrahabr sandbox.