Почему при рефакторинге кода бояться нечего, кроме страха перед совершенством.
Что такое рефакторинг?
Внедрение новых функций очень радует. Но хотя реализация - это чувство, которое всем нравится, у этого процесса есть и более темная сторона. После завершения функции вы внезапно сталкиваетесь с запросами на еще две функции. Подобно Гидре, черты лица умножаются. На первый взгляд, команда чувствует себя за рулем машины Формулы 1, оптимизируя каждый круг и гоня все быстрее и быстрее. К сожалению, под этим весь код и системы начинают портиться, даже если кодовая база не обновляется активно.
Бывают моменты, когда нужно сделать шаг назад из вихря и заняться кодом или самой архитектурой путем рефакторинга. Рефакторинг предполагает улучшение структуры при сохранении ее поведения. Все работает так же, просто это более эффективно и более удобно в обслуживании.
Преимущество рефакторинга
Рефакторинг, как и сон, действует как этап восстановления процесса и дает возможность вырваться из порочного цикла записи / выпуска. То, что выходит из строя, можно устранить и отремонтировать. Со временем этот процесс сделает ваши системы более простыми для понимания, обслуживания, масштабирования / расширения и т. Д.
Давайте рассмотрим простой пример, который придерживается принципа единой ответственности. Допустим, у вас есть лямбда-функция, в которой функция-обработчик выполняет две разные функции: обрабатывает оркестровку события, а также асинхронное выполнение запроса через AWS Athena. Хотя для версии кода MVP это может пройти, лучше разбить это на две функции, каждая с одной целью.
Чтобы расширить этот пример, давайте рассмотрим сценарий, в котором в одной команде с течением времени несколько разработчиков из нескольких приложений обрабатывают свои собственные клиентские подключения Athena. Это означает, что каждый разработчик должен знать, какую конфигурацию шифрования использовать, которая могла быть продиктована его командой безопасности. Если это также жестко запрограммировано в каждом приложении, что произойдет, когда его нужно будет изменить?
Микрорефакторинг против макрорефакторинга
Эти термины действительно существуют? Если вы их погуглите, вы, скорее всего, не найдете много. Есть хороший шанс, что я просто придумываю их. Несмотря на это, здесь необходимо проводить важное различие между попытками рефакторинга. Рассматривайте микрорефакторинг как внесение небольших изменений для улучшения небольших участков кода, таких как улучшения ведения журналов, улучшенная обработка сбоев, модуляризация кода и т. Д. Эти изменения могут выполняться часто и могут быть частью стандартного процесса гибкой разработки.
Теперь рассмотрите макрорефакторинг как создание классов, внесение изменений в классы и даже изменение базовой архитектуры. Очевидно, что это сложнее осуществить, когда у вас есть команда, работающая над различными частями кодовой базы в разных проектах. Несмотря на дополнительную сложность, они жизненно важны для обслуживания ваших сервисов. Представьте себе отладку проблем AWS Athena в пяти различных реализациях с различными стилями обработки конфигураций и ведения журнала.
Как узнать, когда нужно проводить макрорефакторинг? Может возникнуть соблазн сразу перейти к макрорефакторингу, вдохновившись статьями Netflix, Spotify и Airbnb. Хотя их инженеры - талантливые люди, вполне вероятно, что их среда сильно отличается от вашей. Вместо этого усвойте принципы из этих статей и используйте их как вдохновение для создания лучшего программного обеспечения в вашей собственной среде. В конечном итоге вы обнаружите, что микрорефакторы разожгут огонь для ваших макрорефакторов и что они будут более применимы, чем альтернативы.
Способы принять рефакторинг
Ниже приводится ряд советов, которые помогут вам освоить рефакторинг и получить от него максимальную отдачу. Они сгруппированы по трем темам: удовлетворение ваших основных потребностей, получение обратной связи и обобщение полученных знаний. Под синтезом здесь нет ничего необычного. Это просто означает создание более сложной идеи путем объединения отзывов и обучения. Первые две темы помогут вам справиться с вашими микрорефакторами, а третья поможет вам справиться с этими макрорефакторами.
Удовлетворение ваших основных потребностей
- Приступайте к делу: если вы представляете новые функции или новый продукт, стремитесь к статусу MVP. Для всего остального выпускайте постепенно.
- В перфекционизме нет ничего плохого. Пока это не задержит ваш выпуск. Используйте гибкий рабочий процесс, обозначив эту идеальную идею как северную звезду, а затем разбив ее на усилия по размеру спринта.
- Иногда может возникнуть беспорядок, поэтому постарайтесь определить, когда проводить уборку на ходу или в ожидании уборки. Допустим, вы несколько дней сносили часть своего дома. В конце дня имеет смысл подметать полы, но не шваброй Swiffer. С точки зрения инженерии, будут случаи, когда вы захотите провести рефакторинг перед запуском кода. Если код работает так, как задумано, было бы лучше запустить службу при условии проведения надлежащего тестирования и выполнить рефакторинг в качестве быстрого выполнения. Для вдохновения см. Принцип Парето.
Поощрение обратной связи
- Задавать вопросы! Поскольку многие проекты работают одновременно, довольно легко потерять связь с потребителями функции после того, как она была выпущена. Естественно, командный фокус смещается в сторону следующей функции, но вам нужно бороться с тенденцией продолжать кататься на волнах релизов.
- Оставьте время, чтобы вернуться к приложению, функции или процессу. Используйте сеансы парного программирования с другими членами команды, чтобы погрузиться в эти существующие части вашей инженерной экосистемы.
- Внедрите в своей команде совет по межпроектной архитектурной проверке, где члены команды могут представить свое решение другим и получить конструктивную критику. Это помогает архитекторам и инженерам отвлечься от работы и способствует более широкому подходу к решению проблем. Кроме того, важно помнить, что любой член команды может внести свой вклад в улучшения ваших приложений и служб.
Обобщение знаний
- Инкапсулируйте основную идею полученной вами обратной связи; будь то направленное или немедленное применение. Запиши это. В качестве примечания, остерегайтесь незамедлительно применимой обратной связи, поскольку существует ловушка реализации этой обратной связи так быстро, что вы не сможете полностью обработать принципы, лежащие в ее основе.
- Не только просите других высказать свое мнение о том, что вы создали, но также спрашивайте их, как они решили свои проблемы. Запишите их. Цель здесь - вырваться из привычной стихии.
- Позвольте себе приветствовать идеи, выходящие за рамки вашего опыта. Если вы работаете в области инженерии данных, не избегайте статей о разработке программного обеспечения. Например, статьи о том, как команда разработчиков программного обеспечения решила проблемы с кешированием API, могут помочь вам переосмыслить созданное вами приложение для микропакетов. Также запишите их.
- Пересмотрите и просмотрите все, что вы записали. Вы начнете соединять точки между идеями и разрабатывать более всесторонние решения. Кроме того, это будет полезно не только для того, что вы уже решили, но и для того, что вас еще даже не просили решить.
Вывод
У вас может быть идеальное представление о том, каким будет ваш код / услуга. Хотя это видение может быть именно тем, что будет реализовано, более вероятно, что цель будет меняться со временем. Поскольку вы не можете предсказать будущее, позвольте этому вдохновить вас принять цикл построения и обучения. Эти знания помогут направить ваши рефакторинги, что будет дешевле, чем если бы вы построили все, что хотели, и только потом выполнили рефакторинг. Затем найдите макрорефакторы от отражения через микрорефакторы.
Наконец, не бойтесь рефакторинга. Из этих двух приведенных ниже цитат, которые я слышал за свою карьеру, я считаю, что последняя вызывает гораздо больший страх:
«Мы думаем о рефакторинге еще до того, как начнем?»
«Мы не можем прикоснуться к этой услуге. Он работает нормально, и единственный человек, который знает, как это работает, ушел год назад ".
