Почему не стоит бояться рефакторинга

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

Спагетти

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

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

Зачем это делать???

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

Код, толчок, развертывание, рефакторинг, повторение.

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

Вот почему всем нам известен цикл разработки:

  1. Код
  2. Толкать
  3. Развертывать

должен включать новый шаг:

4. Рефакторинг

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

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

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

Что дальше?

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

Следующие шаги для начала рефакторинга вашего кода могут включать:

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

Теперь займитесь рефакторингом своего кода!

Это все на сегодня, дайте мне знать, что вы думаете.