Андрей

Нужно.

Возраст это аргумент далеко не первой десятки.

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

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

Основная проблема возрастных джунов в том, что им, как правило, нужно обеспечивать семью и времени да сил остается маловато, в то время как у 25-летних синьоров ни ребенка, ни котёнка, забот ноль, времени и интереса вагон.

Когда я учился в школе, я участвовал в олимпиадах по информатике. Мне категорически не интересно было заниматься алгоритмами, зато я люто балдел от того, что тупая железяка выполняет любое моё повеление моментально и идеально (с поправкой на ветер), а если что-то пошло не так, значит это 100% мой косяк или железка поломалась. В общем я практиковался по 4-12 часов в сутки, без выходных и каникул. Так вот, мои конкуренты из других школ очень хорошо умели составлять алгоритмы, на бумажке, и практиковались аж бешеные 2 часа в неделю, против моих 30-70 часов... И когда мы сталкивались на олимпиадах, у них просто не было шансов, потому что в зачет шел рабочий код, проходивший тесты (пусть и в ручном режиме, все же 90-е), а за годный алгоритм на бумажке говорили молодец, но баллов не начисляли... :) Они набирали код одним пальцем и им категорически не хватало опыта отладки кода, решения практических задач программирования, которые выходят далеко за рамки только алгоритмов, хотя без последних там тоже ловить нечего.

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

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

ЗЫ: Я сам достаточно много практиковался на кодварс, когда переучивал собственные мозги с PHP на JS, это работает отменно.

ЗЫ: Вообще метод погружения во что угодно работает отменно. О методе можно почитать у Щетинина (школа Щетинина). Говорят у них годовой курс физики дети осваивали за пару недель именно методом погружения.

Надо просто понять суть, понять как работают HOCи (компоненты высшего порядка) и проекция props. Если совсем коротко, то ридакс - это единый стор, который не позволяет менять данные напрямую, вместо этого нужно диспатчить экшены, которые пробрасываются в редьюсеры - чистые функции, задача которых на вход получить текущее состояние стора и экшен, произвести изменения, не затрагивая текущее состояние (иммутабельно) и вернуть новое состояние. Редьюсеры вызываются по цепочке, так же по цепочке вызываются и миддлвары, которые позволяют перехватывать экшены и, например, производить асинхронные действия, вроде запросов к API. Ну и напоследок любой компонент может подписаться на изменения в сторе посредством HOC connect из пакета react-redux.

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

Ну и для облегчения жизни и увеличения производительности приложения надо еще понять reselect (мемоизированные селекторы) и прям чтобы совсем было весело immutable - иммутабельные структуры данных, которые на любой чих возвращают новую структуру с новой ссылкой, за счет чего любые изменения выявляются через банальное сравнение ссылки.

reselect и immutable это как специи, позволяют существенно оптимизировать работу приложения, но на первых порах можно жить и без них.

ЗЫ: Если найдешь меня в скайпе, можешь позадавать вопросы. :)

Аналогичный вопрос меня тревожил в 2015 году, когда я радикально сменил стек. Эмбер хорош, но порог вхождения очень высокий и что-то сделать быстро мало реально.

Ангуляр мне не зашел, в итоге я выбрал реакт и доволен как слон.

В реакте есть ряд подходов, и если все делать грамотно, то JSX будет только в "глупых" layout-компонентах, и вообще это очень-очень-очень удобно.

Веб сильно повзрослел в последние годы, сюда пришел энтерпрайз со всеми вытекающими. Как в 200х клепать лендинги на jQuery и получать хороший гешефт уже не работает. Надо знать, понимать, мочь и уметь очень много и сразу, учиться на ходу, вникать, рефакторить тонны легаси и пр., иначе в нормальную команду/проект попасть архитрудно. Ну и очень много вакансий за еду, но туда тоже всех подряд не берут, кое-что все же разуметь нужно...

Был я когда-то фуллстеком, так же на пыхе в процедурно-функциональном стиле кодил бэк, ООП был в виде подключения всяких библиотек типа Smarty, DBSimple. Году в 10 надоело плодить бойлерплейт, психанул и запильнул небольшой фреймворк, осознав, что основная логика уехала на фронт, поэтому движ делал упор в отдать первичную верстку и поддерживать кучу AJAX-запросов удобно. Фронт делал на jQuery с плагинами.

