Что я узнал после более чем 1000 code review

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

Просто у нас это настолько повсеместно, что считается нормальным.

История архитектуры Dodo IS: путь бэкофиса

Это места стыковки с остальной системой. Само по себе взаимодействие клиента с сервером не изменилось.

То есть при выделении сервиса никаких новых сетевых взаимодействий не возникло?

Чтобы выделить сервис, вовсе не обязательно выковыривать код его бизнес-логики из старой системы.

Попробуйте заменить в этих рассуждениях "сервис" на "модуль" или "сборку" — получится то же самое, нет?

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

Но логически можно выделить отедльный модуль и без выделения в сервис. Кроме, того, что сетевое взаимодействие накладывает дополнительные ограничения на связанность (например, в DDD есть правило, что нельзя делать ссылки внутрь агрегатов, но, насколько я знаю, нет способа проверять это правило. В случае сервисов не получится его не соблюдать так как нельзя делать ссылок внутрь сервиса)

Я пытаюсь понять, что для вас было главным — технические проблемы или логические.

Где-то у Фаулера я видел рекомендации сначала, выделять отдельные модули, потом, отделять хранилища (условно, чтобы модули взаимодействовали внутри с ограничениями характерными для микросервисов, но in-process), потом, выделять микросервисы.

История архитектуры Dodo IS: путь бэкофиса

А где тут "сетевое взаимодействие"? Этот отдельный домен может быть модулем, а не сервисом. Если никто не знает всех нюансов, то как они потом переключат использование на сервис — там будут абсолютно те же самые проблемы что и в случае использование отдельного модуля + дополнительные проблемы связанные с сетевым взаимодействием.

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

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

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

История архитектуры Dodo IS: путь бэкофиса

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

Почему? Разве это не то же самое + накладные расходы на то, что с сервисом надо учитывать все особенности сетевого взаимодействия?

Объясните мне, как вы для себя разобрались в моделях типизаций — они же все размыты

С чего вы решили, что из приведенной цитаты этого не следует?

С того, что там автор говорит о мнении авторов языка, а не о своем. По остальным вопросам, вам, вроде ответили в других комментариях.

Объясните мне, как вы для себя разобрались в моделях типизаций — они же все размыты

В его случае принцип LSP будет соблюдён, так как в обоих случаях Close() описывает финализирующюю операцию

В данном случае это значит, что среди двух методов можно найти что-то общее, а не то, что они тождественны. Так же можно сказать, что они оба методы.

метод sub(x, y) будет возвращать сумму при аргументах sub(-2, -2).

Да он будет возвращать число равно сумме, но других чисел: -2 и 2. Оно так же будет равняться произведению 1 и 0

Объясните мне, как вы для себя разобрались в моделях типизаций — они же все размыты

Нет, это не правда. Проблема вашего непонимания в том, что вы говорите о Классах и Типах как об одном и том же.

С чего вы решили, что автор считает что это одно и то же. Из приведенной цитаты этого не следует.

Если множество запросов совпадает — значит у объектов Тип будет общим, независимо от того к какому Классу эти объекты принадлежат.

Метод void Close() и метод void Close() это один и тот же запрос?

А вот так:

/*  Закрывает окно, потом его можно переоткрыть при помощи Open()
*/
void Close()

/*  Закрывает поток, поток нельзя больше использовать. Изменения сбрасываются в файл на диске.
*/
void Close()

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

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

Нет таких понятий.

https://en.wikipedia.org/wiki/Structural_type_system

Любой ЯП это просто текст в файлике, который так или иначе в итоге станет машинным кодом.

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

Нет «серьёзных» и «несерьёзных» языков программирования,

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

За 7 лет рабочего опыта пора уже отучится от таких детских взглядов на программирование и код.

Вы очень категоричны и неуважительны.

Объясните мне, как вы для себя разобрались в моделях типизаций — они же все размыты

В .NET есть разные штуки чтобы генерировать промежуточный код в рантайме. Можно компилировать ExpressionTree или генерировать байткод.

Можно скомпилировать DLL из исходного текста и подгрузить в процесс.

В стандартной библиотеке регекспы компилятся.

Объясните мне, как вы для себя разобрались в моделях типизаций — они же все размыты

берём юнит, который содержит код, ходящий в http или в Database.
его тест — юниттест или не юниттест?

Юнит тест это размытое понятие. Что конкретно имел ввиду 0xd34df00d под ним — надо спросить у него.

"многие не любят" — это что-то странное.

Почему. Многие не любят острую пищу. Чем это странное понятие? В реальности такое считается.

Напоминаю, мы не обсуждаем нужны ли юнит тесты, мы обсуждаем считает ли 0xd34df00d что никаие автоматические тесты не нужны. По его посту очевидно, что он считает что какую-то часть тестов он считает избыточной при статической типизации а не то, что никакие тесты не нужны.

Объясните мне, как вы для себя разобрались в моделях типизаций — они же все размыты

Он написал о ненужности юнит тестов, а не тестов вообще. Юнит тесты многие не любят

Объясните мне, как вы для себя разобрались в моделях типизаций — они же все размыты

Что такое "вполне типизированный"? Как F# в котором есть поддержка единиц измерения? Или как C?

Объясните мне, как вы для себя разобрались в моделях типизаций — они же все размыты

Можно убрать return и фигурные скобочки

static string Display(object o) =>
    o switch
    {
        Point p when p.X == 0 && p.Y == 0 => "origin",
        Point p                           => $"({p.X}, {p.Y})",
        _                                 => "unknown"
    };

Объясните мне, как вы для себя разобрались в моделях типизаций — они же все размыты

А в каком языке (кроме Idris 2) вы это можете делать?

C#

Объясните мне, как вы для себя разобрались в моделях типизаций — они же все размыты

Насколько я понимаю, хаскеллевские алгебраические типы компилируются во что-то подобное. 0xd34df00d, вероятно, не считает kind информацией о типе

Объясните мне, как вы для себя разобрались в моделях типизаций — они же все размыты

https://en.wikipedia.org/wiki/Tagged_union#1970s_&_1980s

enum ShapeKind { Square, Rectangle, Circle };

struct Shape {
    int centerx;
    int centery;
    enum ShapeKind kind;
    union {
        struct { int side; };           /* Square */
        struct { int length, height; }; /* Rectangle */
        struct { int radius; };         /* Circle */
    };
};

Объясните мне, как вы для себя разобрались в моделях типизаций — они же все размыты

А этот инт логически не будет информацией о типе?

Программист не должен решать задачи бизнеса

Программист вообще ничем заниматься не обязан кроме программирования. По определению слова "программист".

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

Программист не должен решать задачи бизнеса

Т.е.

• Вам это нравится
• Для вас это необременительно
• В качестве постоянного занятия это было бы много.

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

Программист не должен решать задачи бизнеса

Почему вы пишете на форум сами а не наняли специального флеймера?

Хватит натягивать сову на глобус

Какую проблему в этом процессе может решить канбан?

Доска отвечает на вопрос чем именно занимается команда и "есть ли что потестить"

WIP отвечает на вопрос стоит ли сейчас помогать тем, кто тестирует обычно или лучше покодить.