Когда пришло время для рефакторинга кода?

Question

В наличии:
1. У вас никогда не хватает времени на это.
2. «Переключение контекста» ментально дорого (трудно оставить то, что вы делаете в серединеоб этом).
3. Обычно это непростая задача.
4. Всегда существует страх, что вы сломаете что-то, что сейчас работает.

С другой стороны:
1. Использование этого кода подвержено ошибкам.
2. Со временем вы можете понять, что если бы вы реорганизовали код в первый раз, когда увидели его, это сэкономило бы ваше время в долгосрочной перспективе.

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

Спасибо.

Answer 1

Пара наблюдений:

На руках: 1. У тебя никогда не было времени сделать это.

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

1. «Переключение контекста» ментально дорого (трудно оставить то, что вы делаете в середине этого).

См. Предыдущий пункт выше. Рефакторинг является активным компонентом хорошей практики кодирования. Если вы разделяете их, как если бы они были двумя разными задачами, то 1) ваши методы кодирования нуждаются в улучшении / совершенствовании, и 2) вы будете подвергаться серьезному переключению контекста, если ваш код нуждается в серьезном рефакторинге (опять же, качестве кода). )

1. Обычно это непростая задача.

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

1. Высокая цикломатическая сложность ,
2. Нет единой ответственности за класс (или процедуру),
3. Высокая связь и / или плохая низкая когезия (также плохая LCOM метрика ),
4. плохая структура
5. Не соответствует принципам SOLID .
6. Нет соблюдения Закона Деметры , когда это необходимо.
7. Чрезмерное соблюдение Закона Деметры , когда неуместно.
8. Программирование с использованием реализаций, а не интерфейсов.

1. Всегда есть страх, что ты сломаешь то, что сейчас работает.

Тестирование? Проверка? Анализ? Что-нибудь из этого перед тем, как быть проверенным в системе контроля версий (и, конечно, прежде чем быть доставленным пользователям)?

С другой стороны: 1. Использование этого кода подвержено ошибкам.

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

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

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

Так что мой вопрос - Практически - Когда вы решите, что пришло время реорганизовать ваш код?

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

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

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

Надеюсь, это поможет.

Answer 2

Одна из самых распространенных ошибок, которые я вижу, это то, что люди связывают слово «Refactor» с «Big Change».

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

Большие изменения требуют большего планирования.Я стараюсь планировать примерно 1/2 в день каждые две недели в течение нормального цикла разработки, чтобы справиться с большими изменениями рефакторинга.Этого времени достаточно, чтобы существенно улучшить базу кода.Если рефакторинг терпит неудачу 1/2 в день, это не такая большая потеря.И это редко бывает полной потерей, потому что даже неудачный рефакторинг научит вас кое-чему о вашем коде.

Answer 3

1. Всякий раз, когда пахнет , я рефакторинг. Я не могу сделать его идеальным сейчас, но я могу, по крайней мере, сделать маленький шаг к лучшему состоянию. И эти небольшие изменения со временем складываются ...
2. Если я нахожусь в середине чего-то, когда я замечаю запах, и исправление его не тривиально (или я просто перед выпуском), я могу сделать (мысленное или бумажное) примечание, чтобы возвратиться к нему, как только я буду закончил с основной задачей.
3. Практика делает его лучше :-) Но если я не вижу решения проблемы, я отложу его и оставлю на некоторое время вариться, обсуждать с коллегами или даже публиковать на SO; -)
4. Если у меня нет модульных тестов и исправление не тривиально, я начну с тестов. Если тесты тоже не тривиальны, я применяю пункт 2.

Answer 4

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

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

Answer 5

Код рефакторинга, когда он должен быть реорганизован.Некоторые симптомы, которые я ищу:

• дублирующийся код в похожих объектах.
• дублирующийся код в методах одного объекта.
• каждый раз, когда требования меняются дважды или более.
• каждый раз, когда кто-то говорит: «Мы это почистим позже».
• каждый раз, когда я читаю код и качаю головой, размышляя «что это сделал глупец» (даже если речь идет об этом глупце)я)

В целом, меньше дизайна и / или менее четкие требования означают больше возможностей для рефакторинга.

Answer 6

Я начинаю рефакторинг, как только обнаруживаю, что повторяю себя. СУХИЕ принципы

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

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

Answer 7

Мартин Фаулер в своей книге , если одно и то же имя предлагает вам сделать это в третий раз, когда вы попадаете в блок кода, чтобы внести другое изменение. В первый раз в блоке вы заметили, что вам следует провести рефакторинг, но у вас нет времени. Второй раз назад ... то же самое. Третий раз назад-сейчас рефакторинг. Кроме того, я читал разработчикам текущей версии smalltalk (я думаю, squeak.org), что они проходят через пару недель интенсивного кодирования ... затем они отступают и смотрят на то, что можно реорганизовать. Лично я должен сопротивляться импульсу к рефакторингу, когда я кодирую, или я «парализован».

Answer 8

Обычно я выполняю рефакторинг, когда выполняется одно из следующих условий:

• Мне нечего делать, и я жду, когда следующий проект придет ко мне в почтовый ящик
• Дополнения / измененияЯ делаю так, чтобы код не работал, если не будет, или было бы лучше, если бы я рефакторинг
• Я эстетически недоволен тем, как код изложен

Answer 9

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

Тем не менее, я всегда удостоверяюсь, что у меня есть достаточно времени, чтобы все обдумать, прежде чем я начну, чтобы я не попал в эту ситуацию.

Ура! * * 1005