Какие методы разработки программного обеспечения обеспечивают максимальную рентабельность инвестиций?

Question

Команда разработчиков программного обеспечения в моей организации (которая разрабатывает API-интерфейсы API-интерфейса) обязана принимать по крайней мере одну лучшую практику за раз. Ниже перечислены в списке:

Модульное тестирование (в реальном смысле), Автоматизированное модульное тестирование, Test Driven Design & Разработка, Статический анализ кода, возможностей непрерывной интеграции и т.д ..

Может кто-то, пожалуйста, укажите мне исследование, в котором показано, какие «лучшие» практики при принятии имеют лучшую рентабельность инвестиций и быстрее улучшают качество программного обеспечения. Есть ли там исследование? Это должно помочь мне (поддержать мое требование) установить приоритетность внедрения этих методов.

Answer 1

Есть некоторые ссылки на ROI в отношении модульных испытаний и TDD. См. Мой ответ на этот связанный вопрос; Is there hard evidence of the ROI of unit testing?.

Answer 2

«исследование, которое показывает, какие„лучшие“практики, когда принимается лучше ROI, а также улучшает качество программного обеспечения быстрее»

Не было бы здорово! Если бы это было так, мы все это сделали бы, и вы просто прочитали бы его в DDJ.

Поскольку нет, вы должны принять мучительное суждение.

Существует нет «сделать X для ROI 8%». Некоторые из методов требуют значительных инвестиций. Другие могут быть запущены бесплатно.

• Единичное тестирование (в его реальном смысле) - бесплатно - ROI начинается немедленно.
• Автоматизированные модульные испытания - не бесплатно - требуется автоматизация.
• Испытательный дизайн & Разработка - бесплатно - ROI начинается немедленно.
• Анализ статического кода - требуются инструменты.
• возможности непрерывной интеграции - недорогой, но не бесплатно

Вы не можете знать ROI. Таким образом, вы можете уделять первоочередное внимание инвестициям. Некоторые вещи легче для людей, чем другие. Вы должны учитывать желание своей команды принять эту технику.

Редактировать. Единичное тестирование бесплатное.

• «время проводит кодирование тест можно был принять закодировать следующую функцию в списке» Правда, тестирование означает, что разработчики делают больше работы, но поддержка делает меньше работы отладку. Я думаю, что это не торговля 1: 1. Еще немного времени, затрачиваемое на проработку (и передачу) формальных модульных тестов, значительно снижает затраты на поддержку.

• «Как насчет устаревшего кода?» Дело в том, что свободный - это вопрос управления стоимостью. Если вы добавляете модульные тесты в устаревший код, стоимость не является бесплатной. Так что не делай этого. Вместо этого добавьте единичные тесты как часть обслуживания, исправления ошибок и новой разработки - тогда это бесплатно.

• «Traning является вопрос» По моему опыту, это вопрос нескольких твердых примеров, спрос и управления для модульных тестов в дополнение к коду. Это не требует больше, чем собрание всех рук, чтобы объяснить, что модульные тесты требуется и вот примеры. Затем он требует, чтобы каждый сообщал о своем статусе как «тесты, написанные/пройденные тесты». Вы не выполнили 60%, вы - 232 из 315 тестов.

• «это только бесплатно в среднем, если оно работает для данного проекта» Всегда верно, хорошая точка.

• «требуется больше времени, времени, свободного времени для бизнеса» Вы можете написать плохой код, который едва работает и требует большой поддержки, или вы можете написать хороший код, который работает и не требует много поддержки. Я думаю, что время, затрачиваемое на прохождение тестов на самом деле, снижает затраты на поддержку, обслуживание и отладку. По моему опыту, ценность модульных тестов для рефакторинга резко сокращает время для внесения архитектурных изменений. Это уменьшает время для добавления функций.

