Мои рассуждения на тему Как учиться программировать на JavaScript

?v=1

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

Немного о себе

Скажу сразу: я неправильный программист. У меня нет никакого образования кроме школы, а в программирование я подался в возрасте 25 лет. У меня даже нет четкого понимания что я правильно программирую, а что нет. Но несмотря на это, уже более 13 лет я программирую. Я по-прежнему не очень умею в различные математические формулы и т.п., но в целом получается создавать программные продукты (и, к слову, вполне прилично зарабатываю). Вот и учить я буду может не правильно, но обязательно с упором на то, чтобы начинать в скором времени зарабатывать деньги.

Рассуждения о сути программирования

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

Чаще всего я вижу следующую картину: с одной стороны все говорят о том, что программистом стать — это очень сложная задача, требующая кучи времени и из огромного количества желающих выходят всего лишь чуть ли не единицы программистов, а с другой стороны дикий дефицит и все кричат «нам не хватает программистов!». И здесь же еще один парадокс: мало кто вообще понимает по каким критериям оценивать программистов (что это вообще программист). Я думаю, что проблема тут в том, что до сих пор не выработана система правильной постановки задач. В какой проект не посмотри — нужен какой-то фантастический персонаж, который умеет все, что надо. Но такого не бывает. Сейчас даже в рамках одного только JavaScript столько технологий наплодилось, столько подходов, что в какой проект не окунись, гарантированно найдешь то, с чем не сталкивался. И вот и получается, что какой-нибудь матерый спец с 10-летним стажем может еще себе позволить подключиться к проекту, из расчета, что знает точно многое, а чего не знает — доучит. А что делать тем, кто еще и пары лет опыта не имеет? Скажу точно: для таких — почти безнадега.

В итоге огромная пропасть существует между джунами и сеньорами. Практически никто не хочет брать джунов на работу, как минимум хотят мидлов (а лучше сеньоров, но не за дорого). А откуда набраться мидлам и тем более сеньорам, если джунов никуда не берут?

И как мне видится, тут есть два пути:

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

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

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

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

Вот и с JS у меня мысль: не пытаться изучить все необходимое. Если вы будете пытаться браться за любой проект, всего необходимого вы тогда просто не изучите. А сосредоточиться на каком-то определенном стеке, в рамках которого еще и может получиться вычленить отдельные профили (чтобы еще сильнее сузить для себя профиль обучения).

Здесь наверняка многие адепты программирования меня наругают, мол «Чему ты учишь новичков?! Потом наплодится куча быдлокодеров, которые только и смогут что позорить отрасль!». Но я здесь как мантру повторю: «Вам шашечки или ехать?». Мне совсем не понятно, почему программирование пытаются возвести в какой-то мифический ранг? Почему, если программист, то надо быть богом, а вот простым чернорабочим нельзя быть? Есть полно задач, которые не требуют семи пядей во лбу, но которые требуют определенных знаний. Если человек освоит эти необходимые знания, может он и не станет еще программистом в том смысле, как от него ожидают «отцы». Но этот человек вполне может получить работу и получать свою зарплату. А со временем человек будет получать опыт и расти профессионально дальше.

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

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

Итак, какой же стек я предлагаю выбрать?

Git

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

TypeScript

TypeScript — это не полноценный самостоятельный язык, а, по сути, надстройка над JavaScript, которая вводит типизацию в этот нетипизированный язык.

В чем смысл?

Вообще, я всегда был за то, чтобы учить выбранный язык в чистом виде, и только после этого переходить к каким-то готовым решениям (библиотекам и т.п.). Но в случае с TypeScript у меня мнение поменялось. Дело в том, что если мы говорим об обучении с упором на то, чтобы как можно быстрее влиться в коммерческую разработку, надо понимать, что априори мы рассчитываем на командную работу. Обучаясь в этом направлении, вы очень нескоро еще сможете взять целый проект в свои руки. Вместо этого вы будете работать с другими специалистами, совместно выполняя задачи. Но даже если вы сами будете тянуть какой-то проект, современный JS устроен так, что своего кода пишется минимум, а бОльшая часть проекта — это сторонние компоненты. Так вот, работая с большим количеством сторонних компонентов, у вас будет постоянная головная боль: Какие сущности в этих компонентах есть? С какими параметрами их можно вызвать (сколько параметров, какие типы)? Что в результате их выполнения ожидать? Вот если писать на чистом JS, вам постоянно надо будет держать это все в голове, все это знать, или постоянно сидеть в сторонней документации (которой может еще и не быть).

