YuStep

Я полагаю, что такие магазины сохраняют всё, например в postgres или greenplum, а затем передают в аналитические базы (или пишут параллельно), типа в кликхаус или oracle?

XX век прошел под флагом реляционных СУБД. Вокруг них строились все системы.
Для любой банковской системы БД - абсолютная царица дизайна. Именно от нее шло
техническое задание. От базы а не от Хибернейта и синтетических таблиц как щас.
Таблицы любили. Вокруг них строили красивые теории. Модели. EAV. Подгоняли
аппарат алгебры (Эдгар Кодд со своими формочками).

В появлением NoSQL и стриминговых систем - пришлось всем признать что реляционка
исчерпала возможность линейного роста. У Майкла Стоунбрейкера есть статья где
он меряет БД под нагрузкой и доказывает что треть ресурсов CPU просто сгорает
в блокировках и защелках и прочих механизмах синхронизации.

Какой софт использует розничная торговля - сложно сказать. Там будет десяток систем которые
работают просто всместе как Grid. Например сообщения от кассовых аппаратов и платежных
систем могут в первую очередь падать в JMS/MQ систему. А уже потом процесситься и ложиться в
БД операционного дня. И по проишествии периода - сливаться Warehouse и в BigData
Есть еще вариант что в аналитику сразу попадают данные со стриминга. Я такое видел.
И это не последняя часть стека. Аналитика в свою очередь является источником для всяких
BI, витрин данных. ОЛАП-кубиков и прочее что любят смотреть и показывать на презентациях.
С красивой инфографикой.

Что использует Магнит - чорт его знает. Это можно поискать по всяким конференциям. Но само
знание или название продуктов вам ни о чем не скажет. Если они используют допустим
Kafka+Clickhouse - из этого не следует что вам это пригодится.

Были странные архитектурные решения. Uber например пытался выжать максимальные мощности
из Postgres и не смог. Перешел на MySQL. Видимо им было достаточно MyISAM и брали лишь
только те фичи что надо.

Facebook строил Rocksdb (Key-Value) с очень сильной оптимизацией по диску. Там уже было
не R+Tree а другой тип дерева. Тоже видимо у конторы так "пригорело" что им надо было
штучную NoSQL делать.

СБЕР по слухам строил на Apache Ignite прослойку между Ораклом и клиентами потому что Оракл
не справлялся с нагрузками. Впрочем я не могу это нигде доказать. Просто слышал в разговорах
архитекторов. И это очень штучное и очень деликатоное решение. Другим оно может вообще не подойдет.
Нужно много думать о механике инвалидации кешей.

Хедж фонд BridgeWater строит свои хранилища ассетов на базе Amazon S3. Реально эти ребята пихают
в С3 все что можно. И в этом есть своя стратегия. S3 стоит дешево. И масштабируется. Дешевле чем DBMS.

Также, я думаю, что множество магазинов могут быть обслуживаться отдельными кластерами, чтобы работа всей сети не остановилась, если какая та БД выйдет из строя?

Эту задачу тоже можно решать на разных уровнях. Мне нравится решение от Cassandra. Там все
таблицы имеют 1-2 реплики. И убить всю систему в целом в принципе невозможно пока последний
датацентр стоит. Но Кассандра платит за это отказом от consistency и вообще она считается не-реляционкой.
Хотя базовый диалект SQL поддерживает. Фактически она - умный NoSQL c хорошим сетевым протоколом
обхода сбоев и конфликтов. Кажется Netflix ее активно использует.

Вобщем можно дизайнить системы по разному усиливая одни части и ослабляя другие.
Это как тот треугольник дешево-медленно-дорого но в углах стоят разные качества. Например
CAP-свойства систем. Или приоритеты. Тебе что важно. Быстро записать в БД платеж? Но при этом
чтение оперативных данных потребует лагов. Или наоборот писать медленно зато чтоб все по ящичкам
и по коробочкам лежало да и еще в разных копиях и вариациях.

