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

Для меня больше всего две самых важных функции:

  • привязки клавиш Emacs, как, с именно это мои пальцы совместимы.

  • Открытый исходный код, для свободы это обеспечивает. Быть связанным с одной платформой является анафемой.

В эти дни я главным образом использую Eclipse для программирования (набор к привязкам клавиш Emacs) и FSF Emacs для чтения почты и некоторого случайного ЛАТЕКСА.

6
задан 16 September 2009 в 15:33
поделиться

9 ответов

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

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

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

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

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

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

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

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

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

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

3
ответ дан 10 December 2019 в 00:41
поделиться

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

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

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

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

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

2
ответ дан 10 December 2019 в 00:41
поделиться

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

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

Для меня соотношения больше похожи:

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

  • остальное: кодирование / отладка / рефакторинг / документация
2
ответ дан 10 December 2019 в 00:41
поделиться

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

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

1
ответ дан 10 December 2019 в 00:41
поделиться

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

1
ответ дан 10 December 2019 в 00:41
поделиться

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

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

0
ответ дан 10 December 2019 в 00:41
поделиться

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

0
ответ дан 10 December 2019 в 00:41
поделиться

Для хорошего, хорошо спроектированного кода 5% или меньше кажется мне подходящим для текущей разработки.

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

0
ответ дан 10 December 2019 в 00:41
поделиться

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

но это маловероятно.

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

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

но это маловероятно.

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

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

1
ответ дан 10 December 2019 в 00:41
поделиться
Другие вопросы по тегам:

Похожие вопросы: