Ivan Bogachev

У code review должна быть цель. В моей практике обычно проекты небольшие и там нет отдельных тестировщиков. Получается, что code review отвечает на три вопроса:

1. Соответствует ли функционал ТЗ?
   
2. Создает ли код проблемы команде?
   
3. Есть ли тут какой-то специфичный для проекта опыт, который лучше задокументировать, пока мы еще в контексте?
   

Получается что-то такое:

• До выполнения задачи: проводится анализ задачи, формулируется ТЗ. Бывает, что нужно подключиться и помочь с требованиями, с контекстом, в котором все делается. Чем более подробный анализ мы делаем и чем лучше мы понимаем контекст на этом этапе, тем больше вероятность, что потом весь процесс выполнения задачи пойдет как по маслу и code review будет чистой формальностью в конце.
  
• До ревью: линтеры проверяют код на соответствие стилю, на отсутствие синтаксического бреда.
  
• Дальше - проверка на соответствие функционала ТЗ. Это защита от глупых ошибок в продакшене, которые коснутся пользователей.
  
• Потом - на сответствие принятым соглашениям по коду, если они есть в проекте. Обычно это архитектурные паттерны и что-то про зависимости, смотрим не создает ли код проблем окружающим, а то разные глупости порой случаются. Особенно это важно в коде, который не сам в себе, а затрагивает много чего вокруг. Иногда возникает конфликт интересов, когда что-то явно устарело, и соглашения дополняются чем-то. Чем лучше был анализ в начале, тем меньше вероятность, что тут будет, что обсуждать.
  
• Дальше уточняющие вопросы по странным местам, если они есть. Это больше с целью узнать контекст задачи, почему приняты те или иные решения. Происходит передача специфичных для проекта знаний в сторону команды. Возможно там же будут какие-то рекомендации по поводу практик, на что стоит обратить внимание в следующий раз. Это будет передача опыта от команды.
  

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

Имеете в виду что-то такое?

Что это за фреймворк?

Да не нужны там фреймворки. Нужна копипаста стилей для кучи почти одинаковых объектов (ее, наверное, можно сократить каким-нибудь хитрым миксином, но суть не поменяется):

Его заблокировали что ли?

Да. Ну то есть почти да. Клиенты не могут скачать конфигурации для подключения к серверам. Если скачать их из админки своими руками и вставить в любой независимый vpn-клиент, то все соединяется и работает хорошо - сами сервера никуда не делись.

В светлом будущем для решения этой задачи у нас будет :has. Но пока что о кроссбраузерности там речи не идет. В текущем состоянии CSS нет селектора, который бы позволил сделать тот же эффект. Но в контексте вашей задачи никто не мешает самим item сделать классы-модификаторы.

вписать изображения большего размера, что бы разметка не ломалась

Можно что-то такое сделать:

.inv-cell {
    position: relative;
}

img {
    position: absolute;
    width: 100%;
    height: 100%;
    object-fit: cover;
}

Весь вопрос тут будет скорее не в размере картинок, а в их пропорциях. Если вы привязываете саму сетку к пропорциям экрана - она 100% будет расходиться с пропорциями картинок внутри в ту или иную сторону. Если это какие-то формальные фоточки, то object-fit решит вопрос, если же это превьюшки для фильмов с текстами или еще чем-то, что нельзя отрезать - то будет вопрос по самой концепции к дизайнеру, и его нужно будет решать с ним.

console.log(new Number(1) + new Number(2)); // выводится 3 и typeof полученного значения number
То есть всё в порядке, это то же самое, как если бы мы сделали:
console.log(1 + 2);

Число - это Primitive. У примитивов есть эквивалентные объектные аналоги (кроме null и undefined). Поэтому да, это "то же самое" в каком-то смысле (у примитива нет методов, в отличии от эквивалентного объекта, они не могут быть изменены, и.т.д., но в таких простых расчетах мы не обращаем на это внимания). А штуки вроде упомянутых промисов, дат и что там еще бывает - это будут уже не примитивные типы данных, там такой двойственности уже нет.

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

На MDN говорят, что это вопрос безопасности (там только про Gecko, но можно предположить, что везде так). Если SVG используется как картинка, то в ней уже нельзя подгрузить другие внешние ресурсы. Как вариант можно использовать тег embed вместо img, и все будет работать без таких ограничений.

Смешались в кучу кони, люди, GSAP, React, Three.js... Стоит немного систематизировать инструменты хотя бы по задачам, которые они решают. Не привязываясь к конкретным фреймворкам из большой троицы, у нас есть несколько классов инструментов в теме креативных сайтов:

• Про готовые CSS-анимации - animate.css, Wow.js, и.т.д. Там много динозавров из времен jQuery. Такие штуки часто бывают не в тему дизайна, но стоит посмотреть и забыть. Хотя для сайтов в духе дизайнерской дичи, вроде той, что успешно делают в студии Артемия Лебедева - может быть и ок.
  
• Про интерполяцию всего и вся. Тут обычно выбирают между GSAP и Anime.js. Первый вариант - более замороченный, есть полезные плагины, второй - попроще, но тоже хорош, в некоторых кругах даже более популярен. Для совсем простых задач - можно свой инструмент написать.
  
• Про скролл, в основном в контексте CSS-анимаций. Тут Locomotive Scroll рулит.
  
• Про переходы между экранами. Грубо говоря прокаченный роутер. Самый популярный - Barba.js. Раньше еще был Highway.js, но в последне время что-то про него мало говорят.
  
• Про экспорт готовых анимаций из софта для анимаций. Тут нужно отталкиваться от софта. Обычно вопрос возникает в контексте AE и простых мультиков - тут Lottie, говорят, неплох. Но нужно дизайнера заранее консультировать по теме, чтобы лишнего не намалевал.
  
• Про визуализацию данных. Тут полезно знать про d3.js, в основном ради готовых примеров.
  
• Про трехмерный WebGL, чтобы не писать все руками. Самый популярный вариант - Three.js, в основном за счет экосистемы и горы готовых решений, но есть и альтернативы на любой кус и цвет. Для 2D -эффектов вообще ничего не нужно в большинстве случаев.
  
• Плюс не стоит забывать про всякие вспомогательные штуки вроде WebFontLoader, Hammer.js, LeaderLine, и.т.д. К анимациям они не относятся, но в работе могут быть полезны, чтобы не писать все самому.
  

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

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

Пытаюсь установить tailwind... при компиляции получается файл, в котором нет всех стилей tailwind... делаю всё четко по инструкции...

Если ошибок при сборке никаких нет (вы про них ничего не говорите), и вы делаете все по инструкции, то возможно стоит ее еще раз прочитать. Эта самая инструкция начинается со слов:

Tailwind CSS works by scanning all of your HTML files, JavaScript components, and any other templates for class names, generating the corresponding styles and then writing them to a static CSS file.

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

Нужно чтобы форма была по центру

Тогда может быть align-self: center; должно быть у самой формы?

Можно как-то так нашаманить:

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

Но важно понимать, что любые такие штуки с частичными наложениями изображения на само себя могут влететь в проблемы с размерами в нецелое количество пикселей и будут появляться артефакты в 1px по краям замененного цвета. Иногда это не важно, задачи разные бывают, но если вам нужно, чтобы было красиво и надежно, то лучше это делать на канвасе (а еще лучше - сразу в WebGL контексте) - там можно пройти по всем пикселям своими руками и заменить цвета без накладывания слоев. Это будет более замороченное решение, учитывая необходимость конвертировать SVG в изображение на канвасе, но по надежности его не превзойти.