В случае же работы с TypeScript, вы как будто работаете не один, как будто кто-то сидит в вашей IDE и постоянно помогает вам в написании кода, следя за тем что и как вы пишете. И если вы что-то пишете не то, TS вам подсказывает, типа «Здесь ожидается логическая переменная, а ты строку пытаешься скормить» или «здесь условие никогда не выполнится, потому что ты пытаешься жестко сравнить число со строкой, а они никогда друг другу не равны» и т.п. То есть здесь смысл в том, что вы учитесь не тому «что делать», а тому «как делать». И это на самом деле сильно проще. Вам коллега ставит задачу «Забери по АПИ курсы валют и скорми массив числовых значений мне в компонент», и это уже довольно четкая задача, потому что вам уже определено условие: «дай массив чисел». Вы можете здесь ошибиться логически, к примеру, взяв не те числа не из того АПИ. Но вы не сможете скормить не массив, или массив не чисел. То есть решив, как вам кажется, задачу, получив результат и попытавшись отдать решение коллеге, уже IDE вам частично проверит результат, до того, как вы потревожите коллегу.

С typescript легко можно играться в playground. Вот пример.

Мой вердикт: если вы хотите в JavaScript, то изучайте сразу TypeScript. Вот прям сразу. И тогда вы сэкономите много своего времени, а более качественный код вы начнете давать довольно скоро.

React

Про React очень много написано и наверняка все слышали. Так же наверняка слышали и про другие библиотеки типа Vue, Svelte и т.п. Не хочу разводить холивар, но буду советовать выбирать именно React. Поймите правильно: я советую то, с чем сам работаю и что хорошо знаю. Так повелось, что я пишу на Реакт и знаю, что его хватает на большинство задач. А раз тема топика — на чем сосредоточиться по минимуму, чтобы в скором времени выйти на работу, говорить про все мы тут просто не можем.

Styled-Components

Само собой веб-интерфейсы — это JS+HTML+CSS. На чистом CSS уже давно никто не пишет, чаще используют препроцессоры типа SASS, LESS и т.п. Но я советую все же не изучать эти технологии, а сразу изучать styled-components. По моему опыту эта технология гораздо лучше подходит для использования в TS+React -проектах, так как получается более качественно типизацию проработать и гораздо проще работать с вложениями, оперируя не только классическими селекторами, но используя вместо селектором сами компоненты. Это позволяет более четко контролировать целостность проекта.

GraphQL

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

Next.JS

Не все проекты обязательно крупные и пишутся с нуля (хотя сейчас с нуля вообще уже мало что пишется, даже в очень крупных компаниях). Есть спросы и на простые сайта. А простые сайты должны не только просто работать, но и должны хорошо индексироваться поисковиками (то есть обязательно поддерживать качественную работу в режиме SSR (Server-Side-Rendering)), иметь высокие очки производительности (то есть конечные скрипты должны собираться с учетом лучших практик) и т.п. Поверьте, пытаться реализовать все это самостоятельно — очень серьезная задача, требующая огромного опыта и трудозатрат. Вместо этого советую взять Next.JS.

Next.JS — довольно популярный и уже довольно взрослый веб-фреймворк на JS+React плюс все остальное необходимое (включая перечисленные выше технологии). Есть много примеров реализации с применением различных технологий (включая GraphQL, Prisma, Nexus, Styled-Components и т.п.). На нем нельзя просто так сделать вообще все, но он вполне годится под 90%+ современных проектов. К тому же у него отличная документация и активное сообщество (даже в телеге есть очень активное русскоязычное сообщество, которое легко гуглится).

То есть если его взять, можно буквально в считанные дни сделать средненький сайт. А если у вас проект сильно сложнее, то все равно Next.JS наверняка пригодится, потому что он умеет не только в роутинг обычных HTML-страниц, но и можно выстраивать всевозможные API, при чем не только GraphQL. В общем, это такой мощный швейцарский нож с zero-configuration.

Резюме

Да, в сумме, перечисленные выше технологии — это совсем не мало. Но повторюсь — их достаточно для реализации многих проектов. И стратегия здесь следующая: если несколько человек будет изучать один общий стек технологий, то можно объединяться для реализации конечных проектов. И пусть каждый сам по себе не будет знать всего, все же можно разделять на более узкопрофильные задачи и каждый в отдельности может прокачиваться по более ему понравившемуся направлению (кто-то в React, кто-то в Styled-Components, кто-то в GraphQL). И на выходе получать комплексный качественный продукт. Нужен лишь хотя бы один боле менее опытный специалист, который понимает в целом как все это надо делать, который сможет поставить задачи, проверить результат, дать советы и т.п.

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

В итоге я решил, что для этого необходим ресурс, на котором были бы уроки, справочник технологий, проекты с задачами с указанием требуемых технологий и их уровней, обсуждение всего этого и т.д. в таком роде. Собственно говоря, я попытался реализовать такой апгрейд на своем сайте и многое уже сделано и в целом протестировано. Уже сейчас несколько человек обучаются и демонстрируют вполне нормальный прогресс. Вот я и решил, что хотя еще не все сделано, но «лучшее — враг хорошего». Уже сейчас проект выполняет многие задачи в плане совместного обучения. Если вы хотите тоже учиться, присоединяйтесь: https://freecode.academy

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

© Habrahabr.ru