Текст книги "Карьера в IT. Как найти работу, прокачать навыки и стать крутым разработчиком"

Глава 2. С чего начать

Когда я только начинал работать программистом, я не имел ни малейшего понятия о том, чем я занимаюсь. Мне было непонятно абсолютно все, и в голове крутилась единственная мысль: «У меня ничего не получится». Зачем я все это вам рассказываю? Мне кажется, что раз вы взяли в руки эту книгу, вы вполне можете испытывать точно такое же чувство. Не переживайте, это нормально. И даже естественно.

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

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

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

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

Я скачал исходный код крайне популярной игры в жанре МПМ. (Многопользовательский мир. Это что-то типа World of Warcraft, только без графики. Только текст. Да-да, это было в те далекие времена, когда мы дозванивались до «бибиэсок» с помощью модема). Когда я открыл файлы с кодом, то ужаснулся. Я всего лишь хотел создать свою собственную МПМ-игру и добавить в нее кое-какие свои идеи, но чтобы это сделать, нужно было нырнуть в эти дебри непонятных символов. В общем, именно это я и сделал. Я менял значения всех подряд переменных. Я искал код, отвечающий за вероятность нанести критический урон. После того, как я нашел его и изменил, я перекомпилировал игру и посмотрел, что получилось.

Иногда я получал, что хотел. А иногда мое творение даже не компилировалось. Я просто смотрел что работает, а что – нет. Вот так и выглядела моя «учеба»! Несмотря на то что я толком не понимал, что делаю, уже через неделю таких экспериментов мне удалось слепить собственную МПМ с уникальными «фичами».

Конечно, до настоящего программиста мне было еще далеко, но начало было положено. Столь необходимое каждому из нас.

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

Все, что вам нужно, – это просто поковыряться тут и там, понажимать кнопочки. И даже «сломать» что-нибудь в процессе. Кстати, советую иногда отвлекаться от этого увлекательного занятия и периодически заглядывать в главу «Учимся учиться: как обучать себя» в книге «Путь программиста. Человек эпохи IT»).

Обратите внимание, что «научиться программировать» и «узнать, как попасть в мир разработки ПО» – две абсолютно разные вещи. Безусловно, чтобы стать разработчиком, необходимо учиться писать код, однако есть кое-что еще. Эта глава как раз об этом.

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

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

Рассмотрим в качестве примера текстовый редактор. Я пишу эту книгу в приложении «Документы Google». Без него мне пришлось бы достать с чердака печатную машинку или взять шариковую ручку и лист бумаги. Если бы я захотел отформатировать документ по мере ввода, мне пришлось бы вручную настраивать машинку. А для исправления ошибок мне пришлось бы открыть флакончик с корректирующей жидкостью (и, наверное, бутылочку виски).

Конечно, одних только «Документов Google» будет недостаточно, чтобы напечатать книгу. Мне нужен компьютер, который состоит из кучи микросхем и программ, принтер и все в таком духе. Но я думаю, что вы уже поняли, к чему я веду.

Чтобы стать хорошим разработчиком, нужно знать одну простую, но очень важную истину:

Прежде чем что-то автоматизировать, нужно научиться делать это «что-то» вручную.

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

Процесс разработки ПО всегда начинается с констатирования проблемы, которую будет решать ваша будущая программа. Задайте себе вопрос: «А что я, собственно говоря, автоматизирую?»

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

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

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

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

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

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

Первая книга называется «Совершенный код. Практическое руководство по разработке программного обеспечения»[5]5
  Издавалась на русском языке. Русская редакция, 2019 г. – Прим. ред.


[Закрыть], ее автором является Стив Макконнелл. Это классический труд, который должен прочитать каждый разработчик.

Вторая – «Чистый код. Создание, анализ и рефакторинг»[6]6
  Издавалась на русском языке. Питер, 2018 г. – Прим. ред.


[Закрыть] за авторством Роберта Мартина. Это тоже классика, которая научит вас писать более качественный код.

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

Итак, код готов. Значит ли это, что программа готова к выпуску?

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

Например, использование методологии «Водопад» (Waterfall) предполагает тестирование в конце проекта. А при использовании методики Agile тестирование происходит в конце каждой итерации создания ПО, которая обычно длится пару недель.

После того как тестировщики дают «добро» на выпуск кода, наступает этап развертывания, который представляет собой отдельный процесс.

Вы, наверное, уже обратили внимание на то, что я лишь вскользь упомянул о данном этапе создания ПО, – потому что этой теме в книге посвящена целая глава. Развертывание – это процесс установки готового ПО на сервер, загрузки в магазин приложений (типа App Store или Google Play) или предоставления доступа к программе конечным пользователям любым другим способом. (Этот процесс может быть довольно сложным.) Попутно код можно следует отправлять в репозиторий исходного кода, где сохраняются различные версии и изменения вашего ПО.

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

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

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

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

