Дмитрий Лузанов

Никак.
Сделай его прозрачным, и под ним напиши что угодно. Можно даже котика нарисовать.

Автор, ты спрашиваешь у поколения (30+ лет), в котором почти все из "интеллигентных" семей получили вышку, иначе это был в то время просто неадекват. Естественно, признаваться другим и себе, что за 5 лет никаких полезных знаний не было получено, большинство не будет. Я ушла с 5 курса престижного московского вуза и очень рада, что доучилась почти до конца - теперь я наверняка знаю, что там ничему не учат и байки про "специальные предметы начнутся на старших курсах" - это байки. Вузы для программистов - это бизнес на родителях, вот и все. Аргументы любителей вузов:

- некие большие компании, куда закрыт ход без корочки - если ты нормальный специалист, ты сам выбираешь, где тебе работать, можешь вообще делать свои продукты/плагины/игры/уроки и продавать, получая пассивный доход
- переезд за границу - см. пункт 1, если ты нужен компании, тебя перевезут. Только часто бывает выгоднее работать по удаленке
- знания - на деле это черчение, матан, физика, культурология, физра, экономика, экология, философия и какой-нибудь С# и SQL на уровне, который 10-летний ребенок освоит за 2 недели (без преувеличения).
- "учит учиться" - меня скорее вуз научил пить и списывать, кстати рекомендую сдавать экзамены по билетам с микронаушником в ухе и другом на проводе, острые ощущения

Ничего. Идите со своими реальными знаниями. Все остальное - бесполезно

По принципу единственной ответственности метод getSum должен лишь возвращать сумму. Никаких дополнительных действий в нем происходить не должно.

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

const sum = arr => arr.reduce((acc, i) => acc + i);

const calculateSquaresSum = arr => sum(arr.map(i => i.calcArea()));

Для логгирования в dev режиме обычно используют декораторы или middleware.

Проверка на четность через рекурсию? Это где вы такое нашли? Ну, -n делается для того, чтобы отбросить минус, чтобы потом удобно делать n - 2 (и не идти в минус бесконечность).
т.е. логика такая, отнимаем у числа каждый раз двойку, и если мы дошли до числа 1, то число нечетное, если до нуля, то четное.
Вот вам нормальная функция

const isEven = function(number) {
  return number % 2 == 0;
};

Начинать надо вот так: https://angular.io/guide/quickstart
Установил, создал проект, запустил и работаешь.

А вот это ожидание по 30+ секунд, это попахивает кривым гайдом, либо кривым проектом. Воспроизведи проблему на https://codesandbox.io

Сначала идет ТЗ. Потом - протоколы взаимодействия. А потом - уже все равно, хоть одновременно и веб и фронт. Это в сферическом идеале.

По моему мнению нужно использовать первый вариант.
Вся суть Promise, что с начального состояния мы можем перейти в состояние
* выполнено (fulfilled): операция завершена успешно.
* отклонено (rejected): операция завершена с ошибкой.

по логике, если возникла ошибка при асинхронной операции, то мы должны сделать reject(errors) и в дальнейшем обработать исключение в catch().

Второй вариант может неправильно отработать в цепочке Promise.all(iterable), когда нужен явно выполненный результат несколько Promise.

какие паттерны применяются чаще всего на практике и где

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

1. Модули (делим код на независимые части)
   
2. Фабрики (для компонентов интерфейса)
   
3. Синглтоны (для хранилищ, точек сбора полифиллов / утилит и.т.д.)
   
4. Адаптеры (для зависимостей и полифилов, которые могут измениться / выпилиться)
   
5. Наблюдатели (для сбора происходящих событий в одном месте)
   
6. Хранители (для сохранения действий пользователя и "Ctrl-Z")
   
7. Стратегии (если действуем в зависимости от прилетевших данных)
   

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

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

result.hasOwnProperty(i) не может быть false. Во всяком случае я не придумал подходящего "кейса".

Может быть и false, если какое-то свойство определено в прототипе:

class Test {
    constructor() {
        this.foo = 'foo';
    }
};

Test.prototype.bar = 'bar';

const test = new Test();

console.log('foo' in test); // true
console.log('bar' in test); // true
console.log(test.hasOwnProperty('foo')); // true
console.log(test.hasOwnProperty('bar')); // false

Цикл for..in перебирает свойства объекта и всех его прототипов. Чтобы исключить свойства прототипов из цикла используется проверка hasOwnProperty.
Сейчас это считается устаревшим, в моде перебор объекта через Object.keys/Object.values/Object.enties с помощью for..of или перебирающих методов Array.

т.е. нынче конструкция

for (var i in result) {
    if (result.hasOwnProperty(i)) {
        //Остальной код
    }
}

должна выглядеть так

Object.keys(result).forEach((i) => {
  //Остальной код
});

интересно на чем же он сделан.....