Как измерить производительность разработки программного обеспечения? [закрыто]
Я думаю, что соглашение, которое обычно соблюдается, таково:
- статический класс в классе верхнего уровня представляет собой вложенный класс
- нестатический класс в верхнем уровне class является внутренним классом, который имеет еще две формы: локальные классы с именами, объявленные внутри блока, такие как метод или тело конструктора anonymous class - неназванные классы, экземпляры которых создаются в выражениях и операторах
Тем не менее, несколько других моментов для запоминания:
- Классы верхнего уровня и статический вложенный класс семантически одинаковы, за исключением того, что в случае статического вложенного класса он может статически ссылаться на частные статические поля / методы его класса Outer [parent] и наоборот.
- Внутренние классы имеют доступ к переменным экземпляра окружающего экземпляра класса Outer [parent]. Однако не все внутренние классы включают экземпляры, например внутренние классы в статических контекстах, например анонимный класс, используемый в статическом блоке инициализации.
- Анонимный класс по умолчанию расширяет родительский класс или реализует родительский интерфейс, и нет дополнительного предложения для расширения любого другого класса или реализации каких-либо дополнительных интерфейсов. Таким образом,
new YourClass(){};означаетclass [Anonymous] extends YourClass {}new YourInterface(){};означаетclass [Anonymous] implements YourInterface {}
Я чувствую, что больший вопрос остается открытым, какой из них использовать и когда? Хорошо, что в основном зависит от того, с каким сценарием вы сталкиваетесь, но чтение ответа, данное @jrudolph, может помочь вам принять какое-то решение.
11 ответов
НЕ измеряйте производительность каждого отдельного программиста, просто используя инструмент сборки. Конечно, вы можете измерить команду в целом, или вы, конечно, можете измерить прогресс каждого программиста, но вы не можете измерить их производительность с помощью такого инструмента. Некоторые модули сложнее других, некоторым программистам поручают другие проекты и т. Д. Это не рекомендуемый способ делать это, и он побудит программистов писать небрежный код, чтобы казалось, что они сделали больше всего.
Вам, вероятно, лучше измерить, насколько хорошо ваша команда соблюдает график. Если член команды (или вся команда) постоянно опаздывает, вам нужно будет поработать с ним, чтобы повысить производительность.
Нет.
Подобные показатели обречены на провал. Разные люди работают над разными частями кода, над разными классами проблем, и абсолютные измерения в лучшем случае вводят в заблуждение.
Чтобы измерить производительность разработчика, нужно иметь отличных менеджеров, которые хорошо выполняют свою работу, имеют хорошие спецификации, которые точно отражают требований, и внимательно отслеживайте прогресс каждого по этим спецификациям.
Трудно делать правильно. Программное решение не работает.
Я бы НЕ рекомендовал использовать информацию об инструментах сборки как способ измерения производительности / прогресса разработчиков программного обеспечения. Некоторые из сбивающих с толку проблем: возможно, одна задача значительно сложнее другой; возможно, одна задача гораздо больше связана с «пространством дизайна», чем «пространством реализации»; возможно (вероятно) более эффективное решение является лучшим решением, но это лучшее решение содержит меньше строк кода, чем ужасно неэффективное, которое предоставляет намного больше строк кода; и т. д.
Основная проблема с показателями производительности Таким образом, люди ОЧЕНЬ хороши в игре с любой системой, которая измеряет их собственную производительность, чтобы максимизировать этот точный показатель производительности - обычно за счет чего-то еще, что является ценным.
Допустим, мы действительно используем сборку Hudson для сбора статистики на выходе программатора. Что вы могли бы искать и каковы были бы непреднамеренные побочные эффекты измерения этого, когда программисты узнают об этом?
- Строки кода (разработчики просто выдумывают горы шаблонного кода и другие ненужные излишние инженерные решения, или просто встроить каждый чертов метод)
- Сбои модульного теста (не пишите никаких модульных тестов, тогда они не сработают)
- Модульный тест покрытие (напишите слабые тесты, которые проверяют код , но на самом деле не проверяйте его должным образом)
- Количество ошибок, обнаруженных в их коде (не выполняйте никакого кодирования, тогда вы не получите ошибок)
- Количество исправленных ошибок (выберите простые / тривиальные ошибки для работы)
- Фактическое время для завершения задачи, основанное на их собственной оценке (оценка выше, чтобы дать больше места)
И это продолжается.
Дело в том, что вы измеряете, люди (не только программисты) очень хорошо умеют оптимизировать именно это.
Итак, как вы должны смотреть на производительность ваших разработчиков? Что ж, это сложно. И это касается менеджеров-людей,
Кстати о KPI у разработчиков программного обеспечения. www.smartKPIs.com может быть для вас хорошим ресурсом. Он содержит удобную для пользователя библиотеку хорошо задокументированных показателей эффективности. На данный момент в нем перечислены более 3300 примеров KPI, сгруппированных по 73 функциональным областям, а также 83 отраслям и подкатегориям.
Примеры KPI для разработчиков программного обеспечения доступны на этой странице www.smartKPIs.com - разработка приложений Они включают, но не ограничиваются:
- Эффективность устранения дефектов
- Избыточность данных
В Помимо примеров показателей эффективности, www.smartKPIs.com также содержит каталог отчетов о производительности, которые иллюстрируют использование КПЭ на практике. Примеры таких отчетов для информационных технологий доступны на сайте: www.smartKPIs.com - KPI на практике - информационные технологии Веб-сайт ежедневно обновляется новым контентом, поэтому время от времени проверяйте его на наличие дополнительного контента.
Обратите внимание, что хотя примеры показателей эффективности полезны для обоснования решений, каждый показатель эффективности необходимо выбирать и настраивать в зависимости от целей и приоритетов каждой организации.
Как правило, прямое использование метрик для измерения производительности считается плохой идеей и одним из простых способов запустить команду в полный рост.
Теперь вы можете использовать такие метрики, как% от проекты завершены вовремя,% оттока по мере того, как код приближается к завершению, и т. д. это широкое поле.
Вот пример:
60% критически важных ошибок были написаны Джо. Это простая и понятная метрика. Огненный Джо, верно?
Но подождите, это еще не все!
Джо - старший разработчик. Он единственный человек, которому доверяют каждый раз писать сверхнадежный код. Он написал около 80% критически важного программного обеспечения, потому что он лучший .
Метрики - плохая оценка разработчиков.
Проверьте, сколько строк кода написано каждой.
Затем запускайте нижние 70% .. НЕТ 90%! ... КАЖДЫЙ ДЕНЬ!
(для тех, кто не уверен, ДА, шучу. Серьезный ответ здесь )
Есть много разных способов сделать это. На эту тему написаны целые книги. Вы можете использовать отчеты из Хадсона, но я думаю, что это приведет к дезинформации и даст грубые результаты. На самом деле вам нужна методология отслеживания задач.
Не сокращайте и не ищите быстрых и простых способов измерения производительности / прогресса разработчиков. На результат работы разработчика влияет множество факторов. Я видел, как много людей пробовали различные показатели ...
Создаваемые строки кода - побуждают разработчиков сбрасывать неэффективный мусор Меры сложности - поощряет чрезмерный анализ и рефакторинг Количество обнаруженных ошибок - побуждает людей искать действительно простые задачи и ненавидеть ваших тестировщиков. ... этот список можно продолжить.
При рассмотрении разработчика вам действительно нужно посмотреть, насколько хороша его работа, и определить «хорошо» в контексте того, что нужно компании, и какие ситуации / позиции компания поставила этому человеку дюйма. Прогресс следует оценивать с равным вниманием и обдумыванием.
Мы получаем 360 отзывов от всех в команде. Если все члены вашей команды думают, что вы дерьмо, то, вероятно, так оно и есть.