бэкенд с чего начать
Что вы сможете запрограммировать через год, занимаясь по два часа в день: бэкенд
Авторизуйтесь
Что вы сможете запрограммировать через год, занимаясь по два часа в день: бэкенд
Чтобы изучить любой технологический стек — будь то фронтенд или разработка мобильных приложений — нужно потратить немало времени и сил. Тем, кто только знакомится с программированием, не всегда понятно, стоит ли в это вкладываться. Особенно если у вас уже есть работа в другой сфере, которая сильно ограничивает личный ресурс на обучение новой профессии.
В серии статей «Что вы сможете запрограммировать через год, занимаясь по два часа в день» мы с помощью профессиональных разработчиков показываем, из чего состоит обучение тому или иному стеку и что вы будете уметь, изучив его. В этом материале разбираем бэкенд-разработку.
разработчик IT-компании MediaSoft
Привет, меня зовут Андрей, и я PHP-разработчик. Работаю программистом 5 лет, повидал больше 20 проектов, познакомился с толпой руководителей, разработчиков, тестировщиков, аналитиков и других людей из сферы IT.
Хочу поделиться с вами планом развития, с помощью которого учился я сам, а затем научил программировать другого человека практически с нуля. Придерживаясь этого плана, к концу года вы освоите один язык программирования, разберетесь как минимум с одним фреймворком, научитесь работать с API и соберете резюме с собственной базой проектов, которое можно будет показывать работодателю.
Перед началом: стек и задачи
Для успешного освоения годового плана обучения программированию я рекомендую придерживаться следующих правил:
План универсален: всё, что будет различаться в другом стеке, это название языка и список сопутствующих технологий. Замените PHP на Python (Django), Ruby (Ruby on Rails) или C# (ASP.NET), а MySQL — на PostgreSQL или MSSQL, ничего не поменяется. А в двух самых популярных редакторах кода — IntelliJ IDEA и VS Code — поддержка того или иного языка включается пятиминутной установкой плагинов.
В нашем случае язык программирования — PHP. Рядом с ним будут стоять веб-сервер nginx (не люблю Apache) и любая база данных (допустим, MySQL). Это мейнстримное решение в стеке PHP, поэтому остановимся на нем.
В среднем, стек любого языка похож, потому что и задачи везде примерно одинаковые. В бэкенде их большая часть сводится к тому, чтобы принять запрос от пользователя, забрать данные по запросу из БД и вернуть данные в каком-либо формате. Поэтому на начальном этапе важно научиться выделять и решать такие типовые задачи.
Что мы встретим в краях бэкенда
Не расслабляйтесь, на этом список не заканчивается. Это базовые требования к человеку, который претендует на работу бэкенд-разработчика.
Первый этап: основы языка, ООП, базы данных — 4 месяца
В самом начале пути ответьте себе на вопрос: зачем я вообще этим занимаюсь, чего хочу добиться? Может, вы хотите найти работу, может, решили найти развлечение на уютные зимние вечера, а может, в анкету в Тиндере писать нечего. На ваше усмотрение, главное озвучьте сами себе. Это ваш стимул, который не даст вам забросить начатое на полпути.
3–4 декабря, Онлайн, Беcплатно
На первых порах план будет довольно строгим и чётким, так как он опирается на документацию по PHP. Но чем дальше мы будем продвигаться, тем более размытым он будет становиться — выбор конкретных технологий всё больше будет зависеть от ваших предпочтений и потребностей.
Основы языка
Открываем справочник языка и начинаем разбивать его на логические блоки. Берём первые пять: типы, переменные, операторы, конструкции и функции. Это первый пункт плана: основы языка.
При формате «примерно два часа в день» на это уйдет месяц-полтора. За это время надо суметь поставить PHP, написать на нем что-нибудь ради баловства, всё сломать и начать разбираться. Вспоминаем третье правило — избегаем скуки. Можете сразу придумать себе проект, и не надо говорить, что идей нет. Делайте приложение, связанное с вашими интересами или хобби. Каталог книг домашней библиотеки, инструмент для ведения записей или расходов на кота — вперёд и с песней! Через месяц у вас будет приложение — кривое и косое, но оно уже будет работать, и его автором будете вы.
Объектно-ориентированное программирование (ООП)
Здесь советую на пару дней отложить документацию. Читайте статьи, попытайтесь понять базовые вещи об ООП, хотя бы различие между классом и объектом. После этого сразу, пока знания не улетучились, открываем документацию и начинаем изучать всё, что связанно с ООП, неймспейсами, загрузкой классов. Это не самая простая тема, и для того, чтобы появилось стабильное понимание вопроса, придётся потратить около месяца.
И, конечно же, практика превыше всего! Берём наше приложение по планированию расхода карманных денег котом на пополнение домашней библиотеки и начинаем его переписывать с учетом полученных знаний. Здесь заодно можно начать думать об архитектуре приложения: как разделяются функциональные части, как они делегируют друг другу ответственность, как заставить части приложения взаимодействовать друг с другом.
Базы данных
Мы уже написали приложение и даже переписали его на ООП, а всё ещё храним данные в массивах? Непорядок! На этом этапе нужно поставить какую-нибудь базу данных (самое простое — MySQL) и разобраться с языком SQL. В жизни так бывает, что люди сначала изучают базы данных и только потом ООП, но, на мой взгляд, это не слишком удобно: ООП — сложная вещь, на неё требуется больше времени. Пока человек будет с ней разбираться, весь SQL может выветриться у него из головы, и придется учить заново. Так что лучше сначала изучить ООП, а потом БД.
Начните с создания таблиц, наполните их данными, делайте запросы с условием и без. Возможно, за неделю изучения вы дойдете до пресвятого JOIN. Если нет, то за две — это нормально. Главное, не зацикливайтесь на SQL как таковом. БД пока выступают просто как хранилище данных для нашего приложения, а трюки с оптимизацией вы изучите позже. Достаточно разобраться, как это работает, и переходить на отправку запросов из PHP. В PHP для этих целей используется библиотека PDO — встроенный механизм работы с любыми базами данных. Как только поймёте, как работать с БД из PHP, можно прикручивать всё это к вашему приложению.
Вот и прошли 4 месяца нашего погружения. Вы разобрались в основах программирования и написали своё первое приложение, которое делает что-то полезное. Предлагаю поднять за это кружку кофе и посмотреть на свой старый код, чтобы понять, как вы выросли.
Второй этап: системы контроля версий, фреймворки, паттерны проектирования — 4 месяца
Итак, после изучения основ ООП, языка и работы с базами данных вы уже многое умеете, но расслабляться рано. Впереди ещё много нового, в частности, предстоит научиться работе с системой контроля версий, чтобы в будущем участвовать в больших проектах и не иметь проблем с командной разработкой.
Системы контроля версий
Самая популярная система контроля версий на данный момент — это Git. Установите её и заведите себе аккаунт на GitHub, куда будете выкладывать свои работы, начните разбираться с его базовыми возможностями. Если одна из ваших целей это поиск работы, то аккаунт на GitHub — ваше резюме.
Дальше план становится всё более размытым, и приведённые в нём шаги довольно условные. Выбор конкретных шагов будет зависеть от вашей цели. Каждый этап занимает в среднем месяц-полтора. Наиболее чёткий пункт в этом списке — фреймворки. К ним можно переходить, если ООП и базы данных вы уже изучили.
Фреймворки
В современной веб-разработке мало что пишут с нуля, потому что есть инструменты и каркасы разработки, в которых уже заложена необходимая функциональность. Для начала советую фреймворки Yii2 или Laravel (Yii для новичка будет немного проще, но Laravel, на мой взгляд, лучше организован). Просто начните точно так же с изучения их документации и перепишите с нуля ваше приложение, которое вы написали в самом начале обучения. Реализация одной и той же идеи с помощью разных инструментов позволит увидеть принципиальные различия в коде. Если же старый проект вам наскучил, напишите что-то новое. Необязательно выдумывать стартап — просто возьмите готовую идею и перепишите по-своему, это для опыта, а не для выхода на IPO.
Очень рекомендую разбирать всё, с чем вы сталкиваетесь, как можно подробнее. Увидели QueryBuilder — напишите свой, если не делали этого, когда разбирались с PDO. Увидели роутинг — посмотрите, как он сделан во фреймворке, и попробуйте придумать его самостоятельно. Зачем? Во-первых, чтобы набить руку. Во-вторых, чтобы лучше понимать работу и внутренние процессы очень многих вещей и это не было для вас магией. В-третьих, как я говорил в самом начале, — чтобы создать резюме в виде репозитория своих проектов. Если хотите, можете даже попробовать написать свой домашний микрофреймворк, тоже интересный способ изучать эту область: у меня своих фреймворков как минимум два, их создание помогло мне разобраться с такой вещью, как метапрограммирование.
Паттерны проектирования
В ООП есть раздел, о котором очень многие почему-то говорят с придыханием — это «шаблоны ООП» или паттерны. Само появление этого раздела и одноименной книги связано с тем, что разработчики раз за разом сталкивались с одними и теми же проблемами проектирования, в итоге был предложен список из 23 шаблонов, решающих типовые задачи. Это так, краткий экскурс в историю. Почему мы не занялись этим раньше? Потому что без практики сразу погружаться в эту достаточно академичную область сложно. Банальный пример — как объяснить устройство и пользу паттерна «Строитель» (Builder), если до этого человек не изучил QueryBuilder? Это будет слишком сложно.
На этом этапе мы изучаем шаблоны проектирования всех мастей — естественно, с упором на практику. В определенный момент вы поймёте, что основные паттерны все примерно об одном и том же, суть в нюансах реализации. Смогли освоить паттерны — осваивайте методологии.
Третий этап: сопутствующие технологии — 4 месяца
Далее мы подходим к самой размытой части нашего плана — к многообразию сопутствующих технологий, и не только в области бэкенда, а программирования и разработки вообще. Разработка программного обеспечения безгранична, и ваши дальнейшие действия будут зависеть от ваших потребностей (или потребностей работодателя). Изучили Laravel или он вам просто надоел — изучайте Symfony, этот фреймворк не менее востребован. Захотели немного во фронтенд — изучайте JS, Angular, React, да хоть jQuery. Захотели изучить что-нибудь за пределами REST API — вебсокеты и GraphQL ждут вас. Хотите попробовать NoSQL, чтобы хранить документы, которые в обычную БД без боли не засунуть, или хранить настолько разрозненные данные, что никакой SQL не справится, — берите MongoDB или Redis и разбирайтесь до посинения. Хотите узнать, что такое поисковые движки и как у «взрослых дядь» работает текстовый поиск, — ElasticSearch и Sphinx к вашим услугам.
Обязательно изучите Docker — систему упаковки приложения для более удобного деплоя. Чем это может быть полезно для домашнего проекта? Если вы захотите сменить версию PHP или вообще язык, вам не придется что-то ставить на рабочую машину: достаточно поменять конфиги Docker, и приложение запустится без вашего участия. А еще немного поможет с пониманием, как взаимодействуют между собой отдельные части приложения: фронтенд, веб-сервер, бэкенд, база, что такое отдача статики (картинок и шрифтов). Таким образом, Docker позволяет не зависеть от окружения на сервере, от окружения на рабочем месте, упрощает сборку и развертывание проекта, повышает безопасность работы за счет изоляции всех частей приложения, в том числе и друг от друга. Маленький совет: если вы до сих пор работали на Windows, то настало время разобраться с Linux. Потому что Docker и Windows очень плохо дружат.
Если за год вы освоили все вышеописанное — я вам честно аплодирую. Потому что лично я в своё время освоил не всё из этого списка. Если не получилось, не отчаивайтесь и не спешите посыпать голову пеплом — все учатся по-разному.
Что нужно знать начинающему бэкенд-разработчику, кроме языка программирования
Авторизуйтесь
Что нужно знать начинающему бэкенд-разработчику, кроме языка программирования
продакт-менеджер программы «Python-разработчик» в Яндекс.Практикуме
Некоторые новички считают, что достаточно выучить нужный язык программирования — и всё, это знание по умолчанию делает из вас отличного бэкендера. Помните подход «купил зеркалку — стал фотографом»? Но это далеко не так.
Меня зовут Лера Солодовникова, я продакт-менеджер на программе «Python-разработчик» в Яндекс.Практикуме, сегодня хочу обсудить необходимые для работы бэкендера смежные знания и умения. По большей части текст ориентирован на Python-разработчиков, но пригодится и тем, кто работает с другими языками, — принципы довольно общие, разница лишь в инструментах.
Ещё в посте — отношение различных компаний к вашим навыкам, их важность для прохождения собеседования, а также подборка полезных книг по теме.
Базис
Начнём с главного — с ОС. Хороший бэкендер должен быть знаком с unix-подобной операционной системой. Это могут быть не только разные Linux-дистрибутивы, но и macOS или FreeBSD, но общепринятым стандартом всё же является Linux. Работать вы можете на ПК или ноутбуке с любой ОС, но Linux нужно знать. Ведь вам придётся довольно активно взаимодействовать с серверами, а большая часть из них работает на Linux.
3–4 декабря, Онлайн, Беcплатно
Из этого пункта плавно вытекает второй — работа с командной строкой. Это нужно для того, чтобы говорить с сервером на его языке. Нужно не просто знать, как нагуглить ту или иную команду и что она делает, а разбираться в командном интерфейсе. Опять же, допустимы варианты в зависимости от личных предпочтений или литературы, по которой вы учились: zsh, bash, fish, но стандарт — bash.
Следующее требование ― знание систем контроля версий. И тут уже без особых альтернатив: нужен именно Git, несмотря на наличие выбора. Изучите сам Git и механику взаимодействия с ветками, если собираетесь работать в команде. Впрочем, если вы интересуетесь бэкенд-разработкой и сейчас читаете этот текст, аккаунт на GitHub у вас уже наверняка есть (а если нет, вы знаете, что делать).
Очень пригодится базовое знание принципа работы Сети в целом. Мы сейчас не говорим о доскональном изучении HTTP и всех тонкостей DNS, но вы должны представлять, что именно происходит при попытке зайти на какой-то сайт. Что к чему подключается, какие работают связки, что грузится в первую очередь и тащит за собой остальное.
Дополнительным преимуществом для начинающего бэкенд-разработчика будет знание хотя бы одного веб-фреймворка — для Python это Django или Flask. Плюс базовые знания SQL. Никто не будет выставлять вас на ежемесячные соревнования SQL-программистов, но важно уметь самому проектировать БД, работать с ними через ORM, если мы говорим про Django, или через SQLAlchemy в случае с Flask.
Ну и, конечно, никуда без основ администрирования сервера, хотя бы на уровне «Я могу сам задеплоить свой проект по SSH, не отвлекая коллег от чтения Хабра».
Алгоритмы и тестирование
В плане базовых требований к кандидату и знания основ профессии компании делятся на два лагеря.
В первом сидят серьёзные практики, которых волнует только то, что вы умеете делать. У вас может быть любое образование, и, если вы докажете им, что на текущем жизненном этапе вы в состоянии выполнять все задачи, которые они взвалят на бэкендера, вы в деле.
Второй лагерь более требователен — для них важны фундаментальные знания. Техническое образование, математическое мышление и знание алгоритмов — вот тот набор, с которым надо заходить в такие компании. Например, в Яндексе без алгоритмов никуда. Послабление могут сделать в плане самого образования — оно тут как дополнительный плюс, потому что бывают ситуации, когда человек обладает такими знаниями, даже не обучаясь этому в вузе: самоучек много и курсов тоже.
Если вы хотите в Яндекс, то самое важное, на что будут смотреть HR и на техническом собеседовании — это на результаты прохождений самих секций собеседования и на то, насколько вы знаете алгоритмы. Ваш диплом и название вуза здесь как вишенка на торте. Вишенки может и не быть — без неё торт не перестанет быть тортом.
Примерно такое же отношение у работодателей к тестированию. Кто-то уверен, что джун должен заниматься тестированием, и это будет чуть ли не первым вопросом на собеседовании. Кто-то замечает, что для тестирования есть тестировщики. Кто-то вообще ничего не тестирует.
GitHub и хакатоны
Иногда в комментариях к подобным постам встречаются теории о важности наличия у кандидата прокачанного профиля на GitHub или опыта участия в хакатонах. Ваши проекты на GitHub, множество коммитов и форков, килограммы бейджиков с IT-конференций и хакатонов — это дополнительный фактор вашей оценки как специалиста.
Прежде всего на собеседованиях смотрят на практическое решение конкретных задач в рамках прохождения секций. Иногда дополнительно могут посмотреть ваш проект на GitHub, иногда — нет. Если вы идёте на мидла, то хакатонский опыт поможет вам быстрее и легче проходить секции собеседования. Для джуна опыт участия в хакатонах, даже без призовых мест, будет реальным подтверждением того факта, что человеку интересна профессия, он старается быть в курсе новых решений и инструментов, пытается самостоятельно прокачивать навыки. Да, это тоже плюс.
Командная работа
Про soft skills написано множество постов и, скорее всего, несколько книг, поэтому я не будут сильно вдаваться в их важность и необходимость — вы всё это уже читали много раз.
На мой взгляд, главное — уметь работать в команде. Это не значит, что условный интроверт не справится, никто не требует от вас быть душой компании и зажигать на тимбилдингах. В этом пункте речь о способности задавать вопросы. Вы не представляете, сколько проблем в проектах бывает связано с тем, что человек просто вовремя не спросил, не уточнил, не сообщил коллегам, что заметил потенциальный баг.
Разговаривайте, спрашивайте, уточняйте. Это нормально. Так же нормально, как пойти и усердно погуглить что-то, если не получается.
Говоря об отношениях в команде, стоит упомянуть дедлайны. Их важно соблюдать, особенно если они командные. Ситуации, в которых кто-то один просто забыл что-то сделать или не успел (и не сказал об этом), часто заканчиваются тем, что у всей команды съезжает график. Как это отражается на отношении к человеку, регулярно срывающему сроки, вы и без меня знаете.
Ещё несколько советов. Спокойно реагируйте на критику и замечания, прокачивайте уровень самоорганизованности, давайте коллегам обратную связь, не бойтесь ошибаться в работе и исправлять ошибки. И учитесь — возможностей для этого сейчас множество.
Полезные книги
Марк Лутц, «Изучаем Python». Марк написал эту книгу по мотивам собственных курсов, которые ведёт уже более 10 лет. Здесь всё важное: обзор инструментов, типы объектов, функции плюс описания моделей и инструкции по обработке исключений.
Антонио Меле, «Джанго 2 в примерах». Книга делает упор на практическое создание приложений для реальных задач. Кроме непосредственной работы с компонентами самого фреймворка, рассматриваются также и возможности интеграции сторонних инструментов.
Лекции Тимофея Хирьянова по алгоритмам. Тимофей — один из преподавателей МФТИ. Лекций по алгоритмам множество, но эти наглядные. Особенно полезны для новичков, но и разработчику с опытом тоже пригодятся.
Если вы можете свободно читать профильную литературу на английском, то порекомендуем ещё и пару книг о разработке на основе тестов: Harry Percival, «Test-Driven Development with Python» и Kevin Harvey, «Test-Driven Development with Django».
Очередь в backend: за чем стоим и с чего начать свой путь?
Для всех, кто не любит делать UI, «дышит» очередями и мечтает об идеальном API, в четвёртый выпуск подкаста «Сушите вёсла» мы позвали backend-разработчиков Андрея, Азата и Антона.
Железные разработчики Redmadrobot Артём и Рома записывают подкаст, где вместе с гостями обсуждают разные стороны создания ИТ-продуктов и делятся опытом в диджитале. В выпуске #4 ведущие разузнали у собеседников, с чего начинался их путь в backend, какой web-framework стоит выбрать, снится ли им верстка экранов и как объяснить маме, кем ты работаешь.
Прикладываем подкаст и ответы на несколько животрепещущих вопросов
Тайминг
01:27 — Как приходят в backend-разработку
10:33 — Что привлекает специалистов в backend
12:32 — Срыв покровов: нужны ли глубокие знания алгоритмов для тех, кто «пилит апишку»?
15:17 — Вопросики масштабирования и безопасности
16:23 — Одинаковую ли работу делают все backend-разработчики?
19:23 — Ruby on Rails, его «магия», взлёт и падение
24:23 — Как выбрать платформу?
28:06 — Зачем нужны микрофреймворки и как с ними работать?
33:55 — Что такое асинхронный сервер и для чего он нужен?
35:58 — Go: простота и архитектура
41:46 — Postgresql вместо MySQL. Почему?
44:58 — Зачем нужно изучить Docker как можно быстрее и для чего стоит поставить nginx?
50:49 — «Зелёные» разработчики: какими минимальными навыками необходимо обладать выпускникам университетов, чтобы устроиться на работу?
1:04:21 — Лучшие книги по алгоритмам
1:09:33 — Что нужно знать и что не нужно делать на собеседовании?
1:14:29 — Не хочется ли ребятам уйти из backend?
1:20:28 — И все-таки, чего не стоит делать на работе и почему «с людьми нужно общаться»?
Как приходят в backend разработку?
Несмотря на популярность мобильной разработки, остались еще те, кому милее старый-добрый backend. Среди них, разумеется, и наши гости.
Азат, например, рассказал, как он не пошел в мобильную разработку и решил, что логичнее заниматься веб-разработкой в широком смысле. А вот история Антона тесно связана с Python.
Я учился в университете и выучил Python. Он мне нравился, и мне хотелось продолжать делать что-то на «питоне». А в Белгороде, где я жил и учился, можно было найти только какую-нибудь веб-студию, которая делает сайты на CMS’ке — просто подверстывают шаблоны. Мне этим вообще заниматься не хотелось. Поэтому мы с другом нашли каких-то людей, сделали им сайт, а потом ещё кому-то сделали. И было классно, потому что я делал то, что хотел. Но хотел я, наверное, не то, что было нужно в тот момент. Но, по крайней мере, я научился делать backend и после этого нашёл нормальную работу.
Что привлекает людей в backend.
…Когда есть суперпопулярный frontend? Артём вспомнил множество собеседований, на которых соискатели рассказывали, почему они хотят строить карьеру в мобильной разработке. Просто чтобы потом похвастаться крутостью приложения. В backend с этим сложнее.
Но на самом деле, если друзья, с которыми ты делишься радостью создания backend, понимают в ИТ-разработке, то они похвалят тебя. А вот маме можно сказать, что делал сервер для мобильного приложения магазина, которым она пользуется. И даже если, что такое сервер, ей не до конца понятно, мама всё равно будет гордиться.
Плюсы Backend-разработки
Азат предположил, что людей привлекает тот факт, что не нужно верстать. Ещё есть мнение, что backend сложнее и круче, хотя каждому, конечно же, свое. После этого ребята ушли в беседу о масштабировании и безопасности. Подробнее — с 15:17.
Все ли backend-разработчики делают одну работу?
Это не так. Задачи в backend разработке бывают разными, и они зависят не от языка или платформы, а от потребностей и специфики компании, а также от уровня самого разработчика.
Иногда работа может заключаться в том, чтобы доработать уже существующий метод API или сделать интеграцию между двумя сторонними системами, а где-то может потребоваться разработать архитектуру распределенной системы с нуля.
Python, Ruby, Go, С++ и все-все-все
Ребята в студии заговорили о том, как выбрать платформу. А также о том, что Ruby «ещё живет» (Рома недавно видел доказательство), а ещё почему Антон начал учить Python, о странных именах создателей языков программирования, простоте Go, микрофреймворках (о них говорили особенно много — слушайте с 28:06), MySQL, Docker, асинхронных серверах и магии рельсов.
«Зелёные» разработчики и минимальные навыки для соискателя
Насколько глубоко должен, например, выпускник университета разбираться в backend, чтобы получить работу?
Во время обсуждения выяснилось, что он должен быть «уверенным пользователем ПК». А если серьезно, то по мнению Азата, молодой специалист обязан обладать минимальными навыками администрирования unix-систем — знать определенный набор команд: cd, ls и другие.
Также должен понимать, что такое процесс, какие есть права доступа, какая система прав Linux и как вообще в ней функционируют сети, как работает IPC (inter process communications), TCP сокеты. Для начала этого достаточно. Нужно просто уметь программировать. Вот что сказал Антон:
Есть базовые вещи, общие для любой разработки, допустим, для ООП (объектно-ориентированного программирования) есть правила написания, проектирования классов. Если это алгоритмы, нужно просто знать, как они проектируются, что там есть, динамическое программирование, ну и «использовать stack везде, где можно».
Иными словами, для начала погружаться в это с головой не нужно.
Начинающему специалисту не обязательно знать все существующие алгоритмы сортировки. Но при этом подобный вопрос встречается на собеседованиях. Нужен он для того, чтобы посмотреть, как человек мыслит и какое решение он предложит.
Какие книги по алгоритмам стоит прочитать
Андрей «топил» за Стивена Скиена и его «Алгоритмы. Разработка и применение». Антон порекомендовал книгу Томаса Кормена, в которой «есть баланс между строгостью, понятностью и простотой изложения», и ещё «Cracking the Coding Interview» — хорошее практическое руководство, чтобы быстро разобраться в алгоритмах.
Также гости посоветовали «Искусство программирования» Дональда Кнута, которая задумывалась как пособие по компиляторам, а стала настоящей «книгой книг».
В итоге, backend — да или нет?
Ребята пришли к выводу, что во всех сферах веб-разработки есть свои плюсы и минусы. И это нормально. Если вам нравится backend, алгоритмы и очереди, то вам стоит задуматься о карьере именно в нём. Это если кратко. Если же хочется вживую услышать рассуждения, то включайтесь в подкаст с 1:14:29.
Полезные материалы
Для желающих погрузиться в Python можно почитать: