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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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