AD
Ну а больший code coverage часто идет только во вред.
Size: a a a
2020 July 17
r
Code coverage без mutation testing - деньги на ветер
SV
Alexander Dudin
Использовать подобные метрики для оценки продуктового кода, это все равно, что продуктивность программиста измерять в строчках кода. Абсолютно бессмысленно. У нас может быть кодовая база со 100% покрытием тестами и отличными метриками, но из-за технического долга продукт невозможно развивать и он не отвечает требованиям бизнеса.
Есть старая еврейская поговорка: музыкант-профессионал может сыграть и на табуретке. Но играя на табуретке не стать профессионалом.
Конечно, идеальная самодисциплинированная команда может не использовать никакие quality gates, и "жить" одной папкой хранения кода (даже без VCS). Но, разумеется, это и неудобно, и значительно повышает вероятность возникновения ошибок.
И, более того, оценивать программиста в количестве строчек кода — можно. Если мы договоримся, что:
1) в оценку включаются только строки кода, прошедшее code review внутри команды (i.e. pull request'ы)
2) присутствует жёсткий контроль кода по качеству, в том числе субъективный peer-to-peer контроль (который всякие идиотские изменения забракует)
то тогда на средней и длинной дистанции можно оценивать производительность программиста по числу изменений в кодовой базе внутри данной peer-to-peer группы
Конечно, идеальная самодисциплинированная команда может не использовать никакие quality gates, и "жить" одной папкой хранения кода (даже без VCS). Но, разумеется, это и неудобно, и значительно повышает вероятность возникновения ошибок.
И, более того, оценивать программиста в количестве строчек кода — можно. Если мы договоримся, что:
1) в оценку включаются только строки кода, прошедшее code review внутри команды (i.e. pull request'ы)
2) присутствует жёсткий контроль кода по качеству, в том числе субъективный peer-to-peer контроль (который всякие идиотские изменения забракует)
то тогда на средней и длинной дистанции можно оценивать производительность программиста по числу изменений в кодовой базе внутри данной peer-to-peer группы
AD
Вроде 2020 год на дворе, НЕЛЬЗЯ оценивать продуктивность программиста по числу строк
AD
И никакие code review тут не помогут
r
Вместо "жесткого контроля" по факту, когда уже потрачено время на разработку, можно внедрять практику design review, когда согласование что и как делать идёт до того, как написана хотя бы одна строка кода
SV
Alexander Dudin
Вроде 2020 год на дворе, НЕЛЬЗЯ оценивать продуктивность программиста по числу строк
могу придумать с десяток сценариев, почему это не будет работать в конкретных условиях. Но могу и сформулировать условия, соблюдая которые можно эту метрику использовать как одну из.
SV
Можно вообще почти что угодно взять. Число story point'ов, закрываемых pull request'ов, число проводимых code review, количество строчек кода, количество исправленных файлов... на средней и длинной дистанции миддл тупо работает быстрее junior'а, а senior — быстрее middl'а, если, конечно, занимаются одним пулом задач.
r
Ещё б сложность задач учитывать
AD
могу придумать с десяток сценариев, почему это не будет работать в конкретных условиях. Но могу и сформулировать условия, соблюдая которые можно эту метрику использовать как одну из.
Нету таких условий в реальной разработке ПО. Поэтому и невозможно сказать кто более продуктивный, тот кто пишет 50, 100 или 1000 строк кода в день.
AD
Можно вообще почти что угодно взять. Число story point'ов, закрываемых pull request'ов, число проводимых code review, количество строчек кода, количество исправленных файлов... на средней и длинной дистанции миддл тупо работает быстрее junior'а, а senior — быстрее middl'а, если, конечно, занимаются одним пулом задач.
Нету одинаковых задач, в этом основная проблема
SV
в рамках одного дня конечно нет. В рамках 3 месяцев все задачи сольются в единый поток. Уникальная задача на неделю — уже рядовая в рамках полугода.
SV
Ещё б сложность задач учитывать
более сложная задача будет в среднем требовать большего количества изменений, будет иметь большую оценку сложности. Если команда ограничивает объём pull request'ов — то будет иметь и большее их число.
AD
в рамках одного дня конечно нет. В рамках 3 месяцев все задачи сольются в единый поток. Уникальная задача на неделю — уже рядовая в рамках полугода.
Ладно убедил, будем измерять продуктивность программистов по числу строк кода, и code review обязательно сделаем жестким. И зарплату программистов конечно привяжем к числу строк кода за месяц. На большой дистанции же все сгладиться :) Думаю разработка продукта у нас попрет как никогда.
2020 July 18
SV
вы забыли сказать три раза scrum и звякнуть колокольчиком 😋
SV
если серьезно, то имея на руках цифры производительности, вовсе не следует по ним делать финансовые выводы и как-то привязывать зарплату или премии к ним. Это совсем другой вопрос.
AD
Да, митинги утром, днем и вечером это обязательно 😁
ВС
Всем привет. А у меня такой вопрос. Сейчас в компании приняты MVP и что называется "х...-х.... и в продакшен". и они выкатываются на 50% (что в целом много, как по мне, но не суть). Суть вопроса в том, на каком уровне реализовать превращение mvp в production версию. Т.е. чтобы у людей не было соблазна ползунок на 100% передвинуть. Ведь уже всё готово и работает. Модель плоская, все команды самодостаточны. И ответственность на команде, но вот как привить понимание, что если катим что-то успешное в прод, то пожалуйста, добавьте тестовое покрытие, доку, метрики и т.п. Чтобы после 10-20 mvp не получить кучу не покрытого автотестами (на всех уровнях) кода. Ну и подчищать за всеми тоже не хотим.
И большая проблема, что в этой плоской системе мы одна из команд, которая должна этот возможный ппц ограничить. Т.е. у нас тут вариант, когда есть обязательства, но нет рычагов давления, прямых. И уповать на сознательность и что обучим и всё будут заиньками тоже не очень хочется.
У кого-нибудь был похожий опыт? Как решали? Что почитать?
И большая проблема, что в этой плоской системе мы одна из команд, которая должна этот возможный ппц ограничить. Т.е. у нас тут вариант, когда есть обязательства, но нет рычагов давления, прямых. И уповать на сознательность и что обучим и всё будут заиньками тоже не очень хочется.
У кого-нибудь был похожий опыт? Как решали? Что почитать?
Со стороны процесса бывает такой подход:
- регулярный разбор аварий на продуктиве, где выясняется причина
- влияние количества аварий на премию команды
Подход рабочий. Требует ресурсов, тех же премий. Требует хотя бы нескольких человек, которые по такому подходу работали и могут его организовывать.
Тогда команды будут заинтересованы в уменьшении количества сбоев.
В этом случае остаётся команда платформы/интеграции которая связывает все команды. Но тестировать за всех ей не надо. Команды потихоньку втянутся.
Тот же Allure Server Enterprise, если его применить во всех командах даст метрики по тестам, их покрытию, скорости прохождения (какой-то но производительности). Или его аналоги (думаю уже самодельные)
- регулярный разбор аварий на продуктиве, где выясняется причина
- влияние количества аварий на премию команды
Подход рабочий. Требует ресурсов, тех же премий. Требует хотя бы нескольких человек, которые по такому подходу работали и могут его организовывать.
Тогда команды будут заинтересованы в уменьшении количества сбоев.
В этом случае остаётся команда платформы/интеграции которая связывает все команды. Но тестировать за всех ей не надо. Команды потихоньку втянутся.
Тот же Allure Server Enterprise, если его применить во всех командах даст метрики по тестам, их покрытию, скорости прохождения (какой-то но производительности). Или его аналоги (думаю уже самодельные)
ВС
По анализу истории кода вот такой доклад понравился
https://youtu.be/bHk8UB3YSE0
Думаю, технологии AI во многом держатся на экспертизе конкретных людей, которые кратно умнее AI. И без конкретного человека (докладчика - Алексей Токарь) это не сработает. Но сам подход интересный - предсказывать ошибки по метрикам кода
https://youtu.be/bHk8UB3YSE0
Думаю, технологии AI во многом держатся на экспертизе конкретных людей, которые кратно умнее AI. И без конкретного человека (докладчика - Алексей Токарь) это не сработает. Но сам подход интересный - предсказывать ошибки по метрикам кода
ВС
В докладе выше есть цепочка, как во многих других докладах по применению AI для анализа:
- долго делать анализ руками
- обрести мудрость
- использовать AI
Первый пункт долгий. И его все проходят.
Пример в части метрик тестирования. Опыт такой был. На стену был "повешен график" автоматизации тестов, и метрики по нему должны были идти вверх: все функциональные тесты и доля автоматизированных.
Для этого сначала были таблицы в Confluence. Потом статусы в Jira. Потом графики в Grafana, на основе статусов в Jira. То есть автоматизация измерения автоматизации пришла не сразу.
Поэтому думаю в конкретной команде лучше всего подойдёт метрика, которая уже собирается, но собирается как-то тяжело. Ее надо увидеть и начать автоматизацию измерения, изучение с неё:
- сбои
- обращения пользователей
- ... что-то что уже есть
А если дело пойдет, то добавить ещё вспомогательных.
- долго делать анализ руками
- обрести мудрость
- использовать AI
Первый пункт долгий. И его все проходят.
Пример в части метрик тестирования. Опыт такой был. На стену был "повешен график" автоматизации тестов, и метрики по нему должны были идти вверх: все функциональные тесты и доля автоматизированных.
Для этого сначала были таблицы в Confluence. Потом статусы в Jira. Потом графики в Grafana, на основе статусов в Jira. То есть автоматизация измерения автоматизации пришла не сразу.
Поэтому думаю в конкретной команде лучше всего подойдёт метрика, которая уже собирается, но собирается как-то тяжело. Ее надо увидеть и начать автоматизацию измерения, изучение с неё:
- сбои
- обращения пользователей
- ... что-то что уже есть
А если дело пойдет, то добавить ещё вспомогательных.