Вычислить стоимость плохого кода

Я ищу аргументы, чтобы убедить руководство инвестировать усилия в рефакторинг.

Мы регистрируем работу с использованием Jira и связываем каждый svn-коммит с вызовом jira.

Моя идея состоит в том, чтобы сделать следующее:

• вручную определить область кода, которая очень плохо реализована, но часто используется: как от User-POV, так и от Developer-POV (исправления)
• получить svn-коммиты, которые содержат JIRA-проблемы
• фильтровать проблемы по некоторым критериям (тип проблемы, версия, prio. и т. д ...)
• рассчитать время / усилия, потраченные на эти ошибки
• оценить усилия и риски рефакторинга
• представить цифры и попросить усилия, чтобы исправить это.

Что ты думаешь об этом? Будет ли такое измерение полезным и / или убедительным? Каковы плюсы и минусы?

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

ИМХО, чтобы убедительно доказать, вам понадобится следующее, чтобы показать, насколько это плохо:

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

И для обоснования необходимости рефакторинга вам понадобятся:

• оценка времени для рефакторинга и реализации каждой из трех самых плохих вещей
• смета расходов на внедрение (те же почасовые ставки, которые использовались выше)

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

• быть меньше n инцидентов поддержки
• не будет больше таких инцидентов для этих вещей (ДАЖЕ ЛУЧШЕ!)

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

Сколько еще мне придется ждать завершения проекта Y, пока вы проводите время, работая над этими проблемами с X ????? (несмотря на текущие временные ссылки поддержки, которые нельзя предсказать и запланировать в диаграммах Ганта)

Это во многом зависит от того, насколько хорошо вы общаетесь с лицами, принимающими решения, и от того, как они понимают ситуацию.

Я определенно думаю, что это стоит делать, поэтому вы получаете практику построения кейса с помощью метрик и экономите время, даже если они этого не делают. К сожалению, не всех легко убедить, несмотря на данные. УДАЧИ!

Имейте в виду, что рефакторинг также приводит к ошибкам (которые вы поймете при тестировании, но, тем не менее, они являются ошибками и должны быть исправлены). Не тяните Netscape в случае аварии. Это зависит от вашего личного определения «рефакторинг». Для некоторых это означает «переписать весь код», для других это означает «изменить некоторые внутренние компоненты». Как вы говорите, какой вы? Задайте себе следующий вопрос:

Я вообще меняю публичный интерфейс?

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

Это сложный случай, потому что никто никогда не знает, сколько Х стоило бы с рефактором или без, что было сделано год назад. По моему опыту, прагматичные менеджеры всегда сбивают такие вещи, потому что:

1. Прямые доходы не поступают от усилий (финансовые затраты, не оплачиваемые)
2. Уродливый рабочий код все еще работает, вы рискуете создавать проблемы, а не исправлять их (потенциальная цена за качество)
3. Другие проекты будут отложены во время рефакторинга (стоимость времени)

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

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

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

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