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

17

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

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

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

Джеки Чан
источник
9
70k LOC - не очень большой проект. Я бы назвал это маленьким
BЈовић
@ BЈовић Правда, я унаследовал отдельные исходные файлы, которые имели несколько кратных 10 КБ LoC
Джеймс
1
Уч. Чтение 10К LOC-файла похоже на чтение большой книги. Как только вы дошли до конца, вы забыли начало. У меня в проекте один класс по 10 тыс. LOC, и каждое изменение - это боль. Не могу представить, как это иметь несколько!
BЈовић

Ответы:

19

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

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

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

simoraman
источник
Уфф, никогда не пробовал слона
Джеки Чан
Я пытаюсь настроить это мышление в моем проекте тоже. Нам нужно сделать несколько больших изменений для предстоящих изменений, но я хочу провести необходимый рефакторинг, пока мы собираемся. Нет смысла пытаться вытянуть «большую фазу рефакторинга без какой-либо разработки»
съеживайтесь
3
Мы сделали правило бойскаута. Работает, пока не осталось мелких укусов. Есть части, которые настолько запутаны, что нет другого пути, кроме как тратить на это время.
atoth
13

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

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

Стив Йоргенсен
источник
8

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

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

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

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

кандидат наук
источник
6

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

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

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

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

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

Без шансов
источник
3
Можно только надеяться, что у вашего проекта есть тесты на неудачу ...
Rig
2
@ Если нет, я бы начал с того, чтобы написать. Для каждой найденной ошибки напишите тест, который фиксирует ее исправление. Вы должны начать где-нибудь. Нет смысла что-либо реорганизовывать, если вы не можете объективно сказать: «Я ничего не сломал».
Джон Лион
6

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

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

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

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

mouviciel
источник
1

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

Анджей Бобак
источник
1

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

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

Euphoric
источник