Если хотите, как выразились, стать "JS-разработчиком, а не фронтэнд-огрызком", то ответ кроется в самом вопросе :)
Всегда упор надо делать на языке, а не на фреймворке. Развивайтесь как разработчик, это предполагает не только пользование инструментами, но и понимание как они работают. Попутно с обучением по мануалам, читайте код: откройте исходники тот же jQuery, возьмите любую часть его функционала и разбирайтесь как оно работает. Это принесет заметные результаты.
Ну, насчет фантазий кодера, который ничего не слышал об этих практиках - комментировать не стоит, думаю итак очевидно, что стремиться надо совсем к другим вещам.
Насчет того, что иногда приходится поступаться правилами и делать "позавчера" - бывает, да, но чтобы "система не умерла через год или два, весь этот легаси-бардак" разбирать надо сразу как временный (а он же временный?) аврал завершится. Рефакторинг как цикл разработки ПО - он же и про фронтенд тоже.
> Все эти вещи заканчиваются, как только у инвестора или заказчика появляются подозрения, что продукт не пойдет в срок
Могу лишь не по наслышке согласиться. Но такое случается по большей части тогда, когда к серьезной разработке команда не готова. Это и про написание тестов, чистый-аккуратный код и прочее. Как раз прямая связь с квалификацией.
Советы-то верные, но я бы не стал, от греха подальше, так формулировать святую обязанность разработчика - лишь уметь накостылить к релизу. Как минимум один пример я уже привел выше - вас процитировали в контексте "Да ладно, смотри, вон все костылят, какие бест практис, забей". Оттого и грустно.
Безусловно, надо уметь найти пусть не идеальное, но быстрое и эффективное решение - здесь и сейчас. Но технический долг разработчика состоит в том, чтобы таких вещей избегать всегда, когда это возможно. Другой вопрос, когда при неверно выстроенных процессах на уровне менеджмента просто не представляется возможным делать как следует.
Достаточно грустно видеть в топовом заплюсованном ответе нечто вроде:
"В реальности, от разработчика требуется только одно – уметь быстро накостылять какую-нибудь фичу к релизу, который должен был быть вчера. Собственно, если внимательно посмотреть на список, который я привел, можно заметить, что все эти вещи направлены на максимально быструю разработку – тут костыль, там костыль – и в продакшн. Как бы ни пытались нагнать пафоса на собеседовании, в бою будет именно так."
Все (ну или почти все) приведенные Вами технологии направлены на быструю разработку как раз БЕЗ костылей. В них используются лучшие практики, они в какой-то мере вынуждают делать какие-то вещи правильно (если говорить о knockout/backbone/angular/react)
Grunt, gulp - это тоже не про костыли наоборот.
На собеседовании в момент "нагоняния пафоса" в первую очередь оценивается кругозор и способность мыслить в верном направлении. Человек может не ответить на какой-то вопрос, но в процессе дискуссии на тему станет предельно ясно, что произойдет когда он с этим столкнется.
У нас часто возникают дебаты в команде относительно костылей, и вот сегодня в конфе в скайпе вас процитировали :/
По теме - согласен полностью, понимание что и как использовать, плюсов и минусов придет только в процессе работы. Непрерывной, усердной и осмысленной работы. Тот факт, что вы (это я уже к ТС обращаюсь) в принципе заморочились и задаете правильные вопросы как минимум себе, говорит о том, что вы будете выгодно смотреться на фоне соискателей, которые в плане профессионального роста топчутся на одном месте. А их чуть ли не большинство. Поменьше самоуничижения, пару ресурсов вам уже подсказали. Остается пожелать успехов :)
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.