Почему мы осуществляем рефакторинг? [закрытый]

Похоже на опечатку в вашем макете. Я попробовал это, и это работает для меня. Также обратите внимание, что bodyPath() был введен только в каратэ 0.8.0

макет:

Scenario: pathMatches('/tokenisationservice/TokenisationWS_1_3') && bodyPath('/Envelope/Body/getToken/GetTokenRequest/enterpriseID') == '1'
  * print request
  * def response = { success: true }

тест:

* url karate.properties['mock.url']
* path '/tokenisationservice/TokenisationWS_1_3'
* request
"""
<soapenv:Envelope>
   <soapenv:Header/>
   <soapenv:Body>
      <tok:getToken>
            <GetTokenRequest>
            <enterpriseID>1</enterpriseID>
            <merchantGroupID>1</merchantGroupID>
            <pan>1234567890123456</pan>
         </GetTokenRequest>
      </tok:getToken>
   </soapenv:Body>
</soapenv:Envelope>
"""
* method post
* status 200
* print response
9
задан Peter Mortensen 31 August 2017 в 20:08
поделиться

27 ответов

Почему мы проводим рефакторинг?

Поскольку фактически нет замены для написания кода. Никакое предварительное планирование или опыт не могут заменить фактическое написание кода. Это то, что всему поколению (так называемому водопаду) пришлось нелегко.

Как только вы начинаете писать код и занимаетесь им, вы рассуждаете о том, как он работает на более низком уровне, чем вы . ] замечать вещи (производительность, удобство использования или правильность), которые ускользнули от более высокого представления о дизайне.

Рефакторинг совершенствуется.

Задайте себе вопрос: почему художники делают несколько мазков кистью в одном и том же месте?

36
ответ дан 4 December 2019 в 05:51
поделиться

Все ваши пункты являются общими дескрипторами того, почему люди делают рефакторинг. Я бы сказал, что причина, по которой люди должны реорганизовать рефактор, лежит в точке № 1. Большой проектный фронт (BDUF) почти всегда несовершенен. Вы узнаете о системе, как вы ее строите. Пытаясь предугадать, что может произойти , вы часто заканчиваете тем, что строите сложные решения для того, чтобы иметь дело с вещами, которые на самом деле никогда не происходят. (YAGNI - Тебе это не понадобится).

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

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

0
ответ дан 4 December 2019 в 05:51
поделиться

Я занимаюсь рефакторингом, потому что:

  1. Часто мой код далеко не оптимален с первого раза.
  2. Задним числом часто бывает 20-20.
  3. Мой код будет легче поддерживать для следующий парень.
  4. У меня есть профессиональная гордость за работу, которую я оставляю позади.
  5. Я считаю, что потраченное время может сэкономить намного больше времени (и денег) в дальнейшем.
0
ответ дан 4 December 2019 в 05:51
поделиться

I refactor because proper refactoring makes maintenance SO much easier. I've had to maintain a TON of bad, awful code and I don't want to hand down any that I've written for someone else to maintain.

Maintenance costs of smelly code will almost always be higher than maintenance costs for sweet smelling code.

0
ответ дан 4 December 2019 в 05:51
поделиться

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

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

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

0
ответ дан 4 December 2019 в 05:51
поделиться

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

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

0
ответ дан 4 December 2019 в 05:51
поделиться

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

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

0
ответ дан 4 December 2019 в 05:51
поделиться

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

0
ответ дан 4 December 2019 в 05:51
поделиться

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

0
ответ дан 4 December 2019 в 05:51
поделиться

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

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

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

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

Не только это, но и новые идеи и методы для того, что вы делаете, могут стать доступными. Зачем придерживаться старого ошибочного кода, который может стать проблематичным, если его можно улучшить?

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

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

Не только это, но и новые идеи и методы для того, что вы делаете, могут стать доступными. Зачем придерживаться старого ошибочного кода, который может стать проблематичным, если его можно улучшить?

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

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

Не только это, но и новые идеи и методы для того, что вы делаете, могут стать доступными. Зачем придерживаться старого ошибочного кода, который может стать проблематичным, если его можно улучшить?

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

0
ответ дан 4 December 2019 в 05:51
поделиться

Чтобы сделать безумные вещи нормальными.

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

0
ответ дан 4 December 2019 в 05:51
поделиться

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

0
ответ дан 4 December 2019 в 05:51
поделиться

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

0
ответ дан 4 December 2019 в 05:51
поделиться

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

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

0
ответ дан 4 December 2019 в 05:51
поделиться

A straightforward answer is, requirements change. No matter how elegant your design is, some requirements later on will not buy it.

1
ответ дан 4 December 2019 в 05:51
поделиться
  1. Плохое понимание требований:

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

  2. Поддержка новых требований.

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

  3. Множество ошибок в существующем коде.

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

