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

руководствоваться правилом «работает — не трогай». Нередко 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 невероятно радует меня каждый раз, когда ктонибудь устанавливает себе этот плагин и пользуется им.

Серебряные пули

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

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

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

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

Будьте гибкими, не позволяйте опыту (даже личному) вставать на пути к качественному коду.

Тезисы

Серебряной пули не существует.

Всегда ищите лучшие варианты, но не бегите за трендами.

Не останавливайтесь на одном решении, старайтесь сделать лучше.

Задание

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

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

Непроходилоинесколькихлет, чтобымирразработкинеполучал в свое распоряжение какую-нибудь новую блестящую игрушкуицелуюармиюеефанатов, утверждающих, чтоВОТУЖ ТЕПЕРЬВСЕПРОБЛЕМЫБУДУТРЕШЕНЫ. Однакочемдольше находишься в этой индустрии, тем чаще видишь одни и те же технологии, приправленныеновоймаркетологией. Черт, было время, когда и я думал, что C++ сможет решить любую мою

проблему. Идеального кода нет, как и идеальных решений, так что отбросим невротический поиск абсолюта: «делай что должно — и будь что будет».

Код ради кода

Открою вам секрет: разработчики любят код. Можно сколько угодно делать вид, будто мы приходим на работу за зарплатой, но если вы настоящий разработчик, то знаете, о чем я говорю. Нам нравится код, нравится создавать что-то из ничего. И мы любим играть: с новыми технологиями, с новыми идеями

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

Если вы с энтузиазмом познаете новое, с удовольствием разбираетесь в подходах к разработке или обожаете писать свои pet projects, будьте осторожны: так можно перепутать работу

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

Не поддавайтесь искушению играть с кодом на работе. Вам может захотеться встроить в проект Lua-интерпретатор или написать микросервис на Scala, но до конца ли вы уверены, что это решение — результат анализа потребностей проекта? Может, вам просто хочется испробовать новый язык или технологию?

Действительно ли эта новая библиотека, которую так хочется использовать, нужна проекту, или вам просто любопытно, как она работает?

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

Ваша работа — не супермаркет игрушек, поэтому вы должны ответственно подходить к тому, что и как использовать. Никто не станет сдвигать рассчитанные ETA, чтобы вы могли узнать, а так ли продуктивен Go в действительности. Никто не будет мириться со штрафами от клиентов, пока вы проверяете, подходит ли Rust в качестве альтернативы языку программирования проекта (разве что вам поставили такую задачу, если это так — я очень за вас рад).

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

Тезисы

Разработчики любят код и новизну.

Не играйте с кодом на работе.

Разделяйте личный интерес и требования проекта.

Задание

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

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

Я люблю языки программирования, я люблю пробовать каждый, чтобы понять, каков он, чем он может быть интересен. И так как время мое не резиновое, мне всегда приходится искать способ уместить максимум интереса в минимум времени. С какого-то момента, пробуя новый язык, я стал делать с его помощью «Франкенштейна» — небольшой проект, буквально несколько файлов, в которые старался уместить все особенности языка, используя их так, чтобы они делали хоть что-то осмысленное. Со временем это стало забавной традицией и незамысловатым способом поднять себе настроение.

Ошибки

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

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

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