В программировании, как и в любом другом деле, есть два подхода— «просто сделать» и «сделать как надо». Разработчики, выбирающие первый путь, считают рефакторинг пустой тратой времени. Мы с таким подходом не согласны, и в этом посте объясним, почему.
Не пишите сразу на чистовик
Разве в школе вы сдавали учителю непроверенный черновик сочинения? Нет, ведь для пятерки требовалось писать работу в три этапа. Сначала набросать вступление и доводы, потом подобрать аргументацию и дополнить ее логичным заключением. А после этого еще поработать над текстом, чтобы он стал лаконичным и простым для восприятия.
Воспринимайте рефакторинг как вычитку и редактирование текста. Убедитесь, что ваш код похож на дипломную работу, а не на sms-ку другу.
Долг с процентами
Долги связывают человеку руки. В нашем случае речь идет о техническом долге, который ничем не лучше взятых взаймы денег. Чем дольше ваш код остается нетронутым, тем крупнее набежит пеня, которую придется заплатить при его пересмотре. А заплатить однажды все равно придется. Об этом знает каждый, кто хоть раз брал код на техподдержку.
Представьте, что нужно дописать новый функционал. Вам придется заплатить программисту за целую неделю работы, а он даже не приступит к ее выполнению, потому что всё это время уйдет на разбор кода. Оригинальная программа может при этом работать идеально, но если документация непонятна или ее вообще нет, то поддержка обойдется на порядок дороже.
Рефакторинг может не принести вам немедленной пользы, но в долгосрочной перспективе он сэкономит вам время и деньги.
Не влезайте в долги, и ваша система не станет кошмаром для техподдержки.
Повторения вызывают мучения
В программировании есть правило «не повторяйся» (DRY).
«Каждая часть знания должна иметь единственное, непротиворечивое и авторитетное представление в рамках системы»,— гласит оно.
Что будет если пренебречь этим правилом?
Вместо одной проблемы вы создадите множество: чтобы внести всего лишь одно изменение придется переписывать несколько дублирующихся фрагментов, и если что-то упустить, то сломается всё.
Разработчик может просто не разобраться со всеми функциями повторяющегося кода. При слиянии это приведет к массе багов и конфликтов просто из-за того, что один дублирующий компонент не обновился.
Любое срочное мелкое изменение потребует знания всех повторяющихся разделов кода.
Устранение повторов в коде создает единый источник достоверных данных. Это позволяет проводить более комплексное тестирование, и программа становится надежнее и защищеннее.
Лапшу вкусно есть, но больно читать
В программировании существует понятие спагетти-кода. Это когда программа написана запутанно, и другому разработчику сложно в ней разобраться. Причины для такого кода могут быть разными— недостаток опыта, спешка и многое другое.
Рефакторинг приучит программистов упрощать операторы даже в процедурных языках. Если язык позволяет абстрагировать управляющие структуры в другие формы, например в классы, то так и нужно делать. В результате в вашем коде будет меньше условных операторов (IF), а про операторы перехода (GOTO) можно будет забыть, как про страшный сон.
В Work Solutions мы инкапсулируем отдельные фрагменты кода, извлекаем классы и интерфейсы и используем полиформизм. Все это для того, чтобы добиться верного поведения программ и при этом сохранить код с понятной структурой, который легче читать.
Мусорить— некрасиво!
Понравится вам, если пока вы будете в отпуске, кто-то оставит у вас на столе кофейные пятна и липкие фантики? Нет.
Код— такое же рабочее место. Сегодня с ним работает один программист, а завтра другой, и никто не хочет разгребать чужой мусор. С рефакторингом рабочее пространство будет чистым.
Если программист использует определенные общепринятые нормы и способы наименований, то его код будет понятен другим. Любой разработчик, знакомый с этими нормами, сразу поймет, что в этом коде происходит. Такой код легче обсуждать, так как у вас будет общий язык для описания процессов.
Учиться никогда не поздно
Разработчик хорошо понимает, как работает программа, которую он создал, и с которой часто взаимодействует. Рефакторинг выведет это понимание на новый уровень. Периодически уделяя время рефакторингу, программист заметит свои вредные привычки, потому что людям свойственно осознавать ошибки и замечать нюансы, которые можно было сделать лучше только спустя некоторый срок.
С течением времени наши знания и навыки пополняются. И рефакторинг можно использовать для внедрения новых методов, которые появились уже после написания кода. Это не так рискованно, как попытки применить новые технологии на незавершенных проектах.
При этом нужно трезво оценивать недостатки кода и прибегать к рефакторингу только когда это оправданно. Рефакторинг ради рефакторинга — занятие весьма бесполезное. Если код легко понять, и сложности с его поддержанием отсутствуют, то рефакторинг не нужен.
Не воспринимайте рефакторинг как работу над ошибками, в которой должны быть заинтересованы только разработчики. Правильнее думать о рефакторинге как о вкладе в будущее, который сделает ваш проект независимым от конкретных специалистов.
Что поддается рефакторингу?
Чаще всего рефакторингу подвергают исходный код программы, чтобы изменить ее структуру но сохранить при этом функционал. Базы данных тоже можно изменять: при повторной настройке как поведенческих, так и семантических функций их общая конструкция улучшится. Пользовательский интерфейс после рефакторинга сохранит семантику и обеспечит системность и единство для всех пользователей.
Итак, давайте еще раз тезисно перечислим, что можно сделать с помощью рефакторинга:
- улучшить структуру
- избавиться от багов
- ускорить производительность
- упростить код для восприятия
- исправить устаревшую базу данных
- объединить похожие фрагменты кода и убрать дублирующиеся
- сделать программу универсальнее
- поделить длинные элементы функций на короткие и удобные
- укрепить целостность классов и функций
Рефакторинг— не волшебная палочка-выручалочка, а ценный инструмент, с которым ваш проект будет под контролем. В результате рефакторинга готовый код становиться лучше, чище, читабельнее. В будущем это позволит использовать его вновь. К такому коду легче добавлять новый функционал и в нем несложно замечать и исправлять баги.
Итерационный проект просто не невозможен без рефакторинга. Рефакторинг проекта должен отражать текущий профессиональный уровень компании и соответствие отраслевым стандартам.
