Батон хлеба:

• Наличка: 100 р.

• Банк 1: 99 р.

• …

• СБП: 98,5 р.

И в этой схеме нельзя делать сложные бонусы в виде миль / спасибо / 5-ый кофе в подарок.

Ну или надо честно разделять стоимость товара и издержки платёжной системы. Но это тоже усложнит понимание. Будет "Батон: 98 р." А потом на кассе: с вас 98 р + вариативная плата в зависимости от выбора вами способа платежа.

То есть Кешбек — это попытка инкапсуляции сложности финансовых взаимодействий. Да, как и любая абстракция она иногда протекает.

В ОС телефона уже есть главный экран с часто используемыми приложениями. Редкоиспользуемые и утилиты заметены под папки на дальних экранах. Так же у вас есть в распоряжении виджеты, где можно красиво выводить всё что вам нужно.

И вот вопрос: зачем вам суперапп? Зачем вам открывать ОС, чтобы там была одинокая иконка суперапа, внутри которого будет "мир" сравнимый с ОС? Не проще ли сразу всё делать в ОС, зачем лишняя абстракция?

И это не говоря о том, что в ОС у вас свобода выбора приложений, которые вам нравятся: любимые карты от "А", Почта от "Б", Банк от "В" и так далее. В супераппах вам придётся или ставить себе 2-3-5 разных супераппа с пересекающимся функционалом, половиной от которого вы не будете пользоваться или смириться с "вендорлоком", меняя экосистемы целиком.

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

В теории упрощается заполнение склада перед постаматом, так как тебе только подать на ленту, а робор сам всё разложит по полкам. Ну и бонусом склад для робота + окно выдачи должны быть гораздо вместительней, чем постамат для аналогичного количества посылок.

Я бы больше сказал, что они распратраняют товары и людей.

Оператор строгого равенства (а не тройного), не сработает. NaN === NaN вернёт false.

Благодаря этому мы и определим :)

function myIsNaN(value) {
    // Тут используем строгое равенство :) 
    return (value === value) === false;
}

Покажите пример использование переменной до её объявления

Так можно делать с var (но не нужно!) и с функциями.

myFunc();

function myFunc() {
    x = 5
    console.log(x);
    var x = 2
}

через какое-то время на выходе получим пачку лояльных и заточенных под конкретные задачи мидлов за небольшие деньги.

Звучит как джун, конечно :)

1. технического писателя, который пишет документацию, может и ТЗ оформить для истории и

2. PM (project manager), который общается с заказчиком?

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

Вы приводите бизнес аналитики в примерах. Бизнес-аналитик в классическом понимании — экономист, который разбирается в процессах, экономике, финансах, организационном развитии и помогает компании решать стратегические задачи.  (Из интернета)

То есть полезный член команды, но не команды разработки.

Вот когда появятся IDE, которые за меня ошибки исправляют, тогда и поговорим

Вот когда они не только ошибки исправлять будут, но и переменную подскажут, тогда и поговорим

С этими пунктами тоже проблема на самом деле:

• ошибки только алгоритмические (и то не все) и линтеры оформления кода, о логике нет и речи

• Переменные, это просто подсказка всех доступных переменных в текущем блоке кода. Часто даже без учета типа (легко предложат строковую переменную в математическое выражение подставить)

Так что тут бы я тоже не спешил с прогрессом. Удобно? Да. Можно лучше? Однозначно есть куда расти.

interface IBase {
    a(): void
}

class BaseImpl implements IBase {
    a(): void {
        this.b()
    }

    b(): void {
        console.log('BaseImpl')
    }
}

type Constructor = new (...args: any[]) => IBase;

function withDerived<TBase extends Constructor>(Base: TBase){
    return class Derived extends Base {
        b() {
            this.a() // тут будет вечный цикл вызовов
            console.log('Derived')
        }
    }
}

const Derived = withDerived(BaseImpl);
const derivedObj = new Derived();
derivedObj.b();

1. в TS запрещано в миксине объявлять protected / privated методы (как я написал выше). Так же мы не можем переопределять protected методы родителя
2. Нет гарантий, что несколько миксинов не будут перетирать public методы друг друга.

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

Идея не новая. В Typescript она называется mixins.
Возможно, что и в JS есть что-то подобное. Я встречал реализацию подобной идеи через Object.assign(...)