Почитал вот это, понял, что ситуация у нас в команде чем-то напоминает переход от состояния "до н.э" до "после н.э". Хочется начать дикусскию, чтобы узнать больше контекста.
Есть ряд вопросов к тем, у кого есть подобный опыт внедрения какой-то новой практики в команде, которая работает по принципу "копаем, как можем, когда надо можем копать быстрее, нанимаем больше копателей, об эскавторах не думали, ибо слишком сложно"
— сколько людей писало код, приведенный для примера? (какой был размер команды)?
— что собой представляло "внедрение" технологии юнит-тестирования?
— какие полномочия были у внедряющего, какая у него была отвественность?
— как решался вопрос "мне надо копать, а тесты писать некогда"
— как решался вопрос "а я не знаю, как отрефакторить этот код, и вообще мне копать надо"
Если вкратце, то практически каждый Pull Request (PR) должен содержать тест(ы). На каждый PR build server должен прогонять все тесты и не давать аппрувить/мёржить PR, если тесты не проходят. Вопрос "мне некогда писать тесты, я копаю" решается менеджеровским решением, что теперь к каждой раскопке должны быть приложены тесты (если это возможно).
При этом не надо совсем уж впадать в крайности, надо действовать по ситуации, а не по религии. Т.е. в каких-то ситуациях можно обойтись без теста. Ну и вообще не надо слепо дословно следовать TDD, т.е. постоянно писать тест до кода — это крайность.
Здравствуйте, MozgC, Вы писали:
>На каждый PR build server должен прогонять все тесты и не давать аппрувить/мёржить PR, если тесты не проходят.
это само собой — делается, более того build server интегрирован с code review и автоматически показывает построчный code coverage — сразу видно, например, что новый код не протестирован.
>Вопрос "мне некогда писать тесты, я копаю" решается менеджеровским решением, что теперь к каждой раскопке должны быть приложены тесты (если это возможно).
Что такое "если это возможно"? Кто это определяет? Менеджер ходит по всем code review и лично прикладывает палец к носу и говорит, что "тут но невозможно, можно без тестов" / "а вот тут ты потратишь еще 2-3 и тесты можно будет написать — бросай копать и переписывай код, чтобы можно его было протестировать"? Этот подход не скейлится и не работает когда в команде 10-15 человек или больше.
MC>При этом не надо совсем уж впадать в крайности, надо действовать по ситуации, а не по религии.
Так я с этого и начал разговор — как именно внедряется это "действовать по ситуации" на практике — хочется послушать тех, кто реально внедрил — на каком масштабе и как именно.
Здравствуйте, blp, Вы писали:
blp>- сколько людей писало код, приведенный для примера? (какой был размер команды)? blp>- что собой представляло "внедрение" технологии юнит-тестирования? blp>- какие полномочия были у внедряющего, какая у него была отвественность? blp>- как решался вопрос "мне надо копать, а тесты писать некогда" blp>- как решался вопрос "а я не знаю, как отрефакторить этот код, и вообще мне копать надо"
Для начала, любая религия — это зло. 100% покрытие тестами — зло, фанатичное следование "бест практисам" — зло, запихивание архитектуры в прокрустово ложе паттернов проектирования — зло. Религия нужна только тогда, когда нет понимания.
Внедрение делается достаточно просто — до команды доводится (или команда договаривается) о т.н. definition of done, т.е. что такое качественно сделанная задача. После этого некачественно сделанные задачи (например, без тестов) отправляются обратно на доделку. Обязательное ревью всех PR позволяет заставить разработчиков следовать этой практике, даже если они торопятся.
Примеры DoD применимо к тестам:
— на каждую задачу/тикет должен быть хотя бы один тест, запускающий свеженаписанный код
— предыдущее плюс хотя бы один тест, отправляющий корректный запрос (с точки зрения бизнеса) и проверяющий результат
— предыдущее плюс хотя бы один тест, отправляющий некорректный запрос и проверяющий текст ошибки
— тесты на все тест кейсы, указанные в тикете (если аналитики практикуют cucumber-style)
Более жесткие варианты я не встречал, сеньорные разработчики определяют нужное кол-во тестов интуитивно.
Про полномочия: В принципе, это внутренее дело команды. Команда должна согласиться писать тесты и дорабатывать отвергнутые из-за тестов PR. ДОстигнуто ли это путем переговоров, неформального лидерства или приказом сверху — не так важно.
Что касается именно TDD — как религия, это личное дело каждого. Важно только кол-во и качество тестов на выходе.
Здравствуйте, scf, Вы писали:
scf>Здравствуйте, blp, Вы писали:
blp>>- сколько людей писало код, приведенный для примера? (какой был размер команды)? blp>>- что собой представляло "внедрение" технологии юнит-тестирования? blp>>- какие полномочия были у внедряющего, какая у него была отвественность? blp>>- как решался вопрос "мне надо копать, а тесты писать некогда" blp>>- как решался вопрос "а я не знаю, как отрефакторить этот код, и вообще мне копать надо"
scf>Для начала, любая религия — это зло. 100% покрытие тестами — зло, фанатичное следование "бест практисам" — зло, запихивание архитектуры в прокрустово ложе паттернов проектирования — зло. Религия нужна только тогда, когда нет понимания.
вот блин, я уже жалею, что выбрал этот заголовок. Я ничего такого не имел в виду, просто пост по ссылке уж очень отдает чем-то сектантско-фанатичным.
scf>Внедрение делается достаточно просто — до команды доводится (или команда договаривается) о т.н. definition of done, т.е. что такое качественно сделанная задача. После этого некачественно сделанные задачи (например, без тестов) отправляются обратно на доделку. Обязательное ревью всех PR позволяет заставить разработчиков следовать этой практике, даже если они торопятся.
вы участвовали в этом лично? Меня интересуют конкретные детали того, что такое "договаривается лично" и "понимает интуитивно".
scf>Про полномочия: В принципе, это внутренее дело команды. Команда должна согласиться писать тесты и дорабатывать отвергнутые из-за тестов PR. ДОстигнуто ли это путем переговоров, неформального лидерства или приказом сверху — не так важно.
"Команда должна согласиться" — команда соглашается, но продолжает работать как раньше, члены этой команды аппрувят друг другу код, не покрытый тестами и вопросов про покрытие тестами не задают. Меня как раз интересует этот момент, который вами определен как "не так важный" — как именно в вашем опыте, это было сделано, какой был размер команды и т д
Здравствуйте, blp, Вы писали:
blp>Здравствуйте, scf, Вы писали:
blp>вы участвовали в этом лично? Меня интересуют конкретные детали того, что такое "договаривается лично" и "понимает интуитивно".
blp>"Команда должна согласиться" — команда соглашается, но продолжает работать как раньше, члены этой команды аппрувят друг другу код, не покрытый тестами и вопросов про покрытие тестами не задают. Меня как раз интересует этот момент, который вами определен как "не так важный" — как именно в вашем опыте, это было сделано, какой был размер команды и т д
В моем конкретном случае — указание сверху от тех.дира. Команда маленькая, 3 человека. Люди адекватные, саботажа не было.
scf>В моем конкретном случае — указание сверху от тех.дира. Команда маленькая, 3 человека. Люди адекватные, саботажа не было.
Спасибо. Как именно тех дир контроллировал процесс выполнение своего указания?
Если люди адекватные, почему команда до этого указания с самого начала тесты не писала ? (а если писала, что именно изменилось)?
Здравствуйте, blp, Вы писали:
blp>Спасибо. Как именно тех дир контроллировал процесс выполнение своего указания? blp>Если люди адекватные, почему команда до этого указания с самого начала тесты не писала ? (а если писала, что именно изменилось)?
git тогда еще не был популярен, использовался svn. техдир периодически смотрел коммиты и заставлял добавлять тесты тех, кто этого не делал.
Отсутствия опыта разработки, мы все студентами были.
Здравствуйте, scf, Вы писали:
scf>git тогда еще не был популярен, использовался svn. техдир периодически смотрел коммиты и заставлял добавлять тесты тех, кто этого не делал.
Спасибо, а "периодически" — это сколько коммитов в день/неделю и как часто?
"Заставлял" — приходил и требовал все бросить и переделать? "Добавить тесты" иногда довольно трудно ретроактивно.
blp>Есть ряд вопросов к тем, у кого есть подобный опыт внедрения какой-то новой практики в команде, которая работает по принципу "копаем, как можем, когда надо можем копать быстрее, нанимаем больше копателей, об эскавторах не думали, ибо слишком сложно"
Не внедряйте. Ваша команда состоит из людей, которые чувствуют себя комфортно без тестов (иначе они бы уже ушли в другое место). Есть занудные девелоперы, которые знают что хотят писать тесты и поэтому просто не пойдут в команду, где тесты не пишут. Есть гибкие коммуникабельные бизнес-ориентированные девелоперы, которые просто берут и делают "что хочет бизнес". В вашей команде занудных девелоперов нет.
Если всё-таки станете внедрять, стоит начать с проблемы, которую тестирование призвано решить. Например у вас 90% пофикшенных багов переоткрываются через каждые полтора релиза. Или там производительность ключевых фич непредсказуемым образом деградирует и выясняется это от юзеров. В зависимости от проблемы внедрять вы захотите совершенно разное тестирование. Вот вы например пишете конкретно юнит-тестирование (типа "1 класс — 1 тест"). Почему не интеграционные тесты например (типа "одна операция API — вся цепочка от фасада до БД — 1 тест")?
Здравствуйте, blp, Вы писали:
blp>Спасибо, а "периодически" — это сколько коммитов в день/неделю и как часто? blp>"Заставлял" — приходил и требовал все бросить и переделать? "Добавить тесты" иногда довольно трудно ретроактивно.
несколько раз в неделю я думаю. да, бросить всё и писать тесты.
Здравствуйте, blp, Вы писали:
blp>вот блин, я уже жалею, что выбрал этот заголовок. Я ничего такого не имел в виду, просто пост по ссылке уж очень отдает чем-то сектантско-фанатичным.
Он будет таким неизбежно по очень простым причинам:
1. Начиная с какого-то уровня и состава команды горизонтальные договорённости перестают работать. Можно работать чисто на сознательности в небольшой команде, но увеличение количества людей, приход временных людей — приводит к тому, что такие договорённости перестают работать, и начинают требоваться жёсткие формальности.
2. Опять же, если состав команды меняется, то новых людей надо вводить в курс всего происходящего — что за код, как он работает, почему так... Время на это может быть заметное. Мой текущий начальник утверждает, что на полное введение нового человека в наш текущий проект требуется год его работы в рамках проекта. Я не уверен в этой цифре, но оспаривать не буду. Да, у нас тяжёлая специфика — IP-телефония (которая сама по себе ой непроста за пределами тупейших сценариев), управление с навороченной (в основном осмысленно) логикой, и всё такое. Но это тем более значит, что код должен быть достаточно простой и понятный, и тестами должно быть по максимуму обложено всё, чтобы даже случайно ничего не поломать.
А на "галерах" аутсорсинга — ещё и значительно сильнее давление времени и, соответственно, цены работы программиста. Возможность быстро (считай, мгновенно) вкурить конкретный код, что он делает и как, подправить его так, чтобы понятно было типовому коллеге, не тратя дни и месяцы на анализ происходящего — имеет высочайшую ценность. Отсюда растут все эти SOLID, паттерны и тому подобное — чтобы даже в мыслях не было "сделать выбор по подтипу значения вместо того, чтобы добавить виртуальную функцию", чтобы решение типа "сюда втыкаем адаптер" приходило мгновенно, и так далее.
У меня история в этом плане была следующая:
1. Проект ведёт 2 человека, я и старший коллега, договориться о всём — нет проблем, тестирование — только живое.
2. Старший уходит, тяну проект сам. Добавляю какие-то простые средства тестирования, но суровой нужды в них ещё нет, ручной контроль тупо проще и быстрее.
3. Одновременно приходят усложнение и новые люди, которые начинают ломать самые основы. Срочно реанимирую свои автоматические тестовые заготовки. Рисую базовый комплект сценарных тестов — собирается урезанная версия установки, где замоканы внешние участники и ненужные для конкретного теста блоки логики, рисую эмулятор юзерских телефонов и цепляю к тестам. Приказываю все изменения перед коммитом прогонять через тесты (простого make хватает).
4. Ухожу в другое место. Возвращаюсь и вижу цивилизацию — CVS заменён на Git, автотесты загнаны в Jenkins. Количество тестов плавно увеличивается.
5. Снова ухожу. Пока меня нет, новые порядки устанавливают, что каждая новая функциональность должна быть протестирована (а если это невозможно, тикет и сообщения коммита должны это описывать, явными словами, английским по фоновому).
6. Снова тут, тестов просто дофига (и снова, ~90% сценарных, но где возможно и осмысленно — и юнит-тесты). Сложность системы (количество сущностей для одновременного понимания) немного превосходит зашкальную. Без тестов вероятность сломать что-то уже работающее близка к 100%. Типичный вариант — доработал 1-2 целевых для изменения, отправил в CI или в полный прогон на своей виртуалке, получил 5-10 сломанных, исправил, ещё пару циклов — можно показывать коллегам.
Разумеется, правило, что что-то добавил — допиши тест, сохраняется. И есть постоянная задача допокрывать уже сделанное (в основном отдаётся новичкам).
В статье не было вроде явного TDD, говорилось только про юнит-тестирование. TDD это уже следующий уровень: сам по себе он — некорректное сочетание вполне корректных базовых принципов, и за пределами идеальных для него условий (новый (с нуля) интеллектуально низкий код) может работать только если заметно отклоняться от его принципов. Но TDD — это средство для больших команд с многоуровневой структурой, потому, что в случае нарушений его принципов нарушителей и их руководителей ждёт возмездие не за какие-то потерянные проценты покрытия, а за неподчинение административным предписаниям. То есть ещё более высокий уровень того же.
scf>>Внедрение делается достаточно просто — до команды доводится (или команда договаривается) о т.н. definition of done, т.е. что такое качественно сделанная задача. После этого некачественно сделанные задачи (например, без тестов) отправляются обратно на доделку. Обязательное ревью всех PR позволяет заставить разработчиков следовать этой практике, даже если они торопятся. blp>вы участвовали в этом лично? Меня интересуют конкретные детали того, что такое "договаривается лично" и "понимает интуитивно".
А любые конкретные детали слишком специфичны для задачи и команды. Увы, тут общего принципа не будет, или же он лежит в психологической плоскости.
Можете попробовать, конечно, набрать 100 примеров и поискать общее. Только я сомневаюсь, что тут будет что-то более новое по сравнению с данными книг типа "Как пасти котов".
scf>>Про полномочия: В принципе, это внутренее дело команды. Команда должна согласиться писать тесты и дорабатывать отвергнутые из-за тестов PR. ДОстигнуто ли это путем переговоров, неформального лидерства или приказом сверху — не так важно. blp>"Команда должна согласиться" — команда соглашается, но продолжает работать как раньше, члены этой команды аппрувят друг другу код, не покрытый тестами и вопросов про покрытие тестами не задают.
А вот тут уже административный вопрос. Если есть какой-то руководитель, который отвечает за результат, в том числе пусть и косвенно, но денежно — он должен уметь контролировать выполнение, иметь для этого средства и делать это.
Я очень плохо представляю себе вариант, чтобы такая ответственность была разделена между более чем 3 человеками в команде. Между собой они уже, наверно, договорятся. Хотя метод опционов и владения частью акций может растягивать ответственность на много людей, всё равно нужен решающий голос.
blp> Меня как раз интересует этот момент, который вами определен как "не так важный" — как именно в вашем опыте, это было сделано, какой был размер команды и т д
У вас реально команда без начальника? И даже без неформального лидера?
Здравствуйте, blp, Вы писали:
blp>в тредик приглашается langerhigh
Надо же, какую я вкусную тему пропустил. Я сюда редко захожу, сорри.
TDD не должно быть религией. Это просто инженерная практика. В некотором смысле, гигиена.
Внедряться полномочиями оно не может. Не работает схема, когда "тимлид сказал — пишем тесты", и все заверте... В принципе не работает.
В лучшем случае будет пара сотен странных типа тестов, непонятно что тестирующих и непонятно как запускаемых, ломающихся в зависимости от погоды на Марсе. В худшем случае.. не будем об этом.
В большинстве случаев в команде все разработчики работают по схеме "как заведено". В компании, в команде, на конкретном проекте. Поэтому, если юнит-тестирование в проекте не было принято, внедрить его будет непросто.
Нужен разработчик-маньяк, который немного пошатнет устои и поведет остальную команду за собой.
Покрыть тестами уже имеющийся код обычно просто нереально или неразумно.
Покрывать тестами код новый и/или изменяемый — можно и нужно. Вот именно это и должен показать этот самый маньяк, а спустя какое-то время оно обычно само получится — к удобству "написал кое-что, набросал 10 тестов, набрал make check, обломался, поправил код, поправил тесты" и "внес изменения, make check показал 100500 сломавшихся тестов, обсудил с ребятами, все пофиксил" привыкают очень быстро.
Через какое-то время приходит понимание, что юнит-тесты позволяют избавиться от ситуации "мы не вносим изменения в этот код, так как риск регрессии крайне высок, а на полное тестирование ресурсов не выделяют", и тесты уже перестают восприниматься как ненужная работа (к вопросу о "тесты писать некогда, копать надо").
Как этого добиться? Ну, нужен маньяк. Еще нужна метрика. К примеру, в виде покрытия кода тестами. Впрочем, меня устраивает просто абсолютное количество тестов. Если любая из этих метрик растет с количеством коммитов, то проект на правильном пути, но и они не абсолютны — мощный рефакторинг может выкинуть кучу кода и кучу тестов вместе с ними.
Здравствуйте, landerhigh, Вы писали:
z>TDD не должно быть религией. Это просто инженерная практика. В некотором смысле, гигиена. L>Внедряться полномочиями оно не может.
Т.е. ответ на мой вопрос — в существующей команде по желанию, скажем, нового менеджера с TDD головного мозга внедрить TDD не получится.
L>В лучшем случае будет пара сотен странных типа тестов, непонятно что тестирующих и непонятно как запускаемых
Именно это и происходит.
L>Нужен разработчик-маньяк, который немного пошатнет устои и поведет остальную команду за собой.
Это очень красивый образ, но несколько неконкретный.
L>Покрывать тестами код новый и/или изменяемый — можно и нужно. Вот именно это и должен показать этот самый маньяк, а спустя какое-то время оно обычно само получится
Иэх. Это опять-таки очень неконкретно. Начиная откуда оно само получится? А если рядом с маньяком работает бригада обезьян, педалящих тонны нетестируемого говнокода? Количество кода, который непротестирован при этом возрастает, также растет tech debt, связаный с тем, что добавить тесты — это надо рефакторить.
L>Как этого добиться? Ну, нужен маньяк. Еще нужна метрика.
Метрика не работает. Код формально покрыт тестами, потому что понаписали тонну моков для всего на свете. по факту реальные сценарии тестируются процентов на 5, хотя код покрыт процентов на 80
>Не работает схема, когда "тимлид сказал — пишем тесты", и все заверте... В принципе не работает.
Это в прниципе понятно и очевидно. Мой вопрос был про реальные ситуации, когда произошел квантовый переход В частности про ту, что так красочно описана в блоге — сколько там напрмиер было людей в команде и какого размера был проект. А то сейчас выяснится, чот людей было 2 (я и Иа-Иа) и один из них был тот самый маньяк.
Здравствуйте, blp, Вы писали:
L>>Внедряться полномочиями оно не может. blp>Т.е. ответ на мой вопрос — в существующей команде по желанию, скажем, нового менеджера с TDD головного мозга внедрить TDD не получится.
Я не видел ни одного подобного внедрения, которое можно было бы назвать успешным.
L>>Нужен разработчик-маньяк, который немного пошатнет устои и поведет остальную команду за собой. blp>Это очень красивый образ, но несколько неконкретный.
Ну так скажем. Укушенный. Который не может ни строчки написать, не написав для нее тест. Который на предложение прогнать прогу под отладчиком начнет брызгать слюной и бросаться на людей.
Большинство разработчиков имхо относятся к лагерю "могу тесты писать, но могу и не писать". Их не стоит принимать на вакантную позицию маньяка.
L>>Покрывать тестами код новый и/или изменяемый — можно и нужно. Вот именно это и должен показать этот самый маньяк, а спустя какое-то время оно обычно само получится blp>Иэх. Это опять-таки очень неконкретно. Начиная откуда оно само получится?
Начиная с появления некоей критической массы тестов.
blp>А если рядом с маньяком работает бригада обезьян, педалящих тонны нетестируемого говнокода? Количество кода, который непротестирован при этом возрастает, также растет tech debt, связаный с тем, что добавить тесты — это надо рефакторить.
Здесь придется сначала разделять задачи и ответственность. Нельзя объять необъятное. Бригаду обезьян перевоспитать с наскока не получится, их надо медленно варить. Маньяка с командой лучше сначала изолировать на небольшом модуле, откуда тесты вскоре начнут расползаться по другим модулям. Однажды бригадир обезьян придет утром и обнаружит, что билд сломан. А сломан он потому, что юнит-тест, который незаметно для них стал частью билд процесса, перестал проходить. А проходить он перестал потому, что бригада обезьян закоммитила breaking change, не протестировав его никак. Они могут сначала попытаться саботировать, выбрасывая тесты из процесса сборки или просто закоммичивая их, но это только до первого устного выговора. Дальше придется учиться есть кактус.
L>>Как этого добиться? Ну, нужен маньяк. Еще нужна метрика. blp>Метрика не работает. Код формально покрыт тестами, потому что понаписали тонну моков для всего на свете. по факту реальные сценарии тестируются процентов на 5, хотя код покрыт процентов на 80
Кстати, одна из причин, по которой я резко негативно отношусь в качестве использования этой метрики как показателя качества кода. Можно иметь 100% покрытие кода, но близкое к нулевому покрытие сценариев. Динамику изменения покрытия (растет/падает) использовать можно, особенно если можно быстро посмотреть, какой код вообще не покрыт. Но как абсолютную метрику — вряд ли.
>>Не работает схема, когда "тимлид сказал — пишем тесты", и все заверте... В принципе не работает. blp>Это в прниципе понятно и очевидно. Мой вопрос был про реальные ситуации, когда произошел квантовый переход В частности про ту, что так красочно описана в блоге — сколько там напрмиер было людей в команде и какого размера был проект. А то сейчас выяснится, чот людей было 2 (я и Иа-Иа) и один из них был тот самый маньяк.
Размер команды не имеет такого большого значения. Конечно, в небольшой локализованной команде до 5-7 (кстати, размер команды из поста) разработчиков внедрять новые подходы намного легче, нежели в распределенной команде о 50 человеках. Нужно начинать снизу, с небольших команд.
Тут нужно еще понимать, какой будет выхлоп. Для одноразового кода вроде веб-фронтенда, который и так наполовину тестируется юзерами и переписывается каждые полгода с нуля согласно веяниям моды выхлопа может и не быть. Какие тут тесты — фигак-фигак и в продакшен.
Для кода, развитие и поддержка которого планируется на десятилетия вперед, выгода от внедрения юнит-тестирования во многих случаях будет состоять в разнице между "загнулись после первой версии" и "число установок растет двенадцатый год подряд". Описанный мной проект относился к этому классу.
В нем все сценарии поведения протестировать вручную было абсолютно, категорически невозможно. С автоматическим симулятором можно было покрыть большой домен сценариев, но он тоже был ограничен в возможностях. А с юнит-тестами мы могли обеспечивать симуляцию таких хитрых сценариев, которые вешним симулятором было просто не прогнать. Это если забыть на минуту о пользе от юнит-тестов во время собственно процесса разработки и о том, что наличие значительного количества юнит-тестов, покрывающих все ключевые сценарии работы юнитов и их взаимодействия обеспечили нам отличный набор для регрессивного тестирования. Что оказалось крайне удобным при работе над следующими версиями. Всем знакомо "добавить эту фичу сложно, так как поломаем все нахрен"? Вот-вот.
Загнать первую версию в продакшен авралом перед дедлайном можно. Растягивать аврал на годы вперед не выйдет.
Здравствуйте, landerhigh, Вы писали:
blp>>Иэх. Это опять-таки очень неконкретно. Начиная откуда оно само получится? L>Начиная с появления некоей критической массы тестов.
это тоже неконкретно.
L>Здесь придется сначала разделять задачи и ответственность. Нельзя объять необъятное. Бригаду обезьян перевоспитать с наскока не получится, их надо медленно варить.
Собственно, мой основной вопрос был как раз про детали этого медленного варения. Судя по ответам, ваш случай относится к маленькой команде в 5-7 человек, которая не распределена географически. Моя ситуация про команду раз в 10 большую, распределенную примерно в 3 таймзонах.
>Маньяка с командой лучше сначала изолировать на небольшом модуле, откуда тесты вскоре начнут расползаться по другим модулям.
Неосуществимо.
> Однажды бригадир обезьян придет утром и обнаружит, что билд сломан. А сломан он потому, что юнит-тест, который незаметно для них стал частью билд процесса, перестал проходить.
У нас билд никогда не сломан, потому что ломающий чендж не дает зачекинить CI — т.е. при наличии тестов все поломается еще раньше. Проблема в том, что код задизайнен и дизайнится так, что тестировать его либо невозможно либо трудно. Просто потому что о тестах думают постафактум
> А проходить он перестал потому, что бригада обезьян закоммитила breaking change, не протестировав его никак.
Такое становится понятным сильно позже, потому что breaking change вылез где-то в integration pipeline или доехал до продакшена.
blp>>Это в прниципе понятно и очевидно. Мой вопрос был про реальные ситуации, когда произошел квантовый переход В частности про ту, что так красочно описана в блоге — сколько там напрмиер было людей в команде и какого размера был проект. А то сейчас выяснится, чот людей было 2 (я и Иа-Иа) и один из них был тот самый маньяк.
L>Размер команды не имеет такого большого значения.
Не согласен.
>Конечно, в небольшой локализованной команде до 5-7 (кстати, размер команды из поста) разработчиков внедрять новые подходы намного легче, нежели в распределенной команде о 50 человеках. Нужно начинать снизу, с небольших команд.
"Снизу" не начинается, потому что команды шарят достаточно большой проект и имеют зависимости друг на друга.
L>Тут нужно еще понимать, какой будет выхлоп.
Да выхлоп как раз понятен — ускорение релизов, уменьшение числа регрессий, снижение он-колла. У нас не коробочный продукт, а сервис с довольно частыми релизами (~раз в неделю) и он-коллом.
Здравствуйте, blp, Вы писали:
L>>Здесь придется сначала разделять задачи и ответственность. Нельзя объять необъятное. Бригаду обезьян перевоспитать с наскока не получится, их надо медленно варить. blp>Собственно, мой основной вопрос был как раз про детали этого медленного варения. Судя по ответам, ваш случай относится к маленькой команде в 5-7 человек, которая не распределена географически. Моя ситуация про команду раз в 10 большую, распределенную примерно в 3 таймзонах.
Ну не бывает команд в 10 раз больших. Бывают 10-20 условно проектов, на которых попеременно работают в общей сложности столько народу.
Впрочем, это неважно — такую толпу разом не объять.
>>Маньяка с командой лучше сначала изолировать на небольшом модуле, откуда тесты вскоре начнут расползаться по другим модулям. blp>Неосуществимо.
Только так, никак иначе не выйдет.
L>>Размер команды не имеет такого большого значения. blp>Не согласен.
>>Конечно, в небольшой локализованной команде до 5-7 (кстати, размер команды из поста) разработчиков внедрять новые подходы намного легче, нежели в распределенной команде о 50 человеках. Нужно начинать снизу, с небольших команд. blp>"Снизу" не начинается, потому что команды шарят достаточно большой проект и имеют зависимости друг на друга.
Ну и что? Написал новый юнит-написал к нему, и только к нему, без попыток замокать всю вселенную, комплект юнит-тестов.
L>>Тут нужно еще понимать, какой будет выхлоп. blp>Да выхлоп как раз понятен — ускорение релизов, уменьшение числа регрессий, снижение он-колла. У нас не коробочный продукт, а сервис с довольно частыми релизами (~раз в неделю) и он-коллом.
У меня сейчас такая же ситуация. Внедряю методом медленной варки. Идет с сильным скрипом, если честно, но необходимо.
Здравствуйте, landerhigh, Вы писали:
L>Ну не бывает команд в 10 раз больших. Бывают 10-20 условно проектов, на которых попеременно работают в общей сложности столько народу.
Так же, как же, я имел удовольствие встретиться с этим молодым человеком на Патриарших прудах. Он едва самого меня не свел с ума, доказывая мне, что меня нету! (с)
>>>Маньяка с командой лучше сначала изолировать на небольшом модуле, откуда тесты вскоре начнут расползаться по другим модулям. blp>>Неосуществимо. L>Только так, никак иначе не выйдет.
Я понял вашу позицию.
L>Ну и что? Написал новый юнит-написал к нему, и только к нему, без попыток замокать всю вселенную, комплект юнит-тестов.
Это не работает на практике в условиях наличия большого количества существующего кода, плохо покрытого тестами.
Бизнес "новые юниты" не интересуют, интересуют новые фичи или COGS reduction для старых, или ускорение релизов/уменьшение регрессий.
L>У меня сейчас такая же ситуация. Внедряю методом медленной варки. Идет с сильным скрипом, если честно, но необходимо.
Сочувствую!
Здравствуйте, blp, Вы писали:
L>>Ну не бывает команд в 10 раз больших. Бывают 10-20 условно проектов, на которых попеременно работают в общей сложности столько народу. blp>
blp>Так же, как же, я имел удовольствие встретиться с этим молодым человеком на Патриарших прудах. Он едва самого меня не свел с ума, доказывая мне, что меня нету! (с)
Какое-то разделение ответственности ведь есть?
blp>>>Неосуществимо. L>>Только так, никак иначе не выйдет. blp>Я понял вашу позицию.
Нет серебряной пули, увы
L>>Ну и что? Написал новый юнит-написал к нему, и только к нему, без попыток замокать всю вселенную, комплект юнит-тестов. blp>Это не работает на практике в условиях наличия большого количества существующего кода, плохо покрытого тестами.
Ну почему же не работает? Пишется новая логика в изоляции с тонким слоем клея для подключения к имеющемуся коду.
blp>Бизнес "новые юниты" не интересуют, интересуют новые фичи или COGS reduction для старых, или ускорение релизов/уменьшение регрессий.
За один день этого не добиться.
Можно выбрать одну рисковую фичу в качестве пилота. Что-то, что не отваживались делать из-за риска регрессии, или что-то, что уже 15 раз возвращается на доработку.
Здравствуйте, landerhigh, Вы писали:
L>Здравствуйте, blp, Вы писали:
L>>>Ну не бывает команд в 10 раз больших. Бывают 10-20 условно проектов, на которых попеременно работают в общей сложности столько народу. blp>>
blp>>Так же, как же, я имел удовольствие встретиться с этим молодым человеком на Патриарших прудах. Он едва самого меня не свел с ума, доказывая мне, что меня нету! (с)
L>Какое-то разделение ответственности ведь есть?
Зависит от того, что вы под этим понимаете. Оно есть независимо от размера команды. Просто команда большая и все люди периодически трогают весь код, независимо от того, какой у них основной фокус.
L>>>Ну и что? Написал новый юнит-написал к нему, и только к нему, без попыток замокать всю вселенную, комплект юнит-тестов. blp>>Это не работает на практике в условиях наличия большого количества существующего кода, плохо покрытого тестами.
L>Ну почему же не работает?
потому что новая логика не пишется в изоляции — ее невозможно писать в изоляции. Новая логика это не "добавить чекбокс вместо комбобокса", это, например "к существущему троттлингу добавить троттлинг по новому рилтайм-критерию", оно разбивается на много подзадач, покрывающих много компонентов, часть котороых пишется бригадой бабуинов.