или все же стоит использовать
/audioList/audioList.tsx

Если не компонент:
audioList/audioList.tsx
Если компонент:
AudioList/AudioList.tsx

Какие вообще есть плюсы и минусы при использовании того или иного способа.

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

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

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

Лет 20 в web-разработке и с CMS особо не пересекался.

Какое оптимальное время въехать в проект?

Не бывает оптимального времени. Обычно заказчик и исполнитель вместе решают какое время.
Но для оценки я рекомендую следующее. Посмотреть backlog проекта. Посмотреть какие критичные
таски висят. Или блокеры. Посмотреть что у них общее.

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

Для анализа кода поставте план - график. Например 1 неделя на развертывание проекта.
Если там специфичное облако - то на изучение облака еще 1-2 недели.

План график должен включать обязательные пункты который надо пройти. Например если это
Laravel/react - то вы должны поднять в облаке привет-мир на этом стеке и продемонстрировать
что он работает. И только после этого переходить к развертыванию проекта.

Если на проекте есть архитектурная документация, confluence, wiki - то берите пару недель на чтение.
Выписывайте ВСЕ новые слова на бумажку. По ним задаете вопросы.

У вас должен быть ментор или консультант который раз в несколько дней должен отвечать
на ваши вопросы по списку. Ваш план-график должен учитывать риски и внезапные investigations
результатом которых могут быть НОВЫЕ таски которые вы сами создадите. Например - сдохли
сертификаты по сроку. Создать новые. Это время. Это тоже таски и они должны быть эстимированы.

Можно вот так. Тогда вообще по фигу, сколько массивов и какая у них длина

const sum = (...args) => (
    args.flat().reduce((acc, next) => acc += next, 0)
)

Подробнее:
Стрелочные функции
rest-параметры
ES6 reduce
ES6 flat

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

function sum(a1, a2) {
  let result = 0
  
  for (let i = 0; i < a1.length; i++) {
    result += a1[i] + a2[i]
  }
  
  return result
}

Если по теории, то мне в свое время вот эта книга помогла:
https://www.litres.ru/robert-s-martin/chistaya-arh...

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

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

Еще через пол года прочел третий раз, опять же с оглядкой на личный опыт. И тут я кажется уже совсем въехал. По крайней мере многие проблемы с организацией взаимодействия между компонентами стали разрешаться. И вообще появилось достаточно четкое понимание, как структурировать приложение и где разбивать его на компоненты.
Ну и после 3 прочтения еще помог момент: мне дали с нуля проектировать новое, достаточно крупное приложение на Rust. Притом заказчик кричал "микросервисы - это круто, хочу, хочу, хочу", а тимлид мне сказал "давай монолит, но так чтоб потом легко было распилить, а то все сроки про**ем". Вот тут прямо вообще понимание пришло. Ну и плюс в Rust архитектурные компоненты очень хорошо ложатся на отдельные крейты (это такая единица компиляции в Rust), а компилятор в принципе не дает делать циклические зависимости между крейтами.

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

Обычно статистика предваряется изучением теории вероятностей. Вот для ее понимания необходимо иметь представление о том, что такое предел и что такое интеграл. Ну и основы комбинаторики. Потом в матстатистике нелишним окажется понимание что такое оптимум, как его искать аналитически и численными методами. По мере усложнения понадобиться линейная алгебра, понимание векторного исчисления, ну и многомерная оптимизация. (Кстати, учебником "на все времена" и "для всех" считается книга Вентцель Е.С - вот она самодостаточна, кстати.)

Есть несколько полезных ресурсов. Там в основном говорят про Machine Learning, но на самом деле - их можно трактовать и как "Статистические науки"
https://habr.com/ru/post/432670/
https://www.datasciencecentral.com/profiles/blogs/...
https://www.analyticsvidhya.com/blog/2019/10/mathe...

Вот в этой, весьма неплохой книге - вообще никаких тебе сложных математических основ.
loveread.ec/view_global.php?id=76269

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