Когда Вы не должны осуществлять рефакторинг?

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

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

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

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

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

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

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

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

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

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

Если вы придерживаетесь принципа, согласно которому все, что вы делаете, должно приносить пользу для клиента / бизнеса, то вам не следует проводить рефакторинг в следующих случаях:

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

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

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

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

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

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

Если тестов нет, напишите несколько в процессе рефакторинга.

Честно говоря. , в одном случае вам запрещено касаться кода со стороны руководства / клиента / SomeoneImportant, и когда это происходит, я считаю, что проект сломан.

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

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

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

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

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

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

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

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

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

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

Вот мой опыт:

Не проводите рефакторинг:

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

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

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

Обновление (8/10): Еще одна причина не проводить рефакторинг - это когда вы не приближаетесь к существующей базе кода с правильным смирение и уважение . Обладая этими качествами, вы будете склонны к консерватизму и будете проводить только те рефакторинги, которые действительно имеют значение. Если вы подходите к коду слишком высокомерно, вы можете просто внести изменения вместо рефакторинга. Неужели название нового метода действительно яснее, или у старого было имя с очень конкретным значением в вашем домене приложения? Вам действительно нужно было механически переформатировать исходный файл в соответствии с вашим личным стилем, когда существующий стиль соответствовал руководящим принципам проекта? Опять же, парное программирование может помочь.

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

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

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

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

Возможно, их больше, но, надеюсь, вы уловили идею ...

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