Как обосновать время рефакторинга кода?

У очень большого проекта более 70к LOC.

Проект определенно нуждается в некотором рефакторинге кода в Core Framework, а также в других частях. В начале проекта не было времени для рефакторинга. Однако со временем и более 40 разработчиков объединились и покинули проект. С моей точки зрения это необходимо.

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

При работе с устаревшим или коричневым полем заманчиво провести «весеннюю уборку» в надежде вернуть все в порядок. Это никоим образом не является оправданным использованием ресурсов. В конце концов, как оправдано прекращение разработки на работающем программном обеспечении (может быть изменен только рабочий код)? Можете ли вы гарантировать, что время, потраченное на Фазу Большого Рефакторинга, окупится позже и не вызовет вырождения проекта?

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

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

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

Если это не сделано маленькими шагами, то это не действительно рефакторинг, а?

Все хорошие ответы здесь - но могу ли я добавить бизнес-измерение к этому. Позвольте мне спросить вас, ПОЧЕМУ / Так-что? (подумайте о своем заостренном волосяном боссе (PHB) :)

PHB: почему?
Вы: Это будет легче исправить
PHB: ну и что?
Вы: Это увеличит пропускную способность - мы получим новые сборки быстрее?
PHB: ну и что?
Вы: Err ... счастливые клиенты?
PHB: WTF?
Вы: я имею в виду увеличение рекомендаций, большее удовлетворение, 
     больше прибыли быстрее из-за низкого оборота
PHB: Ой! Звучит хорошо. Но это только "звучит" хорошо, я могу это увидеть?
Вы: WTF?
PHB: покажи мне деньги! (т.е. цифры, пожалуйста)
Вы: О! Brb ... (пойти и положить некоторые цифры в простую таблицу, чтобы сделать ваш случай)

По сути, вы должны сделать экономическое обоснование - запустите некоторые цифры, чтобы прояснить свой мыслительный процесс, и получите цифры, которые объективно отражают «выгоду». Вы также будете знать, сколько времени это займет, приблизительные затраты и т. Д. Это должно иметь смысл. Если оно того стоит, вы получите зеленый сигнал и, возможно, возглавите инициативу тоже :)

Если вы думаете, как я могу все измерить, попробуйте эту книгу

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

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

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

Сказав это, нет ничего необычного в том, чтобы добавлять задачи в проект, когда происходит непредвиденное. Таким образом, если разработчики исчезнут по какой-либо причине, это будет считаться событием особого характера, и любые действия по исправлению ситуации должны быть предприняты. Это будет рассматриваться как пожар или землетрясение и т. Д.

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

Представьте, что вы находитесь перед длинной и огромной стеной. Вам нужно перейти на другую сторону.

Либо вы реорганизуете стену, чтобы построить дверь, либо обходите ее.

Оцените время для обоих решений, и вы получите обоснование для рефакторинга.

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

Как я читаю в одном из других ответов, съешь этого слона по одному кусочку за раз. Я участвую в аудите крупного международного проекта, в котором члены команды географически рассредоточены. После создания первых двух версий программного обеспечения команда согласилась с тем, что их подходы, стиль кодирования и построения решений противоречивы. Они согласились написать новые части приложения, следуя новым правилам и соглашениям, и когда (и только тогда) им придется изменить часть старого кода, они сначала реорганизуют его для соответствия новому соглашению. Все работает довольно хорошо. Процесс рефакторинга почти на 5-м месяце, часть кода подвергнута рефакторингу, часть - нет. Новые функции появляются вовремя, клиенты довольны, разработчики довольны, команда QA также довольна. Беспроигрышная ситуация :)

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

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