Хабрахабр

[Перевод] Семь «абсолютных истин» джуниора, от которых пришлось отучиваться

Десять лет! Скоро наступит десятый год, как я профессионально занимаюсь программированием. С трудом вспоминаю годы, когда я не знала HTML: даже странно, если подумать об этом. И кроме формальной работы, почти две трети своей жизни я что-то создавала в интернете. Некоторые дети учатся музыке или балету, а я вместо этого создавала волшебные миры, кодируя в своей детской.

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

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

Это статья о моём собственном опыте и обучении. Для ясности подчеркну, что джуниоры потрясающие: простое появляться на работе, чтобы учиться новому, — это уже требует тонны мужества. Я вовсе не обобщаю, что все младшие разработчики так думают или ведут себя.

Надеюсь, пост вам понравится и напомнит что-то из прошлого или настоящего.

Спасибо Артёму и Саре за отзывы!

1. Я старший разработчик

Когда я впервые попыталась устроиться на работу, мне было 19 лет. Вакансия называлась «студент веб-мастер». Это довольно удивительное название работы, потому что вы считаетесь и «студентом», и «мастером» одновременно. В наши дни все хотят быть «инженерами», потому что это звучит более модно, но по мне «мастер» — более подходящее слово для этого ремесла. В любом случае, моя работа состояла в том, чтобы писать PHP и MySQL и поддерживать наш сайт на Drupal, а также создавать некоторые внутренние инструменты.

Поэтому, когда меня спросили о том, сколько у меня опыта написания на PHP, я уверенно ответила: «3 или 4 года!» Поскольку перед этим я несколько лет кодировала в своей спальне, то была уверена, что эти годы считаются за «годы опыта».

Я думала, что много знаю о SQL, потому что умею делать outer join'ы (внешние объединения).

А когда я погуглила, то выяснила, что три-четыре года опыта означают большую кучу денег.

В то время мой код практически никогда не проходил код-ревью. Перейдём к моей последней работе, которую я получила после пяти лет «комбинированного» студенческого и профессионального опыта (который я считала обычным опытом). Уверен, что никогда не видела ни одного пулл-реквеста. Я запускала ssh на сервере и делала git pull. И всё же я подала заявку на должность «старшего инженера фронтенда», получила предложение и приняла его. Не поймите меня неправильно, на первых двух работах я узнала массу потрясающих вещей, просто никогда не работала с другими разработчиками в той же кодовой базе.

Так я стала старшим разработчиком в зрелом возрасте 24 лет.

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

Прямо как босс.

Что я в итоге поняла

Не весь опыт одинаков. Мой опыт кодирования в спальне, работа студентом-программистом отличается от научных исследований в информатике и работы в растущем стартапе. Это разный опыт. За год работы в техподдержке в начале своей карьеры вы можете узнать в десять раз больше, чем за пять лет в индивидуальных проектах (или с минимальной обратной связью). Если ваш код никогда не просматривают коллеги, обучение идёт намного медленнее.

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

Позиция CTO может быть в команде из 5 человек, 50 или 500 человек. Я также узнала, что названия должностей ничего не означают сами по себе. Так что мой титул «сеньора» вовсе не делал меня ведущим программистом. Это совершенно разная работа, хотя название идентично. Я поняла, что важно не зацикливаться на названиях и не стоит использовать их в качестве какой-то внешней проверки. Кроме того, иерархические титулы по своей сути ущербны и их трудно сравнивать между собой.

2. Все пишут тесты

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

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

Потому что… ну, это же бесплатно.

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

Короче говоря, я ушла из института с большими ожиданиями.

Автоматические деплои. Ожиданиями относительно того, как работает индустрия. Это будет великолепно! Пулл-реквесты и код-ревью. Но кроме качественного кода с надлежащими стандартами и лучшими практиками, я твёрдо верила, что в софтверной индустрии все пишут тесты. Наконец-то качество кода, о котором я мечтала!

Хм...

Никаких тестов в интерфейсе. Так что представьте моё удивление, когда в первый рабочий день в стартапе я не нашла никаких тестов. Вообще никаких тестов. Никаких тестов в бэкенде.

Ничего. Нда. NaN. Ноль. Тесты отсутствуют как явление.

С некоторой наивностью я предположила, что причина в том, что люди просто не знали, как писать тесты для AngularJS. Не только не было тестов, но, казалось, никто не испытывал из-за этого проблем! Ошибка! Если я их научу, всё наладится — и мы начнём проводить тесты. В общем, только спустя несколько лет мы внедрили в код автоматические тесты, и это было не так просто, как я думала.

Но не потому, что люди не умеют их писать.

Две вещи, с которыми я никогда не сталкивалась. Они либо никогда не испытывали проблем от отсутствия тестов, либо испытывали проблемы от наличия старых тестов.

Что я в итоге поняла

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

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

Я выступила ТАКОЙ всезнайкой, настаивая на повсеместном внедрении тестов, почти не имея опыта, как это действительно реализовать в большом масштабе. Быть чрезмерно самоуверенным в вопросах, по которым вам не хватает реального опыта, довольно высокомерно. Важно иметь принципы, но важно ещё быть открытым и по-настоящему заинтересованным, чтобы воспринимать опыт и взгляды других людей. Не повторяйте моих ошибок.