До некоторой поры это работало прекрасно, пока, однажды, не пришлось пилить форму на 60 полей с кучей логики для интеграции внутренней CRM заказчика с Цианом. Особенно когда через несколько месяцев пришлось менять логику, т.к. жизнь не стоит на месте...

Окончательно меня добила форма для подачи заявок на ипотеку на 8 страниц и 300 полей с конфигуратором и возможностью отключать любые поля, блоки и даже страницы. Заказчик потребовал реализации на jQuery, хотя я уже вовсю тогда увлекался React' ом.

В общем что поезд былого ушел и нужно переквалифицироваться я осознал году в 2014-2015 окончательно, чем тут же и занялся.

Сначала я метнулся в Node.JS, но там мне показалось всё скучным, поэтому я переключился на фронт, преимущественно на React + Vanilla. Оказалось, что я толком и не знал JS, поэтому я стал методично закрывать все свои белые пятна. Один из лучших способов что-то выучить - начать учить этому других, поэтому я пошел наставником по JS куда взяли, что помогло в сжатые сроки освоить базу, т.к. сам для себя можешь и смухлевать, а когда ответов ждут другие люди, это очень дисциплинирует. :)

В перспективе планирую все же вернуться к фуллстек разработке, но уже на базе Node.JS + React, т.к. лично для меня данный стек наиболее комфортный.

Предлагаю работу не бросать, но так на работе все обставить, чтобы 2-3 часа свободного времени оставалось в день и качаться-качаться-качаться.

Моё скромное имхо но до джуна качаться не менее года, это при условии, что упереться рогом и почти весь день этим заниматься. Если менее интенсивно, от от 1.5-2 лет. Придется усвоить массу контекстов, приемов, нюансов, которе чисто физически не будут заходить в голову и запоминаться пачками, следовательно придется повторять многократно. Все это нужно будет многократно проработать на практике с разных сторон.

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

Вот как-то так.

Первым делом я бы рекомендовал качать структуры данных и алгоритмы, т.к все программирование, в конечном счете, сводится к обработке данных.

потому что обработчик сабмита на onSubmit тега формы надо вешать и там уже валидацию производить

Го на кодварс и качайся там хотя бы до 4-кью, потом уже умные книжки понятнее станут. :)

Для начала не бывает таких структур данных в JS.

const findDupes = data => {
  const tmp = data.reduce((a, e) => {
    const ee = Object.entries(e).pop();
    const keys = [`${ee[0]}_${ee[1]}`, `${ee[1]}_${ee[0]}`];
    if (!a[keys[0]]) a[keys[0]] = { e, s: [] };
    if (a[keys[1]]) a[keys[1]].s.push(e);
    return a;
  }, {})

  return Object.entries(tmp).filter(e => e[1].s.length > 0).map(e => e[1].e);
}

console.log(findDupes(data));

Вот как-то так я это вижу. На вход надо подавать массив объектов типа такого:

const data = [{ 21: 31 }, { 22: 14 }, ...];

ЗЫ: Код может работать не совсем корректно, если важен порядок детектирования элементов.

Что-то вроде смс-шлюза погуглить стоило бы.

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

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

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

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

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

В целом это и есть процесс программирования. И тут нужно 99% упорной практики и щепотка теории.

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

Если нет опыта успешного и эффективного решения олимпиадных задач, то ситуация патовая.

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

При нынешнем пороге вхождения в профессию будь готов учиться года три, коли не семи пядей во лбу и нет возможности фигачить код по 12-16 часов в сутки.

P.S.: из моего опыта наставничества - чуть не половина курсантов сливают первые несколько интенсивов по причине неумения реализовать базовые алгоритмы, остальная половина кодит не первый год и умеет это делать на других языках, и совсем редко встречаются юные, и не очень, дарования, которые с места в карьер...

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

Лично я использовал в php проектах чудесную библиотеку котерова DBSimple, вопрос инъекций решает на корню, при этом используются практически те же самые запросы.

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

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