• «Я не думаю, что это ROI немедленно» На самом деле, один модульный тест имеет такой огромный ROI, что его сложно охарактеризовать. Первый тест, который пройдет, станет тем, кто думает, что вы можете действительно доверять. Наличие всего лишь одного заслуживающего доверия кода - это экономия времени, потому что это меньше всего, о чем вы должны много размышлять.

War Story

На этой неделе я должен был закончить массовую загрузку данных; он проверяет и загружает 30 000 файлов строк, которые мы принимаем от клиентов. У нас есть хорошая библиотека, которую мы используем для загрузки некоторых внутренних файлов. Я хотел использовать этот модуль для файлов клиента. Но файлы клиентов достаточно разные, что я мог видеть, что API-интерфейс библиотечного модуля не подходит.

Итак, я переписал API, провёл тесты и проверил изменения. Это было значительное изменение API. Много поломки. Большое количество ссылок на источник, чтобы найти все ссылки и исправить их.

После запуска соответствующих тестов я проверил его. И , затем Я повторил то, что, как я думал, был не тесно связанным тестом. По электронной почте Ой. У него был провал. Это было тестирование чего-то, что не было частью API, который также сломался. Исправлена. Проверено снова (с опозданием на час).

Без базового модульного тестирования это нарушило бы QA, потребовало бы отчета об ошибке, потребовало бы отладки и доработки. Посмотрите на труд: 1 час лица QA, чтобы найти и сообщить об ошибке + 2 часа времени разработчика, чтобы восстановить сценарий QA и найти проблему + 1 час, чтобы определить, что исправить.

С модульным тестированием: 1 час, чтобы понять, что тест не прошел, и исправить код.

Практический результат. Мне потребовалось 3 часа, чтобы написать тест? Нет. Но проект получил три часа назад для моих инвестиций в написании теста.

Answer 3

Вы ищете что-то вроде этого?

• The ROI of Software Process Improvement A New 36 Month Case Study by Capers Jones
• Agile Practices with the Highest Return on Investment

Answer 4

Существует такая вещь, как «локальный оптимум». Вы можете прочитать об этом в книге Голдратта «Цель». В нем говорится, что инновация имеет любую ценность только в том случае, если она улучшает общую пропускную способность. Решение о внедрении новой технологии должно быть связано с критическими путями внутри проектов. Если технология ускоряется уже достаточно быстро, это только создает ненужное отставание готовых модулей. Что не обязательно, улучшает общую скорость разработки проектов.

Answer 5

Вы предполагаете, что список вы представляете собой набор «лучших практики» (хотя я согласен, что это, вероятно, делает, кстати)

Вместо того, чтобы попытаться вишневым выбрать одно изменения процесса, почему не изучать ваши текущие практики?

Спросите себя:

Где вы чувствуете большую боль? Что вы можете изменить, чтобы уменьшить или устранить его?

Повторяйте до обезболивания.

Answer 6

Вы не упомянули обзоры кода в своем списке. Для нашей команды это, вероятно, то, что дало нам наибольшую рентабельность инвестиций (да, инвестиции были крутыми, но возврат был еще больше). Я знаю, что Code Complete (по крайней мере, в оригинальной версии) упомянул статистику относительно эффективности обзоров при поиске теста на дефект VS.

Answer 7

Желаю, чтобы у меня был лучший ответ, чем другие ответы, но я этого не делаю, потому что то, что я думаю, действительно окупается, в настоящее время не является обычным. То есть в дизайне, чтобы свести к минимуму redundancy. Легко сказать, но он имеет опыт.

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

В исходном коде это означает, что если некоторые из ваших «входных данных» изменяются с очень низкой скоростью, вы можете рассмотреть возможность генерации кода, чтобы упростить исходный код и получить дополнительную производительность. Если исходный код проще, его легче просмотреть, а потребность в его тестировании будет уменьшена.

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

Answer 8

Одна практика за один раз не даст лучший ROI. Практика не является независимой.