Дисклеймер: я ни в коем случае не хочу сказать, что именно так и надо учиться. Но за плечами 13 лет опыта и не один год активности в сообществах, так что рассуждения будут не на пустом месте. Но если вы уже состоялись как программист, скорее всего вам будет не интересна данная публикация.
Немного о себе
Скажу сразу: я неправильный программист. У меня нет никакого образования кроме школы, а в программирование я подался в возрасте 25 лет. У меня даже нет четкого понимания что я правильно программирую, а что нет. Но несмотря на это, уже более 13 лет я программирую. Я по-прежнему не очень умею в различные математические формулы и т.п., но в целом получается создавать программные продукты (и, к слову, вполне прилично зарабатываю). Вот и учить я буду может не правильно, но обязательно с упором на то, чтобы начинать в скором времени зарабатывать деньги.
Рассуждения о сути программирования
Наверно, надо придумать здесь какой-то другой термин на замену "программированию". Во всяком случае я вряд ли смогу научить именно программированию. Но, как мне кажется, надо просто разобраться в целях. Вспоминаем классическое "вам шашечки или ехать?".
Чаще всего я вижу следующую картину: с одной стороны все говорят о том, что программистом стать - это очень сложная задача, требующая кучи времени и из огромного количества желающих выходят всего лишь чуть ли не единицы программистов, а с другой стороны дикий дефицит и все кричат "нам не хватает программистов!". И здесь же еще один парадокс: мало кто вообще понимает по каким критериям оценивать программистов (что это вообще программист). Я думаю, что проблема тут в том, что до сих пор не выработана система правильной постановки задач. В какой проект не посмотри - нужен какой-то фантастический персонаж, который умеет все, что надо. Но такого не бывает. Сейчас даже в рамках одного только JavaScript столько технологий наплодилось, столько подходов, что в какой проект не окунись, гарантированно найдешь то, с чем не сталкивался. И вот и получается, что какой-нибудь матерый спец с 10-летним стажем может еще себе позволить подключиться к проекту, из расчета, что знает точно многое, а чего не знает - доучит. А что делать тем, кто еще и пары лет опыта не имеет? Скажу точно: для таких - почти безнадега.
В итоге огромная пропасть существует между джунами и сеньорами. Практически никто не хочет брать джунов на работу, как минимум хотят мидлов (а лучше сеньоров, но не за дорого). А откуда набраться мидлам и тем более сеньорам, если джунов никуда не берут?
И как мне видится, тут есть два пути:
Заказчики (работодатели) научатся дробить проекты на правильные подзадачи, сумеют организовать правильную командную работу (возьмут толкового сеньора, который имеет огромный опыт, набил уже кучу шишек, и вот на этом проекте уж точно сможет сделать все правильно), и тогда появятся простые задачи для джунов и можно будет их брать массово на работу.
Самим программистам рассмотреть правильное развитие рынка, вычленить востребованные технологии и сосредоточиться на изучении именно этих технологий, чтобы лучше спозиционироваться на рынке.
Первый вариант я, конечно же, привел чисто риторически. Даже если такое и произойдет, это будет исключением из правил и на всех джунов не хватит.
А вот второй вариант очень даже реален. В свое время, когда я еще программировал на 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
Сразу уточню, что скорее всего это подойдет только новичкам и только тем, кто действительно намерен чему-то научиться. То есть придется прикладывать усилия и первые ощутимые результаты будут только недели через две-три, а на коммерческий уровень надо потребуется минимум месяца два-три. Но гарантирую, что с моей стороны будет оказана всяческая помощь ученикам, и все это бесплатно.
DmitryKazakov8
Вообще опасно заходить в JS топик на Хабре с рекомендациями, какие технологии изучать. Сообщество программистов достаточно четко разбилось по используемым фреймворкам и подходам, и явно многим не понравится то, что фокус ставится строго на определенные.
Я лично не советовал бы GraphQL, так как в реальном проекте не видел ни разу, и по собеседованиям в сотнях компаний только в паре он использовался — он создает большую нагрузку на бэк-разработчиков, в большинстве случаев ухудшает перфоманс и стабильность (права доступа, оптимизацию и кэш, стейт-машины по отдельным ручкам куда проще менеджерить), там сложно с валидацией, нестандартными данными. Также и от SC везде отказываются ввиду колоссального количества недостатков. Лучше бы посоветовать новичкам изучить CSS (+Modules) с PostCSS-плагинами, которые могут расширять его функциональность подо все нужды и классический REST + RPC с Socket, так как это намного более распространено и под те самые малые и средние проекты, о которых вы говорите, GraphQL интегрировать почти точно не будут. Если цель как раз зарабатывать деньги программированием, лучше учиться популярной классике, а не тому, что когда-то было на хайпе.
Fi1osof Автор
Не знаю на счет опасности, но вот говорить за многих — это как минимум странно. Или вы думаете, что я не отношусь к сообществам программистов? Или с каких-то пор стало запрещено высказывать свои предпочтения? Действительно странно…
Еще раз уточню: я нигде не сказал, что другие технологии плохие. С сказал, что я считаю (и это мое личное суждение), что данные технологии переспективны в плане освоения, потому что они будут востребованы. При этом я не сказал, что не будут другие востребованы.
Это еще более странно. При чем даже не столько утверждение как таковое, сколько статистика — собеседоваться в сотнях компаний. Это же сколько времени на это было потрачено. Может лучше было потратить время на программирование, а не на собеседования? Лично мне хватает 3-5 собеседований, чтобы заключить контракт.
Отчасти соглашусь. Потому что специалистов, которые умеют работать с графом нормально — найти очень сложно. Но если его правильно готовить, то получается все ОК. Особенно радует скорость внедрения и легкость сопровождения, особенно в связке с apollo-client, nexus и т.п. Но повторюсь: мало кто это в рунете сейчас умеет. При это для простых сайтов суперпроизводительность и не нужна.
Скорее всего вы тоже не умеете его готовить. К примеру, есть такая штука, как @graphql-codegen/cli, которая на гитхабе имеет 6.3к звезд, и упоминание которой на хабре гугл видит только одну страничку, и ту в вопросах. Так вот, она позволяет из граф-схемы сгенерить typescript-файлы, и сразу нагенерить реакт-хуки и т.п… Пример: github.com/freecode-academy/freecode.academy/blob/master/src/modules/gql/cli/generateTypes/types.ts#L23-L29
const scalars = {
DateTime: 'globalThis.Date',
Json: 'globalThis.Record<string, any> | globalThis.Array',
Long: 'number',
Upload: 'globalThis.File',
UserTechnologyLevel: '1 | 2 | 3 | 4 | 5 |null',
}
И все запросы будут типизированные. Пример:
export type UserTechnologyNoNestingFragment = { __typename?: 'UserTechnology', id: string, createdAt: globalThis.Date, updatedAt: globalThis.Date, components?: Types.Maybe<globalThis.Record<string, any> | globalThis.Array>, date_from?: Types.Maybe<globalThis.Date>, date_till?: Types.Maybe<globalThis.Date>, status?: Types.Maybe<Types.UserTechnologyStatus>,
level?: Types.Maybe<1 | 2 | 3 | 4 | 5 |null>
};
Обратите внимание здесь на level?: Types.Maybe<1 | 2 | 3 | 4 | 5 |null>
И все, если я в level захочу передать что-то кроме перечисленных вариантов, я получу TS-ошибку.
Про остальное писать не буду, там все в том же духе.
В целом ваше сообщение подтверждает ровно то, о чем я говорил: нам внушают, что надо учиться чему-то классическому, проверенному, надежному и точно крутому. Но сколько на это времени уйдет? Когда человек получит первую зарплату, когда пойдет по такому пути? Когда он дорастет до мидла? И вы готовы учить людей? Если готовы (не минутным сообщением, а создать проект учебный, или хотя бы написав сотню-полторы статей (как написал их я)), то конечно же учить можете чему угодно, на ваше усмотрение.
Я вот готов учить, и буду учить желающих. И тем, кто научится, обязательно помогу с работой (запросы ко мне прилетают довольно часто).
DmitryKazakov8
Высказывать предпочтения не запрещено, наоборот, плюрализм мнений — это прекрасно, как и то, что занимаетесь обучением других людей. На собеседования действительно трачу много времени, сотня в год как минимум набирается, и пара десятков в качестве интервьюера — каждый сам выбирает, по каким критериям подбирать работу, у меня они достаточно специфичные, поэтому редко устраиваюсь, а подбираю месяцами. Забивать свободное время программированием мне уже не интересно, если есть желание — занимаюсь пет-проджектами. У вас другая история, много говорите про деньги в статье — для меня же куда важнее идейная и архитектурная составляющие, так что цикл поиска работы разный.
Про GraphQL верно — все нюансы его работы не знаю, как и сопутствующие библиотеки, ссылаюсь на мнение коллег, анализ их юзкейсов и статистику использования. Исходя из этого и сказал, что не рекомендовал бы начинающим изучать эту технологию, что подтвердили ваши слова про "мало кто это в рунете сейчас умеет". Из TS моделей для реста формировать валидаторы несложно, достаточно типов запроса-ответа, обработка ошибок и вариантов ответа бэка тоже не сложна, так что я бы начал обучение с этого — явно в подавляющем большинстве проектов используется он и будет актуален еще долго. Сколько времени займет изучение реста? Точно не больше, чем графовой системы запросов, старт прост как
fetch(url), дальше — типизация, валидация, обработка. Когда человек, изучающий рест, дорастет до миддла? Может завтра, а может никогда.Как я понял, цель этой статьи скорее самореклама, так как статей типа "как войти в айти" огромное количество, и многие более обоснованны. И то, что вы с чего-то начали рассказывать в комментариях, что хотите обучать и у вас уже много учеников, подтверждает. В целом не имею претензий, сказал только что у GraphQL малое распространение и много нюансов, а SC хайп из прошлого, который неудобен и неэффективен.
Fi1osof Автор
<< Высказывать предпочтения не запрещено, наоборот, плюрализм мнений — это прекрасно
Если так, то это радует.
<< На собеседования действительно трачу много времени, сотня в год как минимум набирается, и пара десятков в качестве интервьюера — каждый сам выбирает, по каким критериям подбирать работу, у меня они достаточно специфичные, поэтому редко устраиваюсь, а подбираю месяцами.
Если это осознанный путь, то извините за мой выпад. У каждого действительно свой выбор.
<< У вас другая история, много говорите про деньги в статье — для меня же куда важнее идейная и архитектурная составляющие, так что цикл поиска работы разный.
Поймите меня правильно. Для меня деньги — тоже не высшая цель в том плане, что я не пытаюсь заработать всех денег и не говорю, что все должны к этому стремиться. Но согласитесь — совсем без денег тоже не хорошо. То есть все-таки, это профессия, и она должна приносить прибыль, должна обеспечивать необходимым. Сейчас получается, что если ты уже опытный специалист с многолетним стажем, то проблем с работой практически нет (я сам видел как народ пачками устраивается в тот же СберТех и пачками же оттуда уходит, недовольные буквально мелочами и уверенные, что найдут и лучше). А вот новичкам очень туго сейчас.
>> Из TS моделей для реста формировать валидаторы несложно, достаточно типов запроса-ответа, обработка ошибок и вариантов ответа бэка тоже не сложна
Тут не совсем так. Проблема реста в том, что сам по себе он не сообщает в деталях что он умеет принимать, что отдавать, все наборы УРЛов и т.п. То есть условно, нужны дополнительные действия для того, что бы фронт смог узнать о всех методах API. Я не говорю, что в случае с REST этого нельзя сделать, я говорю про то, что требуются дополнительные действие.
В случае с GraphQL это все идет «из коробки». Видя открытое GraphQL-API, я вижу что можно вызывать, с какими параметрами и что получить в ответ. Это позволяет легко интегрироваться со сторонними API-провайдерами. Для примера, с того же гитхаба хочу какие-нибудь данные получить, иду на страничку docs.github.com/en/graphql/overview/explorer и пожалуйста, пиши запросы. И через тот же apis.guru/graphql-voyager можно довольно быстро пробежаться по всей схеме, посмотреть взаимосвязи и т.п.
Это работает из коробки и для все GraphQL API. Мне это нравится. И я вижу, что это набирает популярность.
noodles
Имеется ввиду Styled Components? Подскажите, кроме того что они вычисляются в рантайме, какие ещё есть недостатаки?