Алексей Нуар

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

В проде - лучше до минимума снизить использование своего кода, если есть поддерживаемая подходящая библиотека - лучше возьмите ее

Тут всё просто. Если хотите разобраться, то это похвально. Однозначно надо писать велосипеды, чтобы понимать, как оно там внутри устроено (в противном случае опять получим поколение jquery разработчиков).
Однако, если вы работаете работу за которую вам платят, то использовать там свои велосипеды надо только в том случае, если решение, которое было уже кем-то написано давно [1] маленькое, [2] неизвестное или [3] не подходит в этом конкретном случае (или в будущем) и вы абсолютно точно понимаете, что вам требуется этот велосипед. Тратить время и деньги заказчика на то, что вы будете чему-то учиться не особо круто. Особенно это важно, если в вашем коде завтра будут разбираться другие программисты, которым придётся изучать ваш велосипед вместо того, чтобы использовать уже известное всему миру решение.

В хороших магазинах карточка товара заполняется вручную, т.к. ее, внезапно, смотрят люди. В уродских магазах идет выгрузка из 1С, поэтому там черти что творится во всех полях.
Для примера сравните магазины Tiffany и Amazon. В первом красивые страницы товаров, картинки, человеческое описание. Во втором уродский текст без форматирования.
Остатки на складах синхронизируются по артикулу или другому уникальному идентификатору товара.

Как это делать правильно:
1. Начальная массовая загрузка делается из любого доступного файла - csv, xls, xml, json и т.д. Эти загруженные товары получают статус невидимок на сайте.
2. Абсолютно все товары проходятся и проверяются вручную. К ним обязательно добавляются фотографии, видео, человеческое описание. Для технических товаров добавляется спецификация, даташиты, чертежи, схемы, инструкции и т.д. Чем больше информации, тем лучше. Это то, что будет вести пользователей к вам из поисковиков, соц. сетей и сарафанным радио. Весь самостоятельно созданный контент обязательно должен иметь стойкие ватермарки, чтобы конкуренты его не воровали.
Если у вас миллион позиций и есть опыт продаж, отберите 1000 самых продаваемых и заполните её вначале. Этим вы ещё сильнее увеличите объем продаж.

Магазин на React должен быть сделан с использованием SSR, иначе у вас будет плохой органический трафик.

> как фронтендеру максимально адаптировать свою работу под будущее использование магазина владельцем?
Ответьте на вопрос - как привести пользователя на сайт и сделать так, чтобы он купил товар. От и до.

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

Делайте качественно и все будет хорошо.

Общего между ними то что они работают одинаково. Разницы между ними технически никакой. А вот идеологические различия есть.

Я расскажу о них в контексте PHP. Прошу заметить что протокол HTTP к PHP имеет косвенное отношение потому что он создавался для обмена html страницами а PHP просто расширяет возможности и того и другого.

GET запрос используется чтобы получить данные а POST чтобы отправить. (Напоминаю что технически они работают одинаково).

Поэтому в контексте PHP опираясь на эту идеологию сделали следующим образом:
1. При каждом запуске PHP по умолчанию создаются суперглобальные массивы ($_GET, $_POST).
2. Если в строке запроса есть вопросительный знак(?). То все что после него считается параметрами GET запроса они представлены в формате 'ключ'='значение' и в качестве разделителя используется знак амперсанда (&)
Пример:
GET /index.php?name=Андрей&surname=Галкин
это строка запроса, тут 2 параметра. эти параметры попадут в массив $_GET.
3. $_POST заполняется другим способом. содержимое этого массива заполняется из "заголовков запроса". То есть из места, скрытого от глаз в явном виде. Всю рутину по созданию таких заголовков берет на себя браузер. Хотя иногда и что-то редактируется в заголовках в ручную.

Чаще всего пост запрос используется в формах (для отправки данных).

Например у нас есть форма для входа 2 поля логин и пароль.

Представим что мы используем GET метод. Тогда при отправке формы мы перейдем на следующий адрес /login.php?login=Андрей&password=123 согласитесь что так передавать такую информацию совсем не безопасно. Любой может открыть ваш браузер и начиная вводить адрес сайта он из истории может увидеть ваши пароли и логины.

А вот если бы мы указали методом POST то мы бы получили следующий запрос:
POST /login.php (login=Андрей&password=123) то что в скобочках было бы скрыто и никак не сохранено в браузере.

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

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

И еще одна хорошая новость их можно комбинировать, например
POST /index.php?page=login (login=Андрей&password=123) Думаю я уже достаточно объяснил что из этого получится и какие параметры в какой массив попадут.

я так понимаю в тупую выполнили
$ ls -C .git/objects/<dir>
а нужно было выполнить
$ ls -C .git/objects/09
с условием что дирректория 09 действительно есть

Вертел я такие задания при устройстве на работу.
Однажды тоже устраиваясь в "крутую" контору прислали большое задание. Все выходные убил на него. Потом еще две недели мурыжили собеседованиями и в итоге не взяли.
Я с тех пор никогда не соглашаюсь на тестовые задания, которые займут больше получаса моего времени.
Объемные задания должны оплачиваться. Если они очень требовательно отбирают сотрудников, то сначала надо дать простое задание/прособеседовать и уже если человек их устраивает, давать объемное задание и платить.

UPD
Не слушайте, пожалуйста, бред об опыте и пользе для вас. Из таких "будущих хороших специалистов" потом веревки вьют, типа "поработай по вечерам, это ж опыт для тебя!" или "давай ты теперь и по субботам выходить будешь, а мы тебя за это серьёром называть будем!". Очень работает с наивными молодыми людьми.
Вы поймите, что все эти разговоры про опыт и пользу для вас - это уловки с целью сэкономить и вас обмануть. Всем плевать на ваш опыт, им нужно денег меньше вам заплатить и все.
Огромное тестовое задание - это неуважение к кандидаду.
Давай представим обратную ситуацию: я прихожу к потенциальному работодателю и говорю: "Давайте я у вас тут недельку посижу без каких-либо обязательств, а вы мне зарплату платите. А потом посмотрим, может быть останусь, а может уйду". Нормально? Ситуация выглядит именно так, потому что работодатель не делает одолжения принимая на работу, он "покупает" ваше время и ваш опыт и все.

Официальный сайт разработки микроформатов:
microformats.org/wiki/Main_Page

Что более оптимально?

Если есть возможность задать фон без картинки (в пределах разумного конечно, т.к. если бросаться в крайности - то картинки можно и CSS'ом рисовать) - то оптимальнее картинки не использовать. Меньше файлов -> меньше запросов + меньше объём страницы = быстрее загрузка.

Можно прописать для картинки обтекание float:left;