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

Инструменты и автоматизация

Работая над проектом, крайне важно создать среду, в которой вы наиболее эффективны, начиная от выбранных вами инструментов разработки и заканчивая операционной системой и «железом». Все должно работать так, чтобы вам было максимально удобно.

Единственное мнение, к которому следует прислушиваться в этом вопросе, – свое собственное. Вы чувствуете, что эргономическая клавиатура вам не подходит? В мусор ее. Вы чувствуете, что монитор, повернутый, как у всех коллег, на 90 градусов, вас раздражает? Поверните его так, как вам удобно. Вы чувствуете, что максимально эффективны в Emacs, а не в полноценной среде разработки, оплаченной вашей компанией? Что ж, вы сэкономили компании немного денег – работайте в Emacs.

Выбор инструментов – долгий процесс, и вам потребуется немало времени, чтобы определить, как и чем удобнее всего работать. Если вы постоянно пробуете новые инструменты и подходы, это тоже правильно. Как можно понять, что вам что-то подходит больше, если не испробовать все варианты? Как шеф-повар, как плотник, вы должны знать свои инструменты досконально.

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

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

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

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

Тезисы

■ Выбирайте инструменты самостоятельно.

■ Учитесь работать со своими инструментами, становитесь эффективнее.

■ Пробуйте новые инструменты и подходы.

■ Автоматизируйте рутинные задачи.

Задание

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

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

Мне всегда нравилось выбирать инструменты, пробовать редакторы кода, среды разработки, утилиты, инструменты автоматизации. Часто это давало преимущество в принятии решения о выборе инструмента – у меня уже был опыт и представление о том, что я хочу видеть и чем хочу пользоваться на проекте. У этого подхода есть и обратная сторона: чтобы сделать HTTP-запрос, я скорее напишу Python-скрипт, чем просто воспользуюсь cURL. Но это определенно не то, из-за чего я стану огорчаться.

Тесты

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

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

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

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

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

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

Тестирование человеком всегда дает вашему проекту преимущество, потому что человек – это невероятная аналитическая машина, способная совершать фантастические глупости. Как разработчику вам никогда даже в голову не придут вещи, которые пользователь может сотворить с продуктом. Буквально. Просто поверьте мне на слово. Тестировщики, конечно, будут относиться к вашему проекту более бережно, однако, как опытные специалисты, они (как и вы в коде) интуитивно чувствуют слабые места и выявляют проблемы продукта куда быстрее и качественнее самих разработчиков. «Володя, я кликнул на это поле ввода три раза, отсоединил и подсоединил обратно клавиатуру, подпрыгнул на стуле, и наше приложение зависло» – да, готовьтесь именно к такому.

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

Как правило, приступая к очередной задаче, вы, как разработчик, располагаете всеми данными, необходимыми для ее реализации (если нет – вы явно пропустили фазу анализа и сбора требований, ай-яй-яй). Следовательно, вы можете заранее описать сценарии работы еще не написанного кода. На этом принципе базируется методология разработки и тестирования TDD. Формализм и аккуратность будут вашими лучшими помощниками при написании таких тестов, однако знайте, что есть грань, пересекать которую считается дурным тоном. Однажды формализм заставит вас написать проверку того, что true является true. Встаньте, передохните и постарайтесь больше не превращаться в робота.

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

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

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

Тезисы

■ Тесты нужны, даже если вас убеждают в обратном.

■ Идеальный вариант, если ваш код будут проверять тестировщики или хотя бы ваши коллеги.

■ Терпите скуку формальных тестов, это окупается.

■ Один упавший тест – минус сотня недовольных клиентов.

Задание

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

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

Вам никогда не встречался тест, который использует текущее системное время для проверки работоспособности проекта? Мне встречался. А знаете, чем будет знаменит такой тест, чем он запомнится вам, когда вы с ним встретитесь? А вы обязательно с таким встретитесь или даже напишете свой. Ваши тесты будут либо выполняться безукоризненно гладко, либо останавливаться с ошибками, и вы потратите уйму времени на то, чтобы понять: все, что меняется между их запусками, – это секунды, которые сменяют друг друга. Тик, тик, тик… Успешный тест, неуспешный тест, успешный тест…

 

Идиоматичность

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

Идиоматичность кода трудно воспринять с первого взгляда. Вам потребуются опыт и много практики для того, чтобы «почувствовать», как стоит писать на том или ином языке программирования. Скорее всего, рано или поздно вы сами придете к идиоматическому написанию кода. Однако я очень рекомендую вам ускорить этот процесс: читать определения авторов языка программирования, код стандартных библиотек и код значимых проектов, написанных на этом языке.

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

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

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

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

Тезисы

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

■ Не пишите код на каждом новом языке программирования так же, как на предыдущем.

■ Читайте код, читайте советы авторов языка, практикуйтесь.

■ Если «заржавели» на одном языке, не бойтесь переключиться на другой и потратить время на его изучение.

Задание

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

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

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

Вместо десятка слов я покажу вам код. Здорово, если вы уже немного знаете PHP и JavaScript, вам будет легче оценить эту шутку:

$sum = 0;

$arr = new Array(1, 2, 3);

for ($i = 0; $i < $arr.length; $i++) {

$sum += $arr[$i];

}

Это JavaScript-код, но написанный так, будто это PHP. Нет, делать так не надо никогда.