Да, то, что вы хотели сделать некоторое время назад
Сегодня я буду делать то, что другие не делают, чтобы завтра я мог делать то, что другие не могут (Джерри Райс)
Независимо от того, пытается ли он рефакторить свой собственный код или код других людей, разработчик программного обеспечения в какой-то момент столкнется с рефакторингом кода.
Но зачем нам вообще рефакторить наш код и как мы это делаем?
Что такое рефакторинг кода?
Процесс реструктуризации существующего компьютерного кода — изменение факторинга — без изменения его внешнего поведения. Рефакторинг предназначен для улучшения дизайна, структуры и/или реализации программного обеспечения (его нефункциональных атрибутов) при сохранении его функциональности. — Википедия
Короче говоря, измените код, не нарушая текущие функции.
Общие цели рефакторинга
- Чтобы наш код можно было поддерживать в будущем
- Для повышения читабельности кода
- Чтобы уменьшить сложность
- Чтобы улучшить производительность кода
- Чтобы упростить реализацию будущих функций
Когда не проводить рефакторинг
- Добавление комментариев/документов может облегчить понимание кода.
- Код не находится под активными изменениями.
- Код соответствует текущему стандарту кода
- Когда существуют правильные спецификации, переписывание может иметь больше смысла.
- Текущий код имеет функциональные ошибки
- Когда добавляется новая функция
Это не исчерпывающий список. У каждой команды будут разные ситуации. Другие ограничения, такие как деньги и время, также будут частью разговора о том, проводить рефакторинг или нет.
Иметь план
После того, как вы и ваша команда решили провести рефакторинг. Важно иметь свободный план информирования вашей команды.
- Встретьтесь с несколькими разработчиками, которые работали над кодом, который вы будете рефакторить.
- Придумайте пошаговый план вместе с командой
- Сообщите другим частям команды о плане
Причина, по которой вы хотели бы сделать это шаг за шагом, заключается в том, что вам будет легче просматривать код. А другие разработчики смогут быстрее выполнять вашу работу.
Если вы подходите к рефакторингу как к созданию секретного стартапа в гараже, вы столкнетесь с большим сопротивлением при попытке объединить код. Не только вашему коллеге может понадобиться переписать часть своей работы, но также будет сложнее протестировать и найти, что пошло не так.
Иметь тест на месте
Если у вас нет теста для частей, которые вы собираетесь рефакторить, вам следует сначала написать тест.
Это сэкономит ваше время, когда вы захотите убедиться, что рефакторинг ничего не сломает.
Вот 13 советов по модульным тестам:
Вот некоторые из моих любимых советов, более актуальных для рефакторинга:
- Тестируйте одну вещь за раз в изоляции
- Следуйте правилу ААА: организуйте, действуйте, утверждайте
- Напишите тесты, которые выявят ошибку, а затем исправьте ее
- Четко называйте свои тесты и не бойтесь длинных имен
- Сделайте каждый тест независимым
- Часто запускайте тест
Попытайтесь понять, чего достигает код
Документация должна быть, но не всегда. Когда его не существует и у вас нет контакта с человеком, написавшим код, вам остается читать код и понимать, что происходит.
Несколько советов для понимания того, что делает код:
- Запустите код
- Запустить отладчик с кодом
- Найдите точку входа
- Визуализируйте соединения
- Поговорите с пользователями
- Поговорите с кем-нибудь, кто работал над кодом раньше
Распознать шаблон
Пытаясь придерживаться СУХОГО принципа «Не повторяйся», обычно легче сказать, чем сделать. Когда кодовая база прошла через руки нескольких разработчиков без надлежащего стандарта кода и стилистического выбора, в какой-то момент произойдет повторение.
Хитрость заключается в том, как обнаружить повторяющийся код и как переписать его насухо?
Вернуться к источнику
Внешний интерфейс:
- посмотрите на пользовательский интерфейс, чтобы увидеть, что похоже
- используйте «Проверить элемент» в консоли, чтобы найти некоторую информацию, которую вы могли бы использовать для поиска этого кода.
- Если на самом деле это два (или более) разных фрагмента кода, превратите их в повторно используемый компонент.
- По возможности отделяйте презентационный компонент от функционального.
Серверная часть:
- Сосредоточьтесь на одной конечной точке за раз
- Найдите ключевые слова конечной точки, чтобы найти код входа, например. "/пользователь"
- Если поиск по ключевому слову не работает, ищите точку входа серверной службы. Затем поймите, как конечная точка настраивается.
- Найти другую службу/функцию, от которой зависит конечная точка
- Подумайте, как уменьшить количество шагов, чтобы добраться до текущего ответа (вывод конечной точки)
Использование глобального поиска по ключевым словам
Если вам повезет, в разных местах могут использоваться одинаковые ключевые слова. И если вы понимаете, что код делает то же самое, то будет неплохо заменить его повторно используемыми функциями.
Визуализируйте, когда это возможно
Нарисуйте структуру кода, чтобы увидеть, как все связано. Целью этого является обсуждение с вашим товарищем по команде, чтобы убедиться, что вы правильно поняли. Кроме того, наличие диаграммы поможет вам определить, какой дизайн не является идеальным.
Некоторые инструменты диаграммы:
- Бесплатно: draw.io
- Не так уж бесплатно: Lucidchart
Всегда помните, что диаграмма должна помочь вам и вашей команде. Если вы обнаружите, что тратите слишком много времени на диаграмму, вы, вероятно, добавляете слишком много деталей или делаете диаграмму красивой.
Думайте о вводе и выводе
Это соответствует принципам единой ответственности и разделения ответственности.
Глядя на функцию, если вы знаете, какова ее цель, будет намного проще уменьшить ввод или вывод.
Уменьшить переменные
Измерение прогресса программирования по строкам кода похоже на измерение прогресса в самолетостроении по весу. - Билл Гейтс
Хотя меньшее количество строк кода не всегда означает лучший код, меньшее количество кода означает меньшую когнитивную нагрузку на разработчика.
Меньшая когнитивная нагрузка означает, что разработчик может быстрее понять кодовую базу и найти ошибки, если они есть.
Другой подход к переменной дедукции:
- Упорядочить → Понять → Переименовать → Удалить избыточность
- Понять → Переименовать → Упорядочить → Удалить избыточность
Независимо от того, какой подход вы выберете, убедитесь, что у вас есть четкое имя переменной, и напишите несколько комментариев, пытаясь понять код.
Уменьшить вложенные условия
Подобно переменным с плохими именами, вложенные условия также могут увеличить когнитивную нагрузку на разработчика.
Выйти раньше
Подумайте, как вы можете переписать условие, при котором вы можете выйти из функции как можно раньше. Таким образом, вы потенциально можете избежать множества else условий.
Избегайте вложенных троичных
Раньше я также писал вложенные тернарии, потому что обычно это требует меньше кода. Но после того, как он стал получателем нескольких сумасшедших вложенных тернарий, он определенно может медленно сводить кого-то с ума.
Комментарии, комментарии и комментарии
Всегда кодируйте так, как будто парень, который в конечном итоге будет поддерживать ваш код, будет жестоким психопатом, который знает, где вы живете. — Джон Вудс
Даже если человек, который берет на себя ваш код, не является психопатом, вы все равно можете написать комментарий, чтобы помочь этому человеку не стать психопатом.
Комментарии — это как глоток свежего воздуха после того, как человек утонул в море хлама и грязи.
Даже если вас не волнует следующий человек, подумайте о себе в будущем. Можете ли вы гарантировать, что всегда будете помнить то, что написали?
Согласованность и форматирование
Шаблоны имен, шаблоны проектирования и форматирование кода должны быть согласованы. Хотя бы от себя придерживайтесь одного стиля.
Для команды вам понадобится некоторая документация и общение. В то же время вы можете воспользоваться pre-hook и eslint для принудительного форматирования кода.
Сосредоточьтесь на одной цели для одного коммита
Перфекционизм потенциально может удержать вас от рефакторинга. В частности, основной целью рефакторинга является улучшение структуры кода.
Заманчиво иметь один рефакторинг, решающий все мировые проблемы, но этот рефакторинг может никогда не закончиться.
Помимо плана разбить его на шаги, каждый из коммитов может быть посвящен одной цели.
Например,
git commit -m 'renamed variables'
Или, чтобы быть более конкретным
git commit -m 'renamed variables in profile page'
В зависимости от того, насколько велика область вашего рефакторинга, вы можете разбить его по функциям, компонентам, службам, конечным точкам и т. д.
Очевидно, это основано на моем собственном опыте работы с кодом в течение многих лет. Я признаю, что есть больше людей, которые более опытны в качестве разработчиков программного обеспечения.
Want to Connect? Let’s connect on LinkedIn.
