Андрей Воскресенский

Мне 39, я часто работаю с молодыми командами. Самая главная проблема, которая возникает - это ситуация "мы просрали все сроки, поэтому будем работать ночами и по выходным, а ты хоть и сделал все вовремя, но должен нам помочь". После отказа (семья, дети) на меня обижаются и работать со мной какое то время не хотят, типа ненадежный товарищ.

На Vue можно сделать всё, что можно сделать на jQ.
На jQ можно сделать всё, что можно сделать на Vue, но сложнее.
На чистом JS можно сделать всё, в том числе Vue и jQ (sic!)

Я участвовал(ую) в проектах, где в качестве фронта один единственный Vue-бандл. Это сложные интерактивные приложения, где jQ просто иррационально использовать из-за огромного количества реактивных связей. А Vue справляется с этим "из коробки".

Также, конечно, были проекты, где нужно было показать слайдеры, при определённых действиях обновить DOM, перехватить пару сабмитов форм, но в целом это просто HTML. Там Vue использовать иррационально и jQ подходит отлично.

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

Вот только чего не стоит делать — так это использовать jQ в качестве HTTP клиента для Vue. Я имею ввиду, что есть куда более легковесные и заточенные под это axios'ы и fetch'и.

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

На пальцах отвечаю на ваш вопрос:

1) По структуре - при проверки качества кода / решения / задачи / продукта / настройки сервера и так далее нужно проходить по списку (чеклист) критериев контроля качества - обычно они выглядят как списки определенных параметров которые может замерить третье лицо или сама система - формат проверяемого параметра прямо вот соответсвует / не соответсвует. На сколько процентов пройден чеклист - на столько процентов результат "качественный"
2) Почему ребята ошиблись - потому что стали приводить конкретные списки. Дело в том что у каждого проекта / сиутации / команды / набора компетенций - свои наборы таких чеклистов на разные ситуации. В больших командах сущесвтует основной чеклист который регламентирует CodeReview - и за него отвечает как правило тим лид - он его обновляет, развивает, обосновывает внесенные правила и следит за тем чтобы ПЕРЕД началом разработки все разработчики были ЗАРАНЕЕ ОЗНАКОМЛЕНЫ с этим порятком проверки качества, а все потому что:
3) Количество стайлгайдов и критериев в приципе существует огромное количество - и то как каждому в одной части света / компании удобно делать одно дело - не регламентирует ни разу что именно так же другому человеку в другой ситуации применять эти правила к своему контексту. В виде открытых стайлгайдов они существуют для накопления практик и навыков в первую очередь для их же развития (процесс формулировки наводит порядок в голове) а также дают возможность "на них конкретно" нанизать точечные ответы огромного сообщества людей, и получить те самые разные взгляды на ситуации, и по возможности опять же привести к общему знаменателю. Но это все мелочи жизни, а в вашем случае вы совершите серьезную ошибку если прямо сейчас возьметесь (примите на себя ответственность) проверять чужой код на предмет оценки, потому что:
4) Вас явно используют как внешнего эксперта на которого можно сослаться, от которого можно получить якобы аргументацию для давления на свою позицию при решении какой-то возникшей ситуации во взаимоотношениях клиент-разработчик на проекте куда вас приглашают за экспертизой.
Если вы, не предупредив, о том что "качество кода" начинается с декларации этого качества (в случае если речь идет о проверке этого внутреннего качества в рамках сотрудничества, а не самих задач которые поставлены перед создаваемой системой - фичесов) - любая ваша оценка будет недостоверна контексту ее применения (вы напишете про строки или еще что-то - а у человека будут либо взыскивать деньги / либо недоплатят за работу / или инкапсулируют в договоренности пост фактум за те же деньги работу над соотвествием определенным стилям - это все работа которая должна быть оплачена). Поэтому вот вам вилка ваших дейсвтий:

1) Если у вас просто просят менторства молодые коллеги - дайте им ссылку на гугл и ключевое словосочетание php style guide github
2) Если вас спрашивают (либо вы сами являетесь таким заказчиком который ищет за что зацепиться в коде чтобы продавить свою позицию) - нет критериев качества кода ДО начала работ подписанных на бумаге / пересланных по почте - никакие критерии не могут быть применены к текущим отношениям - только к следующей итерации за следующие деньги.
3) Если вы все же разработчик и вас попросили оценить код - донесите данную ситуацию до стадии корректного закрытия текущего этапа работ - но дальше предложите уже введение стайл гайда если оно того требует. Я полагаю что на самом деле нет. Дав сейчас ответ на вопрос в виде оценки качества кода вы сделаете только одно - абсолюно необоснованно дадите агрумент в явно перекошенном споре, и просто возьмете на себя еще один мешок кармогрязи которую будуете еще сколько-то положенного времени отрабатывать.

Подумайте хорошо на эту тему - придется выбрать свою сторону.

...работаю по принципу "если надо - разберусь"...иметь представление - да, досконально исследовать каждый пункт - зачем?