Создание сайтов: лендинг, визитка, интернет магазин. Продвижение, поддержка, реклама.

Предисловие

Явление деления разработчиков на уровни очень распространено. Даже в вакансиях чаще всего пишут не просто “Frontend-разработчик”, а более развернуто – “Junior/Middle/Senior/${место для вашей должности} Frontend-разработчик”. Для чего? С помощью такого деления легче делегировать задачи в команде. У каждого разработчика своя особая матрица компетенций, свои навыки, которые он оттачивал месяцами, а то и годами. С помощью такого деления процесс разработки ускоряется в разы.
Вообще на рынке (я смотрю на рынок стран СНГ) по состоянию на начало 2021 года среди Frontend-разработчиков имеют место быть такие должности (от низшего уровня, к наивысшему и без привязки к инструментам/библиотекам)

• Intern Frontend-developer – другими словами – стажер

• Junior Frontend-developer – уровень выше начального, уже более менее самостоятельная единица

• Middle Frontend-developer – самостоятельная единица, командный игрок, много умеет, но чаще всего в одной сфере / направлении. Через тернии к звездам или стремится к Senior

• Senior Frontend-developer* – старший, чаще всего в компаниях самый опытный. Человек, который попробовал многие инструменты, много может, много пробует.

• Architector Frontend-developer** – человек, который часто занимается вопросами выбора технологий, решений в вопросах архитектуры будущего приложения

• TeamLead – глава команды – распределеяет задачи, связующее звено между командой разработки и бизнесом. Хороший управленец и разработчик

* – он может быть также ведущим разработчиком, который выполняет все те же функци, что и выполнял senior, но при этом отчасти может выполнять функции архитектора. Я видел компании, где понятия “ведущий разработчик” и “Senior developer” отождествлялись.

** – Архитектор – достаточно размытое понятие. Иногда, в командах нет архитектора, но при этом есть techlead. Если загуглить, то он решает все те же задачи, что и архитектор.

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

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

Эта статья как раз о том сборнике книг для разработчиков уровня “Middle и выше”.

Секреты Javascript Ниндзя. Джон Резиг, Беэр Бибо, Иосип Марас

У каждой книги есть своя цель, и у этой книги она тоже есть. Цель – напомнить вам о том, что есть в чистом js, что есть в браузере, что такое DOM и какие есть возможности у него.
Она буквально вам говорит: “Отвлекитесь от фреймворков и библиотек – посмотрите что умеет язык без этого!”.
На страницах есть краткая информация для повторения основных понятий в js, некоторых стандартных приемов работы, например, с событиями. Все это приправлено от души хорошими примерами кода.
Книга хороша своим грамотным делением на главы и простым языком изложения. Тот самый случай, когда на ночь можно почитать не только с удовольствием, но и с пользой.

Рефакторинг кода на Javascript. Мартин Фаулер

Мы поняли как работают события, что такое замыкания, как использовать генераторы, как убежать от адской пирамиды вызовов и самое главное – с помощью чего. Теперь время писать код. Вот только мы не знаем самого главного в любом коде – способов его организации.
На просторах интернета и в книгах, о которых я напишу ниже вы сможете увидеть такие понятия как DRY, SOLID, KISS, YAGNI – это все общие положения, немного размытые, о построении архитектуры кода, приложения.
В Книге Фаулера идет полное описание каждого действия в момент рефакторинга кода. И да, Мартин Фаулер описал все способы – поверьте, Фаулер докопался и описал даже способ рефакторинга “Вынос в функцию”. По факту – книга полноценный справочник или очень хорошая настольная энциклопедия, которая служит на благо архитектуры вашего кода.

Javascript для профессионалов. Джон Резиг.

Джон Резиг решил не вдаваться в подробности и не стал делать как многие авторы – описывать в первых главах все ключевые зарезервированные слова, встроенные методы перебора массивов и т. д.
Книга Резига имеет скорее обзорный характер, она рассказывает о языке в целом, о его перспективах, некоторых интересных и уже всеми забытых методах валидации форм, об интересных моментах в работе с событиями в браузерах и о браузерах в целом. Не скажу, что это мега-полезная книга. Книга скорее служит исторической справкой об языке. Может быть, у меня сложилось такое ощущения, потому что я первой прочел “Секреты Javascript ниндзя”. В той книге информации было как-то больше, но обращу внимание на начало второго абзаца – Труд Резига имеет обзорный характер. Возможно, в этом есть свои плюсы.

Погружение в Паттерны Проектирования от RefactoringGuru

А что такое паттерны?

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

Взято с RefactoringGuru

Я уже говорил об DRY, SOLID, KISS, YAGNI. В электронной книге или на официальном сайте вы сможете ознакомиться с данными понятиями более подробно.
Авторов можно поддержать – купить электронную версию, что я советую всем сделать. Труд был проделан огромадный. Я всегда был сторонником идеи “Если можешь объяснить ребенку что-то – значит ты владеешь этим на все 100”. Книга “Погружение в Паттерны Проектирования” будет понятна наверное даже ребенку, потому что все очень подробно описано как в главах об архитектуре кода, так и в главах про устройство и построение архитектуры всего приложения.

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

Чистая архитектура. Искусство разработки программного обеспечения. Роберт Мартин

Да, последние книги про архитектуру, но иначе никак – разработчик не должен писать код ради кода, он должен думать о пригодности этого кода в будущем. Даже не так – разработчик должен писать код ради бизнеса. А чтобы он был ради бизнеса, он должен быть поддерживаемым в будущем.
Роберт Мартин писал книгу не для  Frontend-developer`ов, а для всех разработчиков и им сочувствующих. Мартин объяснил почему стоит уделять внимание архитектуре, как проводить архитектурный рефакторинг, с основными принципами, о которых также написано в refactoringGuru. (в refactoringGuru, как по мне, более подробно раскрыты некоторые моменты).

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

Заключение

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

Спасибо за внимание!