Когда рефактору

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

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

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

Я понимаю «кодовые запахи», red-green-refactor и другие мысли, но часто я чувствую, что лучшее время для рефакторирования - это не первый раз, когда вы пишете код, но второй или третий раз, когда вы используете кода и понять, что это на самом деле проблема и находится в действительном использовании.

31 голос | спросил Hortitude 19 FebruaryEurope/MoscowbSun, 19 Feb 2012 23:59:37 +0400000000pmSun, 19 Feb 2012 23:59:37 +040012 2012, 23:59:37

9 ответов


22

Рефакторинг, когда стоимость рефакторинга меньше стоимости рефакторинга не .

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

ответил Bryan Oakley 20 FebruaryEurope/MoscowbMon, 20 Feb 2012 05:47:24 +0400000000amMon, 20 Feb 2012 05:47:24 +040012 2012, 05:47:24
11

  1. Является циклическая сложность функции ниже 5?
  2. Вы полностью поняли, что такое циклическая сложность, не следуя этой ссылке?
  3. У вас есть автоматизированный тест или документированный тестовый пример для каждого пути через функцию?
  4. Проходят ли все существующие тестовые примеры?
  5. Можете ли вы объяснить мне эту функцию и все ее крайности менее чем за 1 минуту?
  6. Если нет, около 5 минут?
  7. 10 минут?
  8. Есть ли менее чем 100 строк кода в функции (включая комментарии)?
  9. Вы можете найти двух других разработчиков, которые согласны с этим кодом, без ошибок, просто путем визуального контроля?
  10. Используется ли эта функция только в одном месте?
  11. Соответствует ли функция требованиям производительности (время /память /процессор)?

набранное

Добавьте ответы «нет» выше:

  • 0-1 - Почему вы даже подумали о реорганизации этого? Вероятно, вы просто хотите переименовать переменные, потому что вам не нравится соглашение об именах предыдущего разработчика.
  • 2-5 - Это может потребоваться небольшая настройка, но я бы не задерживал выпуск продукции для чего-то в этом диапазоне.
  • 6-8 - Хорошо, нам, вероятно, нужно это исправить ... Скорее всего, мы будем продолжать пересматривать это и /или мы действительно не знаем, что он делает. Все еще на заборе, но это очень подозрительный
  • 9+ - Это лучший кандидат на рефакторинг. (Примечание: запись тестовых примеров - это форма рефакторинга).

http://mikemainguy.blogspot.com/2013/05/when-to-refactor- code.html
ответил Mainguy 16 Maypm13 2013, 16:30:47
8

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

  

Я понимаю «кодовые запахи», red-green-refactor и другие мысли, но часто я чувствую, что лучшее время для рефакторирования - это не первый раз, когда вы пишете код, но второй или третий раз, когда вы используете кода и понять, что это на самом деле проблема и находится в действительном использовании.

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

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

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

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

ответил S.Robins 20 FebruaryEurope/MoscowbMon, 20 Feb 2012 00:31:30 +0400000000amMon, 20 Feb 2012 00:31:30 +040012 2012, 00:31:30
2

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

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

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

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

ответил Jeff 20 FebruaryEurope/MoscowbMon, 20 Feb 2012 00:07:39 +0400000000amMon, 20 Feb 2012 00:07:39 +040012 2012, 00:07:39
2
  

«Когда рефакторировать?»

Короткий ответ: каждый раз, когда вы сталкиваетесь с кодом, который плохо пахнет или его можно улучшить ( Правило бойскаута )

Практически это происходит:

  • Если вы практикуете TDD, систематически на этапе Refactor цикла TDD, то есть после того, как ваш тест будет зеленым и перед тем, как начать новый тест.
  • В результате обзора кода
  • При использовании старого кода
  • При использовании кода, который кажется неловко разработанным
  • и др.
ответил guillaume31 20 FebruaryEurope/MoscowbMon, 20 Feb 2012 19:42:42 +0400000000pmMon, 20 Feb 2012 19:42:42 +040012 2012, 19:42:42
1

Когда я впервые узнал о рефакторинге, мой наставник сказал мне: «Сделайте это дважды, держите нос, делайте это три раза, рефакторинг». (Спасибо, Джош!) Чтобы быть конкретным, он говорил, что, когда вы собираетесь написать тот же блок кода в третий раз (или даже похожий шаблон кода), настало время для рефакторинга. Я последовал за этим в течение последних 10 лет и нашел, что это достаточно правильное эмпирическое правило.

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

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

ответил Sam Goldberg 20 FebruaryEurope/MoscowbMon, 20 Feb 2012 01:22:37 +0400000000amMon, 20 Feb 2012 01:22:37 +040012 2012, 01:22:37
1

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

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

ответил 0lukasz0 20 FebruaryEurope/MoscowbMon, 20 Feb 2012 02:18:59 +0400000000amMon, 20 Feb 2012 02:18:59 +040012 2012, 02:18:59
1

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

Рефакторинг постоянно, как вы работаете. Используйте Test Driven Development, чтобы у вас было несколько циклов red-green-refactor в течение дня. Рефакторинг - это только те части кода, которые вы затронули.

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

ответил Dogweather 12 FriEurope/Moscow2014-12-12T01:15:47+03:00Europe/Moscow12bEurope/MoscowFri, 12 Dec 2014 01:15:47 +0300 2014, 01:15:47
1

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

По техническим причинам их несколько.

  • Если у вас есть ошибка в коде, это означает, что это место неправильно понято, и очень вероятно, что здесь может быть скрыто больше ошибок, и, несомненно, будут большие проблемы с любой попыткой разработать связанные части кода. Итак, это место должно быть проверено на предмет возможного рефакторинга.
  • Другая причина заключается в том, что вы добавляете или изменяете функцию, а старый код очень неудобен для изменения /добавления, и более поздние изменения /добавления очень возможны. Конечно, вы должны сбалансировать стоимость.
  • Возможно, самая серьезная причина заключается в том, что вы меняете код и не подвергаете сомнению.
ответил Gangnus 20 FebruaryEurope/MoscowbMon, 20 Feb 2012 01:44:15 +0400000000amMon, 20 Feb 2012 01:44:15 +040012 2012, 01:44:15

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

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132