Есть смысл в отслеживании тенденции

Расчёт покрытие или падает

Тенденция может дать пищу для размышлений о состоянии разработки

Если покрытие падает, значит скорее всего начали "слишком" спешить, не исключено что тех долг нарастает

Когда нужно говнокодить, чаще всего в первую очередь забивают на тесты

"нужно говнокодить" - звучит как цель. Интересно, что о такой цели думают руководители.

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

Нет конечно

Это вопрос сложный.
Автоматическое тестирование - один из способов обеспечения качества разрабатываемого ПО.  
Одних только требований по покрытию очевидно недостаточно для обеспечения качества, т.к. код может быть покрыт на 100% и делать полную фигню, т.к. в тестах ... почти не будет assert'ов )))  Однако, в сочетании с другими подходами (статический анализ кода, процедуры код ревью, ручное тестирование) это, как правило, работает на благо проекта.

Когда команду поставили в позу, в которой решить задачи можно только если стремительно говнокодить

А как же инженерное сопротивление плохим решениям?

Вы же открываете ящик пандоры и будете до конца проекта пострадывать

Ну так это примерно как я написал про крышу - если черепицей покрыть ее на 100% но сверху вниз, хозяин будет недоволен...

И бизнес, и клиенты будут пострадывать, не только разработка, тестирование и эксплуатация

Не знаю. Я просто на хер посылал руководителя и команда продолжала заниматься дизайном и писать тесты. Меня соответственно лишали части премии. Всё честно))

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

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

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

Господа, подскажите умные слова для гугления следующей задачи: есть сервис, состоящий из N инстансов, есть 2 клиента, нужно обеспечить передачу куска данных по цепочке сервис -> клиент 1 -> клиент 2 -> сервис, так чтобы кусок данных оказался на том же инстансе сервиса, с которого и начал своё движение. Мне в голову приходит 2 варианта решения: балансировка запросов по какому-нибудь ключу, который могут знать (генерить) клиент 1 и клиент 2, тогда они оба попадут на один и тот же инстанс сервиса, либо общее хранилище/кэш/дистрибьютед очередь между сервисами, тогда данные от клиента 2 поступают в эту хранилку, а оттуда подсасываются в нужный инстанс сервиса. Потерями при вылете одного инстанса сервиса можно пренебречь.

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

Может быть я не знаю какого-то ещё очевидного инженерного решения для такого рода проблем?

Звучит как обычное шардирование с consistent hash по идентификатору клиента, если требуется стейтфул сервисы или стейтлесс, если все будет в едином хранилище, а сервисы взаимозаменяемы за лоад балансером

Ну то есть других решений не видите тоже :) Шардирование — по сути в моём варианте "на лоад-балансере".

Ну тут кажется и нет больше вариантов (хотелось бы ошибаться), ибо все придумано давно за нас, нужно только выбрать что удобнее))

так вообще в принците вариантов всего 2: точка-точка, точка-хаб

Ну, теоретически, можно сделать shared state c hash-ring-ом между инстансами сервиса и при получении запроса роутить его на нужный инстанс уже внутри... но это всё сказки для хороших программистов, а не х-х и в продакшен