1
ответ дан 4 December 2019 в 05:51
поделиться

В то время как многие другие люди уже сказали совершенно веские причины, вот моя:

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

1
ответ дан 4 December 2019 в 05:51
поделиться

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

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

1
ответ дан 4 December 2019 в 05:51
поделиться

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

1
ответ дан 4 December 2019 в 05:51
поделиться

As Martin Fowler says, the only thing surprising about the requirements for software changing is that anyone is surprised by it.

The requirements will change, new features will be requested. This is a good thing. Enhancement efforts succeed most of the time, and when they fail, they fail small, so there is budget to do more. Big up front design projects fail often (one statistics puts the failure rate at 66%), so avoid them. The way to avoid them is to design enough for the first version, and as enhancements are added, refactor to the point where it looks like the system intended to do that in the first place. The lifespan of a project that can do this (there are issues when you publish data formats or APIs - once you go live you can't always be pristine anymore) is indefinite.

In response to the four points, I would say that a process that shuns refactoring demands:

  1. A static world where nothing changes так что предварительный дизайн может ударить неподвижная цель отлично.
  2. в результате уродливые хаки обойти недостатки дизайна, которые не являются рефакторинг.
  3. приведет к опасным дублирование кода как страх перед изменение существующих кодовых наборов в.
  4. Будет тратить ресурсы на разработку проблема и создание большого дизайна артефакты в ожидании требования, которые никогда не заканчиваются строить, вызывая большие суммы кода и сложности, чтобы перетащить проект вниз, не предоставляя каких-либо значение.

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

2
ответ дан 4 December 2019 в 05:51
поделиться

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

  • Неэффективен
  • Багги
  • Трудно расширить
  • Трудно поддерживать

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

6
ответ дан 4 December 2019 в 05:51
поделиться

Потому что задним числом легче, чем предвидением.

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

Другая причина в том, что программное обеспечение не создается, оно растет.

3
ответ дан 4 December 2019 в 05:51
поделиться

Чтобы сохранить поддерживаемую кодовую базу?

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

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

7
ответ дан 4 December 2019 в 05:51
поделиться

Рефакторинг - это способ оплаты технического долга .

14
ответ дан 4 December 2019 в 05:51
поделиться

Я хотел бы кратко остановиться на трех ваших моментах.

1. «Результат недостаточного предварительного проектирования»

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

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

3. «Опасная деятельность, которая напрасно рискует дестабилизировать рабочий код»

Что ж, да, если все сделано неправильно. Прежде чем пытаться внести какие-либо существенные изменения в работающую систему, вы должны принять соответствующие меры, чтобы гарантировать, что вы не причиняете никакого вреда - своего рода «развивающая клятва Гиппократа », почти.

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

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

4. «Пустая трата ресурсов»

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

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

7
ответ дан 4 December 2019 в 05:51
поделиться

Выполнен рефакторинг, чтобы упростить понимание / документирование кода.

  • Чтобы дать методу лучшее название - возможно, предыдущее было непонятным или неправильным.
  • Чтобы сделать переменные более описательными / better names.
  • Разбейте действительно длинный метод на множество более мелких методов, представляющих шаги, связанные с решением проблемы.
  • Переместите классы в новый пакет (пространство имен), чтобы помочь организации.
  • Уменьшите дублирование кода.
0
ответ дан 4 December 2019 в 05:51
поделиться

Есть разница между большим рефакторингом (реструктуризация модулей, иерархий классов, интерфейсов) и «единичным» рефакторингом - внутри методов и классов.

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

С современными инструментами рефакторинга, такими как ReSharper на C #, этот вид единичного рефакторинга чрезвычайно прост, быстр и мал риск.

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

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

Избегайте рефакторинга только ради рефакторинга; это просто рефакторинг!

С современными инструментами рефакторинга, такими как ReSharper на C #, этот вид рефакторинга модулей чрезвычайно прост, быстр и невелик.

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

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

Избегайте рефакторинга только ради рефакторинга; это просто рефакторинг!

С современными инструментами рефакторинга, такими как ReSharper на C #, этот вид рефакторинга модулей чрезвычайно прост, быстр и снижает риск.

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

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

Избегайте рефакторинга только ради рефакторинга; это просто рефакторинг!

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

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

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

Избегайте рефакторинга только ради рефакторинга; это просто рефакторинг!

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

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

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

Избегайте рефакторинга только ради рефакторинга; это просто рефакторинг!

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

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

Избегайте рефакторинга только ради рефакторинга; это просто рефакторинг!

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

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

Избегайте рефакторинга только ради рефакторинга; это просто рефакторинг!

Избегайте рефакторинга только ради рефакторинга; это просто рефакторинг!

Избегайте рефакторинга только ради рефакторинга; это просто рефакторинг!

0
ответ дан 4 December 2019 в 05:51
поделиться
Другие вопросы по тегам:

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