3. Мы настолько отстали от всех остальных (aka техническая версия синдрома упущенной выгоды)

Это тесно связано с темой модульного тестирования. Моя компания не проводила тестов, но, конечно, все остальные компании их делали, верно?

Просмотрела массу выступлений с конференций на YouTube. Я прочитала кучу постов в блогах. Кажется, что все пишут суперсложные и высококачественные приложения с отличной производительностью и модными анимациями, в то время как я просто делаю заплатки, пытаясь успеть к дедлайну. Чёрт возьми, я непрерывно читаю «тот оранжевый сайт» [вероятно, имеется в виду Hacker News — прим. пер.].

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

Что я в итоге поняла

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

Нет, серьёзно, легко представить, что у какой-то другой компании нет легаси. Работать с легаси совершенно нормально. Попробуйте найти компанию, у которой НЕТ огромного монолита на PHP или Ruby, который они пытаются приручить (или должны были приручить в какой-то момент)? Но проведя время на конференциях, разговаривая с людьми, работающими в топовых компаниях, становится ясно, что все мы в одной лодке. Легаси код — обычное дело, и работа с ним часто научит вас большему, чем создание приложений с нуля, потому что вы больше работаете с концепциями, которые ещё не понимаете.

4. Качество кода очень важно

В былые времена я могла сделать очень жёсткое код-ревью.

Мой стиль оказался модифицированной версией стиля руководства по стилю JavaScript от Airbnb, но соответствует моим личным вкусам. По крайней мере, я был весьма придирчива к стилю. Совершенно невозможно было пройти код-ревью без единого комментария от меня: вам пришлось бы освоить навыки чтения мыслей и вдобавок выиграть в лотерею. Такие вещи, как отступы, форматирование, именование — не дай бог вы сделаете это иначе.

Представьте более 50 комментариев к вашему пулл-реквесту с перечислением всех точек с запятой, которые вы пропустили!

Потому что у меня глаза как у орла — и этот орёл хочет получить все свои высококачественные точки с запятой!

(К счастью, после многих лет работы за компьютером зрение как у орла пропало, так что теперь вам не о чем беспокоиться — #шуткибезшуток)

Что я в итоге поняла

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

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

Но качество кода — это не то, что я думала. Качество кода важно, не поймите меня неправильно. Это не линтинг, форматирование или какой-то стиль, о котором рассказано в последней прочитанной мною статье.

5. Всё должно быть задокументировано!!!

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

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

Итак, как я справилась с тем фактом, что 300 строк незнакомого кода заставили меня почувствовать, что я тону?

ПОВСЮДУ. JSDOC.

Аннотации для каждой функции, до которой я могла добраться. Я начала комментировать всё, чтобы попытаться найти смысл.

Мой код всегда был в два раза длиннее, потому что у него было столько документации и комментариев. Я выучила весь этот причудливый Angular-специфичный синтаксис JSDoc.

Что я в итоге поняла

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

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

6. Технический долг — это плохо

Если после прошлого пункта вы посчитали меня невротиком, просто почитайте этот! Какое-то время в моей карьере я считала техническим долгом любой «грязный» код. Технический долг — забавный термин, потому что если вы попросите привести пример, они назовут очень разные вещи.

Поскольку я считала любой «неупорядоченный» код техническим долгом, я немедленно пыталась устранить его с максимальной строгостью!

Однажды я буквально провела выходные, вручную исправляя 800 ошибок линтинга.

Вот каким невротиком я была.

(Отказ от ответственности: это было до того, как появились автоматические исправления).

Что я в итоге поняла

Неорганизованный или беспорядочный код — не то же самое, что технический долг. Просто неидеальное состояние не означает, что это технический долг. Технический долг фактически замедляет вас каким-то образом, или делает определённые виды изменений трудными или подверженными ошибкам. Если код просто немного запутан, он просто немного запутан. Уборка может не стоить вашего времени.

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

7. Чем выше должность программиста, тем лучше он программирует

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

Долгое время я думала, что именно в этом суть ведущего разработчика.

Ведь должность называется «ведущий разработчик», а не «ведущий коммуникатор» или «ведущий менеджер проекта». Вроде бы всё сходится? Я действительно не понимала, сколько ещё навыков нужно ещё развить, чтобы стать по-настоящему «ведущим».

Что я в итоге поняла

Старшим инженерам придётся освоить много навыков, кроме программирования. Если сравнить с началом карьеры, мне пришлось развить астрономическое количество навыков. Коммуникация, управление зависимостями, совместное использование контекста, управление проектами, оценка сроков выполнения проекта и сотрудничество с коллегами, которые не являются разработчиками. Эти навыки с трудом поддаются количественной оценке и требуют много проб и ошибок, прежде чем будут усвоены надлежащим образом.

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

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

Отличная вещь, если в какой момент вы задаётесь вопросом, что подразумевает эта работа. Бонус: мне очень понравилась статья «Быть ведущим программистом».

Показать больше

Похожие публикации

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»