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

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

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

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

После (а лучше в процессе) изучения языка программирования очень важно научиться правильно структурировать код. Выше я уже упоминал об одном отличном ресурсе, который поможет вам овладеть этим навыком: книга Стива Макконнелла «Совершенный код. Практическое руководство по разработке программного обеспечения».

Что я понимаю под структурированием кода? Хороший и понятный код, который не требует большого количества комментариев, – словом, удобочитаемый.

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

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

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

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

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

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

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

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

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

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

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

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

• массивы или векторы;

• связанные списки;

• стеки;

• очереди;

• деревья;

• хеши;

• наборы.

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

Когда я только начинал программировать, то плохо разбирался в структурах данных и алгоритмах, поскольку был самоучкой. Я не осознавал их ценность, пока не начал соревноваться в решении задачек на сайте TopCoder, где знание этих вещей дает серьезное конкурентное преимущество. Разобравшись с принципами работы этих технологий, я вдруг понял, что те проблемы, над которыми я ломал голову, будучи начинающим разработчиком, перестали вызывать у меня какие-либо сложности. На самом деле, я считаю, что алгоритмы и структуры данных являются одной из самых увлекательных областей разработки ПО. Это и вправду очень полезно – в работе над сложной проблемой использовать все эти вещи, чтобы решение было чистым, элегантным и быстро работающим. Лучшим ресурсом для изучения этой темы (на момент написания книги) я считаю книгу Гейл Лакманн Макдауэлл «Карьера программиста»[7]7
  Издавалась на русском языке. Питер, 2021 г. – Прим. ред.


[Закрыть]. Данная книга содержит практически всю необходимую информацию об алгоритмах и структурах данных.

Разумеется, изучение этой темы – задачка непростая, однако она стоит потраченных на нее усилий. Это один из тех навыков, которые выгодно «оттенят» вас на фоне коллег. Возможно, вы удивитесь, но БОЛЬШИНСТВО разработчиков ПО очень плохо подготовлены в этой области. Если вашей мечтой является устройство на работу в такую крупную компанию, как Microsoft или Google, без знаний алгоритмов и структур данных вас туда не примут.

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

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

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

Сказанное означает, что вы должны быть знакомы как с самой платформой, так и с тем, какие инструменты разработки, шаблоны и фреймворки обычно используют разработчики при написании программ для этой платформы. Может показаться, что язык программирования определяет платформу разработки, но в большинстве случае это не так. Давайте посмотрим, например, на такой язык программирования, как C#. Зная C#, вы можете писать программы для Windows, macOS, iOS, Android, Linux и даже для встроенных систем каких-либо устройств. И вот вам мой совет: выбирайте не только язык программирования, но и платформу разработки.

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

Фреймворк – это набор библиотек, которые используются для создания кода на некоторой платформе разработки или на нескольких платформах. Как правило, фреймворк упрощает решение задач, стоящих перед программистом. Вернемся к примеру с C#. Большинство разработчиков на C# используют для создания приложений фреймворк. NET Framework. Этот фреймворк состоит из множества библиотек и классов, которые позволяют C#-разработчику работать на более высоком уровне абстракции, благодаря чему программисту не приходится «изобретать велосипед» всякий раз, когда потребуется что-то написать.

К примеру,NET Framework содержит код для работы с изображениями. Написать с нуля такой код очень сложно, поэтому данный фреймворк значительно упрощает жизнь разработчикам C#, которые пишут код, манипулирующий изображениями.

Чем фреймворк отличается от стека? Стек – это набор технологий, обычно включающий в себя фреймворки. Стек используется для создания приложения целиком, а не какой-то его конкретной части. Например, есть такой стек под названием MEAN. Данная аббревиатура расшифровывается как MongoDB, Express.js, AngularJS и Node.js. MongoDB – это технология баз данных. Express.js – платформа Node.js для создания веб-приложений. AngularJS – JavaScript-фреймворк для создания пользовательских интерфейсов веб-приложений. Наконец, Node.js – среда выполнения для разработки веб-приложений на JavaScript.

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

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

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

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

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

Под термином «основные принципы работы» я подразумеваю следующее:

• как работают базы данных;

• как выполнять базовые запросы для получения данных;

• как добавлять, обновлять и удалять данные;

• как объединять наборы данных;

Кроме того, вам, наверное, будет интересно узнать, как извлекать и добавлять данные с помощью кода на выбранной вами платформе и/или фреймворке. Зачастую от разработчика ожидается умение писать код, взаимодействующий с БД.

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

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

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

Сегодня большинство проектов по разработке ПО используют ту или иную систему сборки[8]8
  Включает такие действия, как компиляция исходного кода в объектный модуль, сборка бинарного кода в исполняемый файл, выполнение тестов, развертывание программы в целевой среде, написание сопроводительной документации или описание изменений новой версии. – Прим. пер.


[Закрыть]. Конечно, существуют команды, которые до сих пор занимаются задачами тестирования и развертывания программы вручную, но это скорее исключение. Давайте сначала разберемся, что такое «система сборки». Позвольте задать вопрос.

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

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

Система развертывания отвечает за развертывание кода либо в производственной среде, либо в какой-либо тестовой.

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

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

Поскольку во многих проектах по разработке ПО используется так называемая методология Agile (мы обсудим ее чуть позже), сегодня разработчикам ПО и тестировщикам приходится работать в гораздо более плотном взаимодействии. Качество создаваемого кода стало обязанностью всей команды. Хотя лично я придерживаюсь мнения, что так было всегда. Отсюда следует, что вам все-таки придется хоть немного, но разбираться в тестировании. Например, вас не должны приводить в замешательство следующие слова:

• тестирование методом белого ящика;

• тестирование методом черного ящика;

• модульное тестирование;

• проверка граничных значений;

• автоматизированное тестирование;

• приемочное тестирование.

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

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

А теперь серьезно. 90 % вашего рабочего времени в качестве разработчика будет тратиться на поиски ответов на вопрос: «Какого черта этот долбаный код не работает?» Я знаю, что это совсем не круто. Знаю, что вы хотите каждый день писать новый код. Однако реальный мир жесток, увы.

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

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

Вы все еще не бросили читать эту книгу, несмотря на всю ту картину, что я перед вами развернул? Чудесно. Обещаю, этот раздел – последний. Честно-честно.

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

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

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

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

Чуть позже мы еще вернемся к этому вопросу. А пока…

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

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

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

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

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

Слушай, да в этой книге просто гора ссылок! А еще ты рекламируешь кучу своих и чужих продуктов. Что за фигня, чувак?

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

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

(Кстати, если вы откроете ссылку https://simpleprogrammer.com/products/careerguide/links/, то попадете на страницу со списком ВСЕХ ссылок в книге, сгруппированных по главам.)

А что касается ссылок на другие мои проекты… Да, вы правы, это действительно реклама. Вы имеете полное право назвать меня меркантильным, но я предпочитаю называть это иначе – «быть умным».

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

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