Каково хорошее соотношение времени рефакторинга и времени разработки?

Question

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

Мне кажется, что 20% времени разработчиков, потраченных на рефакторинг, кажется хорошим соотношением, но мне нечего показать.

На мой взгляд, на 100% или время разработки:

• 50% уходит на написание кода, отладку и т. Д. *
• 30% уходит на написание юнит-тестов
• 20% потрачено на рефакторинг кода

Таким образом, около 1 строки кода для 2 написанных в конечном итоге находится в отгруженном продукте. Очевидно, что время проектирования, документирование и т. Д. Включены в эти проценты.

Что такое отраслевой стандарт? Как правило, что ваша команда использует? Спасибо, Оливье

Answer 1

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

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

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

Шаг 1: соберите отряд.

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

Шаг 2: найдите способ выполнить первоначальный архитектурный проект и спланировать конечное состояние.

Теперь о трудной части. Вы просите 20% времени 30 инженеров, что, вероятно, превышает 500 000 долларов в год. Вам понадобится гораздо больше оправданий, чем «накопленный технический долг». Вам нужно будет показать окупаемость инвестиций.

Так что будьте готовы ответить на вопрос, который обязательно задаст ваш начальник: "Почему я должен?" Что вы ожидаете получить от рефакторинга? Сократите ли вы усилия по разработке новых функций на 10%? 100%? Будете ли вы повышать качество кода / уменьшать количество ошибок / уменьшать затраты на поддержку? Будете ли вы ускорить время выхода на рынок? На сколько? Позволит ли это уменьшить количество сотрудников SE или подрядчика? Как много? Или вы сможете добавить больше функций в каждом выпуске? Есть и минусы: сколько функций будет отложено, если вам дадут год, чтобы провести анализ с рефакторингом? На сколько они задержатся?

Шаг 3: сделайте серьезную оценку.

Итак, теперь, когда вы вооружены планом, планом, денежным обоснованием и у вас есть техническая поддержка, вернитесь к своему боссу и представьте свое дело ему или ей. Вам повезет гораздо лучше, чем сказать: «Мы должны потратить 20% нашего времени на рефакторинг, как говорили некоторые ребята в Интернете».

Answer 2

Я сомневаюсь, что есть какие-либо нормы.

К вашему расстройству: большинство команд не пишут юнит-тесты и не проводят рефакторинг (пока что-то не остановит или не остановит разработку). Чаще всего время рефакторинга составляет <1%. </p>

Если вы заинтересованы в хорошей практике, тогда ....

• Рефакторинг может быть постоянной деятельностью в рамках процесса разработки. Вы видите потенциал для улучшения, и вы лично отводите немного времени, чтобы все стало лучше. Здесь время рефакторинга <5%. </p>

• Вы выполняете регулярные проверки кода. Скажем, раз в несколько месяцев. Тогда вы можете посвятить несколько дней исключительно команде, чтобы только пересмотреть свой код и улучшить его. Здесь также <5%. </p>

Answer 3

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

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

Так что для меня отношения больше похожи:

• 50%: модульные тесты

• остальное: кодирование / отладка / рефакторинг / документация

Answer 4

Каков ваш дизайн? Водопад? Agile? Насколько велик ваш проект? Насколько велика ваша команда?

Самая продуктивная из тех, что я делал во время Agile-разработки, имеет тенденцию к 33/33/33 или, может быть, даже к 30/30/40. После того, как вы написали тест, а затем написали код для прохождения теста, вы можете выполнить рефакторинг и отточить код, уверенный, что вы ничего не нарушаете.

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

Это все равно, что спросить, сколько раз вам стоило построить дом, сколько раз вы должны строить дом, сколько раз вы должны соблюдать строительные нормы и правила, и сколько раз вы должны выполнять техническое обслуживание. Очевидно, что строительство дома - это самая важная вещь, и теоретически вы можете спроектировать «идеальный» дом, который не будет нуждаться в ремонте, но это маловероятно.

Скорее всего, вы потратите год или два на строительство дома, а остальная часть дома будет периодически обновляться. Усиление несущих элементов важнее, чем сборка колоды, даже если ваши клиенты просят колоду. Они будут несчастны, но они будут еще более несчастны, если упадет крыша и все, на что им нужно жить - это колода.

Аналогично, вы потратили бы X времени на написание кода, но больше времени на его рефакторинг и оптимизацию в течение жизненного цикла проекта.

Answer 5

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

Answer 6

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

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

Answer 7

Если вам сложно понять ваш код, тогда пришло время провести рефакторинг.

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

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

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

Answer 8

Хороший, хорошо разработанный код, 5% или менее звучат как подходящие мне для дальнейшей разработки.

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

Answer 9

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

Answer 10

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

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