Но не бойтесь. Цель этой книги – информировать вас обо всех аспектах – или, по крайней мере, указать правильное направление. Возможно, вам придется самостоятельно собирать свой багаж (знаний), а я подскажу, что стоит с собой взять.

«Так, Джон, мы поняли, что разработка – это не только программирование, и нам придется проводить кучу времени за отладкой, развертыванием и бла-бла-бла, – скажете вы. – Ну а начать-то с чего?» Спешу вас поздравить: вы уже начали!

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

Да-да, я знаю, что все это лишь слова, но поверьте мне, это не пустые нравоучения. Когда-нибудь вы тоже станете старым вредным профи и будете вещать то же самое.

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

Давайте поговорим о том, из чего должен состоять подобный план.

В первую очередь надо объективно оценить, каков сейчас уровень ваших навыков и чему вы хотите научиться.

• У вас есть опыт программирования?

• Вы знаете какие-нибудь языки программирования?

• Вам уже приходилось писать программы (пусть даже самые простые) или вы пока что находитесь в самом-самом начале пути?

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

• Знаете ли вы что-нибудь о базах данных, управлении версиями ПО, разработке через тестирование, отладке или методологиях создания программ?

Задайте себе еще и такой вопрос:

• В какой сфере разработки ПО вы хотели бы развиваться?

Да-да, конечно, все хотят разрабатывать игры, но стоит ли в это бросаться? Если вы планируете начать карьеру программиста именно в этой области, подумайте, готовы ли вы конкурировать с огромным количеством таких же «гейм-дизайнеров»?

Очень много людей отправляются в дорогу, не продумав свой путь.

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

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

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

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

Я понимаю, что сделать выбор очень трудно, но, поверьте мне, это очень и очень важно! Скажу так: чем точнее вы представите финальную цель, тем проще вам будет ее достигнуть.

Представьте, что вы решили стать «спортсменом». По-моему, это звучит как-то расплывчато. Как, например, будут выглядеть ваши тренировки? Может быть, вы будете «тягать железо» и бегать, или, наоборот, станете мастером спорта по плаванию. А может, ваше призвание – это ракетка и мяч?

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

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

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

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

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

Вопрос Джону!

А как понять, что я хочу разрабатывать?

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

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

Существует огромный спектр технологий, на которые можно обратить внимание.

Интересны веб-приложения? Мобильная разработка? А может быть, вам было бы интересно писать код, который позволит холодильнику правильно регулировать температуру? Или отправлять космонавтов к далеким звездам?

Подумайте об этом, а затем самостоятельно исследуйте вопрос. Если задать его правильно, то найти ответы будет несложно.

Я считаю, что рассмотрение реального примера – весьма полезная методика. Поэтому давайте рассмотрим следующую вполне конкретную ситуацию, в которой человек планирует стать веб-разработчиком на Node.js.

Цель. Стать разработчиком Node.js

План

Обучение

♦ Выучить основы JavaScript

♦ Понять, как работают веб-страницы и какие существуют технологии веб-разработки (например, HTML и CSS)

♦ Выучить основы Node.js

♦ Научиться создавать приложения на Node.js

♦ Узнать о различных фреймворках и технологиях, которыми пользуются разработчики Node.js

♦ Дополнить свои знания о Node.js

♦ Узнать о технологиях баз данных, используемых вместе с Node.js

♦ Разобраться с базовыми понятиями компьютерных наук:

♦ Алгоритмы

♦ Структуры данных

♦ Узнать о лучших практиках написания хорошего кода

♦ Узнать, как разрабатывать архитектуру приложений на Node.js

♦ Подготовиться к поиску работы

♦ Прочитать описания вакансий разработчиков на Node.js и узнать требования работодателей

♦ Составить список компаний, где вы хотели бы работать

♦ Начать посещение тематических встреч в вашем городе (клуб по интересам)

♦ Начать общаться с программистами, которые разрабатывают на Node.js

♦ Нанять специалиста по созданию резюме

♦ Проанализировать вопросы, которые задают на собеседованиях

♦ Попробовать пройти собеседование (сымитировать)

♦ Создать портфолио из нескольких приложений

Получение работы

♦ Связаться с компаниями и известить их о своих навыках и поиске работы

♦ Принять участие в стажировке или подать заявки на замещение должности джуниор-разработчика

♦ Подавать заявки как минимум на две вакансии в день

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

Поначалу ваш план будет далек от идеала, но по мере проработки он будет становиться все более полным.

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

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

Глава 3. Необходимые технические навыки

Я убежден, что каждый программист должен развивать не только технические, но и так называемые гибкие навыки. Я даже написал об этом целую книгу: «Путь программиста. Человек эпохи IT». Тем не менее нельзя недооценивать важность технических навыков.

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

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

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

Хочу сразу предупредить, что приведенный далее список технических навыков, которые вам понадобятся как программисту, не является исчерпывающим. Однако я постарался привести наиболее важные из них. В части «Все, что нужно знать о разработке ПО» я подробно разберу каждый из представленных здесь навыков.

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