Знаете это чувство, когда вы долго собираете что-то, потихоньку дополняете и перерабатываете, а в итоге это “что-то” превращается в кашу? А если в работе задействованы ещё несколько человек, каждый со своим видением и пониманием? Например, вы пишете книгу на протяжении десятилетий. За это время поменяется ваше мировоззрение, вы смените множество помощников. Когда книга будет готова, вам обязательно придётся полностью её перечитать и аккуратно убрать все смысловые неувязки, логические ошибки и поправить грамматику.
Рефакторинг — та же самая переработка. Только не книги, а программного кода. Давайте узнаем, когда он нужен, а когда нет.
Что такое рефакторинг?
Это изменение структуры кода. Его делают, чтобы было проще понять внутреннее устройство программы и принципа её работы. Также рефакторинг помогает с исправлением проблем. Тем не менее, в функции рефакторинга не входит изменение внешнего поведения программы, устранение ошибок или переработка функциональности — это оптимизация, и о ней мы поговорим как-нибудь в другой раз.
Для чего нужен рефакторинг?
- чтобы сделать код более понятным.
Разбираться в горах старого кода сложно даже “старичкам”, а что говорить о новичках! Рефакторинг помогает недавно пришедшим на проект программистам быстрее освоиться. Ведь если вы платите за время программиста, то в ваших интересах, чтобы он работал быстрее.
- для ускорения разработки, чтобы код был проще и работал быстрее.
Для расширения функциональности программы лучше не “лепить” дополнительный код поверх старого, а сначала провести рефакторинг. Задача тут та же, как и у сверления зуба, когда вам на кариес накладывают пломбу — подчистить старое, чтобы новое встало лучше.
- для улучшения стабильности работы программы.
Чем лаконичнее вы изъясняетесь, тем проще и понятнее вас слушать. Как людям удобно общаться с теми, кто говорит чётко, кратко и по делу, так и IT программы, имеющие наиболее лаконичный код, работают лучше.
Когда нужен рефакторинг?
Сигналы для заказчика, что стоит принять предложение прорефакторить от программиста:
- если проект идет уже долго, и требования часто менялись
- программа начинает хуже работать: медленно, часто глючит
- ошибки при оценке сроков и увеличение затрат времени на реализацию новой функциональности
- если программисты менялись
- вы еще долго собираетесь пользоваться этим проектом, поддерживать его, дорабатывать: время потраченное на рефакторинг сейчас окупится тем, что дальнейшая разработка будет идти быстрее, будет меньше багов — “потрать 50 часов сейчас, чтобы сэкономить сотни в будущем”
Сигналы для заказчика, что предлагают рефакторинг ради рефакторинга, и выгоды он не принесет:
- нет серьезных или частых проблем в работе программы
- если проект идет не долго и требования не менялись
- если вы не собираетесь еще долго периодически дорабатывать проект
Вот на какие признаки ориентируются программисты, предлагая рефакторинг. Слышите что-то из этого — дополнительная уверенность, что предлагают не просто так:
- Громоздкие классы (каждый класс должен выполнять одну свою функцию);
- Длинные методы, лапшевидные контроллеры;
- Большое количество параметров в методе;
- Неиспользование функций фреймворка;
- Плохой нейминг переменных,функций;
- Много дублирующегося кода;
- Отсутствие документации.
Но лучше всего, конечно, найти программистов, которым доверяешь :)
Когда рефакторинг не нужен?
- Когда код настолько плох, что поддержка и внедрение нового функционала займут слишком много времени
- Когда программа написана на слишком устаревших технологиях, которые уже не поддерживаются. Пример: Flash уже не поддерживается браузерами, рефактори-не рефактори — работать не будет.
Что делать в таких ситуациях? Вот, что:
И начинайте писать с нуля :)
Можно ли обойтись без рефакторинга?
Задаваясь таким вопросом, сначала спросите себя: “а можно сразу писать без ошибок?”. Ответ отрицательный, ибо люди не машины, и всегда найдутся факторы, снижающие качество кода. Рефакторинг, однако, при правильном использовании поддерживает код проекта в хорошем состоянии. Он также минимизирует траты времени на добавление функциональности и привлечение новых разработчиков. Это в свою очередь откроет двери для привлечения клиентов и маркетинга — куда более полезное занятие по сравнению с бесконечным пополнением команды из-за сорванных сроков разработки :)
Комментарии