Использование результатов непрерывной сборки как части показателей оценки производительности? [закрыто]

11

Мой начальник планирует использовать метрики из нашей непрерывной сборки (собирает и запускает тесты для каждого коммита) как часть наших обзоров производительности (в нашей метрике «качества»). Это кажется мне ДЕЙСТВИТЕЛЬНО плохой идеей, но я хотел бы знать, изучал ли кто-нибудь это или видел, пытался ли это раньше.

Я думаю, что наши разработчики не будут ставить так много тестов, как в противном случае, из-за боязни провала тестов. Я чувствую, что он превращает ценный инструмент разработчика в клюшку, чтобы побеждать разработчиков.

Очевидный контраргумент состоит в том, что это будет способствовать тому, чтобы люди были более осторожны, прежде чем совершать свои действия, и, следовательно, приводили к повышению качества.

Я с базы здесь? Пожалуйста, оставьте в стороне вопрос о том, должны ли мы делать обзоры производительности вообще или нет - это было дано в другом месте.

continuous-integration Майкл Кон
источник
8
Любая система, в которую можно играть, - ужасный вклад в производительность.
Стив Джексон
У каждого есть возможность не тестировать?
JeffO
1
@Steve, а «системы», которые не могут быть игровыми, дают вам узкое представление об общей картине. Для действительно точного отслеживания производительности потребуется работа на ногах.
maple_shaft
2
Обратите внимание, что некоторые вещи хорошо работают на машинах разработчиков, но не работают на сервере сборки (случайная зависимость от внешнего jar-файла, неправильный способ использования / и \ на блоках Linux и т. Д.). Основная причина для сервера сборки заключается в том, чтобы поймать эти вещи, а не беспокоить кого-либо за то, что он не проверил их сначала. Другими словами, это плохая идея.
1
Последующие действия: после того, как мы начали это делать, я обнаружил, что самая большая проблема не имеет ничего общего с другими инженерами и желанием написать надлежащие тесты, а скорее с тем фактом, что наши существующие тесты были ДЕЙСТВИТЕЛЬНО нестабильными, поэтому каждый коммит имел довольно большой шанс не прорваться не по вине человека, совершающего коммит. Этот фактор ослабил энтузиазм каждого по поводу тестирования гораздо больше, чем какой-либо эффект от анализа производительности.
Майкл Кохн

Ответы:

7

Обзоры производительности хороши, но как насчет полезных показателей, таких как:

  • Процент охвата модульным тестом функций
  • Способность уложиться в сроки
  • Четкая и краткая документация
  • Следуйте надлежащим правилам кодирования
  • Хорошо общается с другими
  • Возможность превращать требования и истории пользователей в задачи

Это все хорошие способы измерения производительности, но проблемы, с которыми, похоже, сталкивается руководство, заключаются в том, что им действительно требуется ... ммм ... ну, вы знаете ... ФАКТИЧЕСКАЯ РАБОТА с их стороны.

К сожалению, у большинства менеджеров такое отношение: «К черту это, я хочу судить своих сотрудников по показателям, которые на самом деле не требуют, чтобы я следил за тем, что они делают».

maple_shaft
источник
1
+1 за предоставление хороших выборов каких метрик являются полезным.
Дэвид Руттка
3

По моему мнению, игровая система здесь вполне вероятна, и ваш босс должен найти способы, чтобы это не стало реальностью. Другой случай, о котором вы не упомянули, - это когда разработчики совершают кучу раз, так что это поток проверок, где количество модификаций относительно мало, как будто есть какая-то часть обзора, где используется количество сборок, это вот где это становится новым инструментом, который можно довольно легко использовать неправильно. Я думаю о регистрации, где что-то переименовывается или меняется пробел, это регистрация и считается, что какой-то формой производительности будет педантичный взгляд.

JB King
источник