Какие практики разработки программного обеспечения обеспечивают максимальную рентабельность инвестиций? - PullRequest
3 голосов
/ 27 ноября 2008

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

Модульное тестирование (в его реальном смысле), Автоматизированное модульное тестирование, Тест-дизайн и разработка, Статический анализ кода, Возможности непрерывной интеграции и т.д ..

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

Ответы [ 8 ]

7 голосов
/ 27 ноября 2008

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

Разве это не было бы здорово! Если бы была такая вещь, мы бы все это делали, и вы бы просто прочитали это в DDJ.

Так как нет, вы должны принять болезненное решение.

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

  • Модульное тестирование (в его реальном смысле) - бесплатно - ROI начинается немедленно.
  • Автоматизированное модульное тестирование - не бесплатное - требует автоматизации.
  • Test Driven Design & Development - Бесплатно - ROI начинается немедленно.
  • Статический анализ кода - требуются инструменты.
  • Возможности непрерывной интеграции - недорого, но не бесплатно

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

Edit. Модульное тестирование бесплатное.

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

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

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

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

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

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

История войны

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

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

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

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

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

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

1 голос
/ 27 ноября 2008

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

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

Задайте себе вопрос:

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

Повторяйте до тех пор, пока не пройдет боль.

0 голосов
/ 12 ноября 2009

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

0 голосов
/ 27 ноября 2008

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

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

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

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

0 голосов
/ 27 ноября 2008

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

0 голосов
/ 27 ноября 2008

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

0 голосов
/ 27 ноября 2008

Существует несколько ссылок на ROI в отношении модульного тестирования и TDD. Смотрите мой ответ на этот связанный вопрос; Есть ли убедительные доказательства ROI модульного тестирования? .

...