Шпиона вместо кого? У вас под этим компонентом что в зависимостях? Дочерние компоненты? Сервисы внутренние без выхода в сеть? Сервисы работающие с выходом в сеть для работы с АПИ? Еще что-то?
Я так понял, что assertEqual( app.rows()[0].title(), title ) считается «проверкой работы подразделения под руководством». А как тогда выглядел бы ассерт на проверку «умения перекладывать бумажки»?
Аналогия интересная и вроде самоочевидная. А предлагаемое «тесты более высокого уровня полагаются на то, что тесты уровня ниже уже всё проверили» в ней же — это какой вариант?
Ну то есть assertEqual( app.rows()[0].title(), title ) это проверка результата?
А как тогда выглядела бы проверка бумажки?
По итогу не понял, в чем заключается новый подход. Из заявленных определений выходит, что и система и юниты это частные случаи компонентов. Неудивительно, что после этого оказывается можно отказаться от системных и юнит тестов.
А собственно классическую оценку задач вы не проводите и Ване она не интересна? На мой взгляд у Вас вышла скорее система классификации задач по срочности деплоя, чем собственно оценки трудоёмкости задач. А ведь обычно под оценкой задач всё-таки понимают долю ресурса разрабоки, которую она займёт из какого-то отрезка времени. И используется она не для того чтобы решить, что выкатить первее, а что лучше сделать за условный ближайший месяц, вот эту большую фичу в 13 сторипоинтов или вот эти 4 фичи в 3 + 5 + 2 + 3 = 13 сторипоинтов.
В итоге получается Ваня сам мог провести такую классификацию задач и без всяких SLA примерно представлять, в какой срок какой тип задач выкатывается на прод?
Если коротко, то суть статьи сводится к тому, что не надо принимать архитектурные решения, если вы в этом ничего не понимаете?
Есть желание использовать микросервисную архитектуру в будущем продукте, надо это как-то утвердить.
Это уже прекрасно, на мой взгляд. Думаю стоило тут уже проконсультироваться с теми, кто не только в целом понимает плюсы и минусы различных архитектур, но и уже имеет практический опыт, когда какой подход хорош или плох.
Микросервисы не только в разном масштабировании полезны. Разный деплой, разные требования к надежности, к виду БД, да вот хоть к предрелизному тестированию.
И да, если криво поделить систему на микросервисы можно вместо монолита получить распределенный монолит, который обладает всеми недостатками как монолита, так и микросервисов, по этим граблям люди ходят с удивительной частотой.
Не знаю, как насчет «микро»-сервисов, но переход на отдельные bounded contexts, обменивающиеся через асинхронные сообщения прекрасно позволяет разделить работу, чтобы люди не мешали друг другу, в том числе по деплою. Каждая команда работает в своём темпе и со своей степенью надежности, нужной бизнесу. Плюс этот же подход позволяет достаточно легко и однотипно интегрировать любой сторонний функционал, мы вот Битрикс24 так подключаем — дали доступ команде разработчиков под Битрикс к нашей кафке и вперед.
Кроме прочего этот подход позволяет потрогать в продуктовой среде новые технологии не перенося на них критичные для бизнеса bounded contexts и в случае успеха плавно на них мигрировать, не переписывая на них вообще всю систему за один заход.
ИМХО, если разработчики не смогли хороший монолит и поехали на микросервисы без понимания зачем их реально используют, то с большой вероятностью у них выйдет «распределенный монолит», который обладает практически всеми недостатками как монолита, так и микросервисов.
Да там в любом случае две совершенно противоположные задачи.
Основной ходовой движок+винт должны обеспечивать максимальный КПД на длинном отрезке, а взлётно-посадочный не имеет таких требований по КПД, но тут нужна минимальная масса почти любыми жертвами. Плохое охлаждение и перегрев за 20 секунд работы — ну и пусть. 5 секунд должно хватать на взлёт или посадку.
На мой взгляд уж лучше пусть зануды, чем грохнуть несколько лет жизни и серьезные финансы в заведомо тупиковый проект. В правильно использованном (с обоих сторон) занудстве нет ничего плохого.
1. Складывать крылья (почему просто не взлетать из вертикального положения? Заодно и моторы поворачивать не надо будет). То есть вот это всё усложнение конструкции, повышение веса и снижение общей прочности стоит 2 маневров поворота в воздухе (на взлёте и потом на посадке)? Или я что-то упускаю?
2. Ставить одинаковые двигатель для взлёта/посадки и используемый в основном режиме. Навскидку основной должен быть максимально эффективный в длительном режиме, а взлёт-посадка исключительно короткий режим, не нужно заботиться о перегреве — буквально 5-10 секунд и выключаемся.
Ну то есть assertEqual( app.rows()[0].title(), title ) это проверка результата?
А как тогда выглядела бы проверка бумажки?
Это уже прекрасно, на мой взгляд. Думаю стоило тут уже проконсультироваться с теми, кто не только в целом понимает плюсы и минусы различных архитектур, но и уже имеет практический опыт, когда какой подход хорош или плох.
Кроме прочего этот подход позволяет потрогать в продуктовой среде новые технологии не перенося на них критичные для бизнеса bounded contexts и в случае успеха плавно на них мигрировать, не переписывая на них вообще всю систему за один заход.
> Но сразу перейти на микросервисы получится не у всех
А монолит в каком смысле? В том, что весь код вообще в кашу или в том, что все модули в одном сервисе и в одной базе?
А нужно прямо именно на микросервисы?
Навскидку — может там навесное какое-то габаритное, которым крутить нельзя, или груз на подвеске снизу.
Основной ходовой движок+винт должны обеспечивать максимальный КПД на длинном отрезке, а взлётно-посадочный не имеет таких требований по КПД, но тут нужна минимальная масса почти любыми жертвами. Плохое охлаждение и перегрев за 20 секунд работы — ну и пусть. 5 секунд должно хватать на взлёт или посадку.
1. Складывать крылья (почему просто не взлетать из вертикального положения? Заодно и моторы поворачивать не надо будет). То есть вот это всё усложнение конструкции, повышение веса и снижение общей прочности стоит 2 маневров поворота в воздухе (на взлёте и потом на посадке)? Или я что-то упускаю?
2. Ставить одинаковые двигатель для взлёта/посадки и используемый в основном режиме. Навскидку основной должен быть максимально эффективный в длительном режиме, а взлёт-посадка исключительно короткий режим, не нужно заботиться о перегреве — буквально 5-10 секунд и выключаемся.