Здравствуйте, landerhigh, Вы писали:

blp>>Иэх. Это опять-таки очень неконкретно. Начиная откуда оно само получится?
L>Начиная с появления некоей критической массы тестов.
это тоже неконкретно.

L>Здесь придется сначала разделять задачи и ответственность. Нельзя объять необъятное. Бригаду обезьян перевоспитать с наскока не получится, их надо медленно варить.
Собственно, мой основной вопрос был как раз про детали этого медленного варения. Судя по ответам, ваш случай относится к маленькой команде в 5-7 человек, которая не распределена географически. Моя ситуация про команду раз в 10 большую, распределенную примерно в 3 таймзонах.

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

> Однажды бригадир обезьян придет утром и обнаружит, что билд сломан. А сломан он потому, что юнит-тест, который незаметно для них стал частью билд процесса, перестал проходить.
У нас билд никогда не сломан, потому что ломающий чендж не дает зачекинить CI — т.е. при наличии тестов все поломается еще раньше. Проблема в том, что код задизайнен и дизайнится так, что тестировать его либо невозможно либо трудно. Просто потому что о тестах думают постафактум

> А проходить он перестал потому, что бригада обезьян закоммитила breaking change, не протестировав его никак.
Такое становится понятным сильно позже, потому что breaking change вылез где-то в integration pipeline или доехал до продакшена.

blp>>Это в прниципе понятно и очевидно. Мой вопрос был про реальные ситуации, когда произошел квантовый переход В частности про ту, что так красочно описана в блоге — сколько там напрмиер было людей в команде и какого размера был проект. А то сейчас выяснится, чот людей было 2 (я и Иа-Иа) и один из них был тот самый маньяк.

L>Размер команды не имеет такого большого значения.
Не согласен.

>Конечно, в небольшой локализованной команде до 5-7 (кстати, размер команды из поста) разработчиков внедрять новые подходы намного легче, нежели в распределенной команде о 50 человеках. Нужно начинать снизу, с небольших команд.
"Снизу" не начинается, потому что команды шарят достаточно большой проект и имеют зависимости друг на друга.

L>Тут нужно еще понимать, какой будет выхлоп.
Да выхлоп как раз понятен — ускорение релизов, уменьшение числа регрессий, снижение он-колла. У нас не коробочный продукт, а сервис с довольно частыми релизами (~раз в неделю) и он-коллом.