Программисту легко быть пассивно-агрессивным с нашим кодом. Мы ждем, пока не перестанем терпеть наш код и от него не станет тошнить, прежде чем рассматривать его. Рефакторинг не обязательно должен выполняться как одно большое усилие, которое делается нечасто. Вместо этого проводите рефакторинг интерактивным и непрерывным образом.
Всегда проводите рефакторинг
Есть много вещей, которые вы можете сделать, чтобы попрактиковаться в непрерывном и итеративном рефакторинге. Вот несколько вещей, которые вы можете попробовать.
- Содержите вещи в порядке: оставьте все в лучшем виде, чем было.
- Что я сделал?!: используйте git fault во благо.
- Рефакторинг через тестирование: используйте тесты, чтобы убедиться, что вы не все сломали.
- Меньше значит меньше!: используйте небольшие изменения, чтобы избежать технического долга.
Держите вещи в порядке
Со временем мы развиваем свои навыки программистов и совершенствуем наши знания о передовых методах. Лучшие практики меняются, как и наша способность кодировать. Когда вы повторно посещаете кодовую базу, чтобы добавить функцию или исправить ошибку, мы должны каждый раз искать, что можно улучшить.
Большинство рефакторингов, которые я проводил на протяжении многих лет, состояли из множества мелочей. Со многими из них можно было бы справиться быстро по отдельности. Всегда было проще проводить повторный рефакторинг моих Proof of Concepts и Prototypes, поскольку они обычно меньше по размеру и с ними легче работать. Моя цель — поделиться радостью, которую я испытываю, когда постоянно нахожусь в состоянии рефакторинга.
Гораздо проще содержать дом в чистоте, чем убирать его раз в год. Если для устранения неприятного запаха кода требуется всего несколько минут, зачем ждать, пока он выйдет из-под контроля? Каждый раз, когда вы редактируете файл, ищите, что можно взять. Затем, когда приходит время для архитектурного рефакторинга, это уже не так сложно.
Я что сделал?!
Обвинение Git – это мощный инструмент, который обычно используется в качестве обличительного оружия. Это намного больше. Это отличный инструмент для выяснения контекста изменений, которые вызвали эти строки кода. Что еще более важно, это может помочь вам узнать, с кем вам нужно поговорить, если вы не понимаете, почему что-то было сделано именно так.
Работая над проблемой, я часто чешу себя и удивляюсь, почему все было сделано определенным образом. Я воспользуюсь Git обвинять, чтобы выяснить, от кого получить более подробную информацию, только чтобы узнать, что это был я… пару лет назад. Я говорю себе, что это хорошо, это признак того, что мне становится лучше! Иногда было бы проще, если бы это был кто-то другой. Таким образом, я могу связаться с ними и совместно работать над тем, чтобы сделать вещи более читабельными и удобными в сопровождении.
Попробуйте использовать Git обвинять, чтобы получить больше информации о коде, о котором у вас есть вопросы. Если вы не знаете, как использовать для этого командную строку, используйте Github. Просто откройте репозиторий/файл на Github, нажмите на номер соответствующей строки, затем на три точки рядом с ним, а затем выберите «Просмотреть вину git» для того, кто и ссылку на коммит.
Рефакторинг через тестирование
Все мы слышали о TDD или разработке через тестирование. Что с ТДР? Рефакторинг через тестирование может помочь нам гарантировать, что мы ничего не сломаем во время рефакторинга. Да, это увеличивает время нашего рефакторинга, но помогает нам итеративно добавлять тесты для улучшения покрытия тестами. Попробуйте это в следующий раз, когда будете вносить изменения в кодовую базу, у вас также больше шансов что-то случайно не сломать.
В начале моего текущего рефакторинга я руководил другим разработчиком через свой мыслительный процесс. Сначала мы не были уверены, что мы можем разделять и властвовать. Мы поняли, что можем что-то делать в тандеме. Один из нас мог писать тесты, а другой заниматься рефакторингом. Как только мы закончим, мы обеспечим, чтобы рефакторинг прошел тесты, работающие заведомо хорошо.
Парное программирование во время рефакторинга может быть довольно сложным. Назначив одного разработчика для написания тестов, а другого для рефакторинга, вы можете помочь обоим быть продуктивными, не наступая друг другу на пятки в процессе. Объедините это с непрерывным и итеративным рефакторингом, и вы постоянно и итеративно увеличиваете покрытие тестами. Ваша группа контроля качества будет вам благодарна.
Меньше меньше!
Меньше значит меньше! Меньше долгосрочных разочарований. Разочарование, вызванное накопившимся техническим долгом. Меньше длинных обзоров кода для этих больших рефакторингов. Меньше времени тратится на объяснения или получение помощи. Меньше нарушений функциональности, так как легче тестировать. Меньше длинных совещаний по планированию крупных релизов.
Обычно я попадаю в ловушку, когда сразу делаю кучу мелких изменений и отдаю их в QA. Звучит контрпродуктивно, выпускать больше релизов (вы заставили меня сказать, что меньше значит больше), но включение большого количества изменений в релиз всегда приводило к более длительным циклам релизов, которые выходили из-под контроля. В конце концов, непрерывные итерационные выпуски, будь то новые функции или небольшие рефакторинги, в целом означают меньше времени.
Как только мы начинаем внедрять передовой опыт или очищать наш код, трудно остановиться. Затем мы сталкиваемся с громоздкими экспертными проверками наших запросов на вытягивание. Чтобы бороться с этим, старайтесь решать одну задачу за раз. Сделайте свои коммиты небольшими и значимыми. Делайте запросы на вытягивание небольшими и осмысленными. Меньше больше, больше или меньше.
Я буду честен и признаю, что не всегда следую этим строгим правилам, но обычно я сожалею, когда не делаю этого. Может быть, именно поэтому я начал писать эту серию статей, чтобы закрепить шаблоны, которые хорошо работали в прошлом, и избежать тех, которые вызывали проблемы.
Если вы хотите узнать больше о моем видении и мыслительном процессе по рефакторингу, прочитайте мой предыдущий пост Запах кода — когда проводить рефакторинг.
