В качестве примера возьмем кафе
Давайте представим, что мы открыли свое кафе, обустроили там отличную кухню и взяли на работу опытного шеф-повара. Вначале мы включили в меню только простейшие блюда, чтобы их можно было разогревать в микроволновой печи. Рядом с микроволновкой поставили стеллаж для необходимой утвари.
Через пару месяцев, когда дела пошли вверх, мы добавили в меню мучные изделия. Приобрели духовой шкаф, рядом установили стойку для подносов. Свободного места на кухне стало меньше, повару приходится обходить стойку и постоянно переступать через провода, но в целом работе это не мешает.
Еще через какое-то время поставили фритюрницу с миксером для замешивания теста. Проводов стало больше. Рядом появился очередной шкаф. В штат добавили второго повара. В результате на кухне образовался хаос: нагромождение мебели и техники, передвигаться и готовить блюда стало очень неудобно. Если мы решим установить новую плиту, ситуация значительно ухудшится, ведь места катастрофически не хватает, хотя, казалось бы, площадь позволяет все разместить.
Тогда появляется кухонный проектировщик, который создает дизайн заново и расставляет все столы, шкафы и девайсы по местам. Теперь на кухне воцаряется совершенно другая обстановка: оборудование не мешает работе поваров, провода аккуратно спрятаны по коробам, а стойки не перекрывают проход.
При этом для посетителей ничего не изменилось: мы оптимизировали только кухню – в меню все осталось по-прежнему. Это и называется рефакторингом – когда изменения вносятся исключительно во внутреннюю часть, и, хоть снаружи этого не видно, дальнейшая работа сильно облегчается.
В разработке под рефакторингом кода подразумевают такое его изменение, которое не затрагивает функциональность, но делает лучше читаемость и облегчает дальнейшую поддержку.
Когда нужен рефакторинг в программировании
Существует два вида рефакторинга: плановый и при необходимости.
Рефакторинг, который изначально закладывается программистами в цикл разработки, называется плановым. Например, его могут планировать на каждые 6 месяцев или каждые 4 сплита.
В крупных компаниях, где обычно много legacy-кода, вообще формируются отдельные команды, занимающиеся исключительно рефакторингом старья. Благодаря этому остальные команды легче и быстрее понимают, что происходит в этом коде и как его использовать.
Второй вариант – рефакторинг при необходимости. К нему прибегают, когда возникают сложности с добавлением новых возможностей к старому коду. Тогда мы приостанавливаем процесс и выделяем какое-то время на переустройство того, что было.
Важные моменты при рефакторинге
Как понять, был ли рефакторинг успешным? Да, если в результате код стал более чистым, простым и понятным.
К примеру, если переменная А отвечает за число покупателей, то желательно назвать ее customerCount – это облегчит понимание кода.
Если фрагмен используется несколько раз, его стоит оформить, как отдельную функцию/метод. Так будет проще в дальнейшем вносить изменения – обновить одно место, а не искать одинаковые фрагменты по всем строкам.
Для лучшей читаемости кода большие функции, которые не помещаются целиком на экране, разбивают на несколько менее объемных. Иногда часть функций вообще переносят в отдельный файл, а затем присоединяют его к коду.
Нужно понимать, что рефакторинг – это не синоним оптимизации. Его цель – сделать код понятнее, а оптимизация нужна для ускорения и улучшения эффективности программы.
Можно ли обойтись без рефакторинга?
Конечно, рефакторинг не обязателен. Но чем дольше вы будете его избегать, тем тяжелее будет работать. Это как с уборкой рабочего места: чем дольше не наводишь на нем порядок, тем неудобнее становится работать. Регулярный рефакторинг уберегает от замедлений в дальнейшей разработке и тем самым облегчает жизнь больших команд. Без него могут обойтись разве что маленькие и медленно развивающиеся продукты.
