От джуна до сеньора: Как стать востребованным разработчиком

Open source

«With great power comes great responsibility»[1] – это, пожалуй, самое точное описание, которое можно дать open source проектам. В своей карьере вы совершенно точно столкнетесь (и уже сталкивались) с open source решениями, которые будете использовать на благо ваших проектов. Приложения, библиотеки, сервисы, компоненты, утилиты – все, что вы можете представить, и еще немного сверх того.

С точки зрения кода open source – это самый большой помощник, который у вас есть. Современная коммерческая разработка не терпит задержек и никого не ждет. Рынок диктует условия и сроки. Продукт, который не был запущен «прямо сейчас», через месяц окажется задавлен конкурентами или потеряет актуальность. Вы не можете позволить себе потратить жизнь только на то, чтобы написать свой веб-сервер, когда захотите завести себе небольшой сайт-визитку. Поэтому все разработчики приходят к open source, используют его, стараются делать лучше, участвуя в разработке открытых проектов, берут и отдают одновременно.

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

Правило № 1. Всегда проверяйте лицензию open source проекта, который хотите использовать. Это звучит как шутка (мы же говорим об OPEN source, эй!), однако вы должны уважать автора продукта и его правила игры. Нужно быть уверенным, что этот код разрешено применять в условиях вашего проекта. Обязательно сохраните упоминания об авторе и лицензии, если это требуется. Если лицензия для open source проекта не указана, не пожалейте нескольких минут на то, чтобы спросить автора напрямую или создать тикет с соответствующим вопросом. Этот пункт особенно важен, если вы работаете над коммерческим проектом. Лучше быть уверенным в лицензии заранее, чем, спустя полгода получив повестку в суд, пытаться переписать половину кода проекта.

Правило № 2. Выбирайте для своего проекта только проверенные и поддерживаемые open source компоненты. Если вы собрались добавить к своему проекту текстовый шаблонизатор, проведите анализ, составьте список библиотек, которые подходят по лицензии и удовлетворяют вашим требованиям. Убедитесь, что проекты достаточно развиты и над ними ведется работа. Проверьте, как авторы реагируют на сообщения от своих пользователей об ошибках и не оставляют ли их без внимания. Создайте proof of concept решение с использованием нескольких выбранных проектов, чтобы проверить, какой подходит вам больше всего.

Правило № 3. Следите за обновлениями open source проектов, которые используете. Пропущенное обновление безопасности может дорого вам стоить, во всех остальных случаях следует руководствоваться правилом «работает – не трогай». Нередко open source проекты предоставляют обновления без обратной совместимости, и ваш проект может выйти из строя, пока вы не проведете необходимую миграцию или не откатитесь до предыдущей версии компонента, который обновился.

Правило № 4. Не бойтесь «заглядывать под капот». Нередко наступает момент, когда вам становится непонятно, что именно происходит в той части системы, где используется open source решение. Не создавайте интригу: загляните в код (это все-таки open source!), попробуйте разобраться, что происходит не так, поднаберитесь новых идей. Чтение open source кода – замечательная практика, которая помогает знакомиться с новыми языками программирования, нарабатывать опыт интуитивного чтения кода, узнавать об оптимальных способах решения тех или иных проблем.

Правило № 5. Старайтесь участвовать в жизни проектов, которые используете. Open source сообщество живет разработчиками, их желанием создавать и делиться. Не упускайте возможность почувствовать это, заводите тикеты, участвуйте в обсуждении новых фич, внесите свой маленький вклад. Можно просто сказать спасибо, а если вы внезапно ощутили особый прилив любви к какому-то open source проекту – узнайте, принимают ли они донаты. Люди вкладывают в эту работу много сил и времени, им будет очень приятно, что вы оценили их труд.

Тезисы

■ «With great power comes great responsibility».

■ Проверяйте лицензию у любого open source проекта, который собираетесь использовать.

■ Выбирайте только качественные, проверенные временем и людьми проекты.

■ Следите за обновлениями, но не обновляйтесь без необходимости.

■ Изучайте код open source проектов, читайте его, старайтесь разобраться в том, как он работает.

■ Не только берите, но старайтесь и отдавать что-то open source сообществу, только так оно будет оставаться живым.

Задание

Найдите open source решения, которые используются на вашем проекте. Проверьте, актуальны ли они, как давно обновлялись, появилось ли в них что-то новое. Есть ли решения, уже отмеченные авторами как устаревшие и неподдерживаемые? Если да, попробуйте составить список альтернативных проектов, которыми вы могли бы их заменить. Попробуйте найти места в коде вашего проекта, которые реализуют что-то очень обычное (то, что можно было бы заменить на библиотеку). Проанализируйте, что может дать вашему проекту замена этого кода на open source компонент: станет ли проект гибче, получит ли новые возможности – или ваше решение не требует замены и работает слаженно именно с вашим проектом?

История из жизни

Из-за постоянной занятости у меня никогда не хватало времени на то, чтобы полностью участвовать в жизни open source, равно как и на то, чтобы писать открытые решения. Однако я все же пересилил себя и написал небольшой плагин к редактору VIM, который приводил текст комментария к табличному виду. Первый коммит на GitHub датирован 16 декабря 2012 года, а сам плагин на момент написания этой книги имеет целых (ух-х-х!) 42 звездочки. И эта микроскопическая капля в море open source невероятно радует меня каждый раз, когда кто-нибудь устанавливает себе этот плагин и пользуется им.