О Web-Backend разработке для начинающих

Небольшой ориентир для начинающих программистов.

Первое трудоустройство

Не бойся идти на стажировку с низкой оплатой труда. Как только ты погрузишься в рабочий процесс это даст колоссальный прирост к скорости обучения. Самый быстрый способ прокачать навыки это устроиться на работу. Поначалу может ничего не получаться и это может сильно раздражать. Постарайся с пониманием относиться к наставнику — он тратит время на обучение, а не на выполнение задач. Со временем ты увидишь, что стажёр или даже начинающий разработчик — скорее инвестиция для компании, чем источник прибыли. Если совсем не получается, возможно, стоит попробовать другое направление или даже сменить специальность. Многие начинают с backend-разработки, но не все остаются в ней надолго — и это нормально.

Не бойся legacy-кода

Многие разработчики ориентируются сразу на современные фреймворки, но на рынке труда много вакансий с legacy-кодом. Казалось бы да кому они нужны? А я скажу что многие такие движки дают более мощный "буст" в понимании как всё устроено под капотом. В них ты можешь найти уже забытые, но очень элегантные решения, актуальные и в наше время.

Изобретай велосипеды

Многие говорят "не изобретай велосипед", но на самом деле изобретать полезно. Только изобретая велосипед ты начинаешь действительно понимать как всё работает. Используй готовые решения — но только после того, как разберёшься, что стоит за ними.

Про ООП

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

• Без ООП нельзя построить ни одного масштабного проекта

• ООП это лучшее что было создано в программировании

• Ты в курсе что вообще-то синглтон это антипаттерн?

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

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

Изучай концепции, а не рецепты

Не учи 23 паттерна, а учи концепции: Наследование, Инкапсуляция, Полиморфизм, Абстракция. Размышляя о концепциях ты придумаешь рецепты сам. В целом это относится не только к программированию.

Начни писать код так, как считаешь нужным

Начни писать в процедурно-функциональном стиле. Это наиболее естественный способ мышления ^[1]: решаешь задачу — записываешь логику шаг за шагом. Забудь о классах, интерфейсах и прочем, начни с простого и по итогу получишь код в процедурном стиле. Выдели общие фрагменты в отдельные функции, чтобы исключить дублирование кода. Такой код забракует твой руководитель, и это не страшно, в лучшем случае он укажет что можно исправить. В ПФ-стиле пишут многие опытные разработчики, хотя он не так популярен, и о нём редко говорят, но все это основа основ, и каждый когда-либо писал в ПФ стиле. Ты никогда не увидишь программиста ПФ, доказывающего что его подход лучше других, он просто пишет код и его код работает, и работает стабильно. Но ты всегда найдёшь программиста ООП, доказывающего с пеной изо рта, что без класса здесь не обойтись.

Если фреймворк, на котором работаешь, построен на ООП - найди баланс, сочетай подходы.

Не занимайся преждевременной оптимизацией

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

Докер в докере

Попробуй поработать с докером и без докера. Всегда ли тебе нужен дополнительный слой виртуализации?

Не спеши уходить на удалёнку

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

Вместо заключения

Backend-разработка — это не только про фреймворки и технологии. Это про умение думать, учиться и не бояться пробовать.

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