Рефакторинг — это неизбежный процесс
Рефакторинг или реорганизация кода — процесс изменения внутренней структуры программного продукта, не затрагивающий его внешнего поведения и направленный на улучшение сопровождаемости и читаемости кода.
В основе рефакторинга лежит последовательность небольших преобразований программного кода, сохраняющих его поведение. Так как каждое преобразование по объёму незначительно, то программисту легче проследить за его правильностью, а вся последовательность этих изменений может привести к существенной перестройке программы и улучшению её согласованности, чёткости и простоты понимания её кода другими разработчиками.
Обычно рефакторят код под контролем прохождения автоматизированных тестов, без этого достаточно сложно убедиться, что внесённые изменения не являются деструктивными и поведение программы осталось прежним.
Без рефакторинга не обходится ни один действительно сложный и долгоживущий проект
Обойтись без рефакторинга можно лишь в том случае, если разрабатывается что‑то, что будет использовано лишь однажды, а потом просто выброшено. Во всех остальных случаях рефакторинг необходим. Проявляться он, конечно, может по‑разному.
В самом простом случае рефакторинг осуществляется в процессе написания кода. Разработчик реализует функциональность, добивается работоспособности, а затем проводит оптимизацию и рефакторинг написанного кода. К сожалению, сложно написать сложный программный компонент сразу идеально: полное понимание взаимосвязей, логики и вариантов реализации, как правило, приходит в процессе разработки.
Тем не менее, рефакторинга только в процессе разработки отдельных компонентов недостаточно. Если разрабатываемый компонент не изолирован, а взаимодействует с другими, то обычно есть необходимость в рефакторинге программных интерфейсов, через которые это самое взаимодействие реализуется.
В рамках всей программной системы перед рефакторингом стоит ещё задача унификации именования функций и переменных, форматирования и соблюдения стандартов кодирования.
Наиболее частые причины для рефакторинга:
- дублирование кода
- длинные методы
- объёмные классы
- длинные списки параметров
- избыточные временные переменные
- классы данных
- несгруппированные данные
- несоблюдение стандартов кодирования
Рефакторинг очень существенно влияет на сопровождаемость проекта
Любой проект без регулярного рефакторинга за несколько лет (или даже месяцев) становится трудным для понимания, процессы изменений замедляются и становятся дороже, а иногда такие проекты доходят до состояния «проще переписать тут всё с нуля, чем разбираться». Таким образом, затраты на рефакторинг окупаются за счёт того, что изменения вносить становится проще и процесс модернизации обходится значительно дешевле.
Рефакторинг и оптимизация производительности
Стоит разделять эти понятия. Оптимизация кода, нацеленная на обеспечение быстродействия, иногда приводит к снижению понятности кода: часто эффективный код — это код, написанный не так, как понятно человеку, а так, как понятно компьютеру.
Но рефакторинг сам по себе нередко повышает производительность, так как выявляются и удаляются лишние конструкции, от которых результат работы не зависит, но на время выполнения программы могут существенно влиять; иногда меняется и последовательность выполнения программного кода, что тоже может положительно повлиять на производительность.
Тематические статьи
SOLID — это аббревиатура, введённая Майклом Физерсом для пяти основных принципов проектирования в объектно-ориентированном программировании:
- Single responsibility — принцип единственной ответственности
- Open-closed — принцип открытости / закрытости
- Liskov substitution — принцип подстановки Барбары Лисков
- Interface segregation — принцип разделения интерфейса
- Dependency inversion — принцип инверсии зависимостей
Принцип единственной ответственности — один из пяти основных принципов объектно-ориентированного программирования и проектирования, описанных Робертом Мартином. Принцип декларирует, что каждый объект должен иметь одну обязанность, и эта обязанность должна быть полностью инкапсулирована в класс, а все его сервисы должны быть направлены исключительно на обеспечение этой обязанности.
Принцип открытости/закрытости — один из пяти основных принципов объектно-ориентированного программирования и проектирования, описанных Робертом Мартином. Принцип декларирует, что программные сущности (классы, модули, функции и т. п.) должны быть открыты для расширения, но закрыты для изменения. Это означает, что эти сущности могут менять своё поведение без изменения их исходного кода.
Принцип подстановки Барбары Лисков — один из пяти основных принципов объектно-ориентированного программирования и проектирования, описанных Робертом Мартином. Принцип в формулировке Роберта Мартина декларирует, что функции, которые используют базовый тип, должны иметь возможность использовать подтипы базового типа, не зная об этом.
Принцип разделения интерфейса — один из пяти основных принципов объектно-ориентированного программирования и проектирования, описанных Робертом Мартином. В его формулировке принцип декларирует, что клиенты не должны зависеть от методов, которые они не используют. То есть если какой‑то метод интерфейса не используется клиентом, то изменения этого метода не должны требовать изменений в клиентском коде.
Принцип инверсии зависимостей — один из пяти основных принципов объектно-ориентированного программирования и проектирования, описанных Робертом Мартином. Принцип декларирует, что модули верхних уровней не должны зависеть от модулей нижних уровней, а оба типа модулей должны зависеть от абстракций; сами абстракции не должны зависеть от деталей, а вот детали должны зависеть от абстракций.
Любая командная разработка может быть эффективной только в том случае, если участники команды имеют общее видение. Если над проектом работает команда, а не один‑два разработчика, то обязательно должен быть стандарт оформления кода — набор правил и соглашений, которые описывают базовые принципы оформления программного кода, используемого совместно группой разработчиков.
Принцип заключается в том, что возможности, которые не описаны в требованиях к системе, просто не должны реализовываться. YAGNI основан на идее, что большинство «гипотетических» возможностей, которые кажутся полезными на этапе проектирования, никогда не будут востребованы. Реализуя их заранее, разработчики тратят время, усложняют код и повышают риск ошибок.
TDD, test-driven development или разработка через тестирование — это методология разработки ПО, повышающая надёжность и сопровождаемость проектов. При следовании этой методологии тесты пишутся до написания кода. TDD основывается на повторении коротких циклов разработки: сначала пишется тест, покрывающий желаемое изменение, затем пишется программный код, который реализует желаемое поведение системы и позволяет пройти написанный тест, а после этого проводится рефакторинг написанного кода с постоянной проверкой прохождения тестов.
Вёрстка независимыми блоками — это методология, которая была сформулирована разработчиками Яндекса. Впоследствии эта методология была расширена и получила название БЭМ (Блок-Элемент-Модификатор). Собственно БЭМ нужен для упрощения командной разработки, для унификации интерфейсов и для более активного повторного использования программного кода.
MVC — это паттерн проектирования приложений, который разделяет на три отдельных компонента модель данных приложения, пользовательский интерфейс и слой взаимодействия с пользователем. В парадигме MVC контроллер отвечает за взаимодействие пользователя с приложением, модель — за слой хранения данных и бизнес‑логику, а представление — за пользовательский интерфейс / формат выходных данных. Модификация каждого из этих компонентов либо оказывает минимальное воздействие на остальные, либо не оказывает его вовсе. Это облегчает понимание логики работы системы и упрощает внесение изменений в кодовую базу.
KISS — это принцип проектирования и программирования, при котором простота системы декларируется в качестве основной цели или ценности. Большая часть программных систем необоснованно перегружена практически ненужными функциями, что ухудшает удобство их использования конечными пользователями, а также усложняет их поддержку и развитие разработчиками. Следование принципу KISS позволяет разрабатывать решения, которые не обладают этими недостатками: они просты в использовании и в сопровождении.
REST — это стиль построения архитектуры распределённого клиент‑серверного приложения, который упрощает роутинг и построение API.
Используемые технологии
Наши услуги
Давайте обсудим ваш проект
Заполните короткий бриф или свяжитесь с нами удобным вам способом
