Как разработчики программного обеспечения, мы постоянно вынуждены предоставлять новые функции, исправлять ошибки и улучшать общую производительность наших продуктов. В этой быстро меняющейся среде легко отдать предпочтение новым функциям, а не рефакторингу кода, что может показаться трудоемкой и менее важной задачей. Однако в долгосрочной перспективе рефакторинг похож на техническое обслуживание автомобиля: вы можете отложить замену масла и продолжить движение, но откладывание этой работы на потом создает большую долгосрочную проблему, которую труднее решить, и в конечном итоге вы слишком боитесь. водить эту машину куда угодно.
Вопрос в том, когда и как мы расставляем приоритеты в процессе рефакторинга? У нас есть несколько вариантов: во время создания функции, в качестве собственных приоритетных задач или вообще без них. У каждого подхода есть свои плюсы и минусы, в зависимости от размера, сложности и важности необходимого рефакторинга.
Без рефакторинга
Начнем с очевидного: полное отсутствие рефакторинга — серьезный риск. Если ваша команда не отдает приоритет рефакторингу, это может создать ужасную историю для вашей кодовой базы. Ваше программное обеспечение станет громоздким, с ошибками и хрупким, и позже вы пожертвуете скоростью для создания функций и стабильности. В конце концов, никто не захочет трогать ваш код. Это меняет культуру команды и то, как люди подходят к кодовой базе, что приводит к менее эффективному рабочему времени, низкому моральному духу и разочарованию. Становится все труднее и труднее нанимать хороших разработчиков, что ведет к скользкой дорожке технического долга.
Некоторые могут возразить, что если кодовая база является «временной» (например, доказательство концепции), мы можем избежать рефакторинга. Это разумный аргумент, однако значительная часть «выбрасываемого кода» имеет тенденцию жить намного дольше, чем предполагалось. На самом деле, если кодовая база живет достаточно долго, и вы чувствуете потребность в рефакторинге, можно утверждать, что вы преодолели порог, чтобы считать проект временным.
Приоритетные истории
Другой подход, который используют команды, — это создание историй, которым продукт будет отдавать приоритет в бэклоге функций. Откровенно говоря, время проведения рефакторинга обычно не зависит от продукта. Бывают случаи, когда разработчики определяют, что объем рефакторинга слишком велик или требует более крупных командных решений. В этом случае может быть уместно приоритизировать его в бэклоге. Однако эта стратегия расстановки приоритетов никогда не должна становиться механизмом контроля за рефакторингом в здоровой команде. На самом деле, это может быть признаком того, что более мелкие рефакторинги не проводились ранее в работе над функциями.
Эта стратегия контроля, когда рефакторинг должен быть связан с историей, может привести к некоторым нездоровым практикам. Хорошие разработчики не могут удержаться от рефакторинга — приведение в порядок логики по мере продвижения делает нашу работу более эффективной и приятной. Это означает, что если нам потребуется связать рефакторинг с историей, разработчики, скорее всего, будут внедрять рефакторинг в свою работу.
Во время работы над картиной
Рефакторинг кода как части фичи может быть вполне разумной практикой. Однако в некоторых случаях, когда мы устанавливаем отношение «один к одному» между кодом, запросом на включение и «заявкой», мы в конечном итоге выводим PR за пределы понятного объема и задерживаем будущую работу, которая зависит от этой функции.
Лучший способ определить, когда проводить рефакторинг, — удалить как можно больше процессов. Если во время работы над фичей кажется правильным провести рефакторинг как часть этого релиза (или PR), они должны взять на себя смелость включить его. Если рефакторинг выполняется во время работы над новой функцией, но может задержать ее или увеличить объем, его следует выполнять отдельно от выпуска функции (или PR), но не обязательно приоритизировать его отдельно. И если рефакторинг кажется достаточно объемным или требует обсуждения в более широкой команде, его можно превратить в отдельную задачу и расставить приоритеты.
В конце концов, решение о том, когда проводить рефакторинг, сводится к доверию. Доверяйте команде разработчиков, чтобы она делала правильные вещи, и доверяйте общению между разработчиками и командой продукта. Хотя отказ от контроля над этим процессом может показаться заинтересованным сторонам пугающим, это действительно самый эффективный способ создать быстродействующий, надежный и восхитительный продукт в долгосрочной перспективе.
