Давайте посмотрим, когда вам следует подумать о рефакторинге кодовой базы и как убедить руководство потратить время на рефакторинг и технический долг.

По мере того, как вы продвигаетесь вперед, чтобы создать и выпустить на рынок следующую крупную вещь, вы, вероятно, позволили некоторым вещам скользить, которые, возможно, сейчас догоняют вас. Одним из них является рефакторинг - процесс изменения программной системы таким образом, чтобы он не изменял внешнее поведение кода, но улучшал его внутреннюю структуру.

Давайте посмотрим, когда вам следует подумать о рефакторинге кодовой базы и как убедить руководство потратить время на рефакторинг и технический долг.

Какая у вас культура на рабочем месте, когда дело касается рефакторинга?

Решение о том, когда проводить рефакторинг кода, в первую очередь зависит от корпоративной культуры. В идеальном мире код реорганизуется мало и часто, а это означает, что это задача, интегрированная в повседневные рабочие задачи. Наличие базового уровня регулярного рефакторинга означает, что любой более глубокий рефакторинг кода обычно менее обременительный.

Для сравнения, если это задача, которой не было в списке дел, или ответственность за нее возлагается на кого-то, кто слишком занят или ушел из организации, то продать ее может быть сложно. В таком сценарии сделать рефакторинг кода приоритетом означает либо нанять дополнительный персонал, либо отвести персонал от других задач. Может быть трудно убедить руководство отложить выполнение других задач и сосредоточиться на рефакторинге.

Когда рефакторинг кода должен стать главным приоритетом?

Команда разработчиков замедляется

Это, вероятно, самый простой способ убедить разработчиков и руководство сделать рефакторинг кода приоритетом, поскольку он имеет как технические, так и бизнес-последствия. Вы можете оказаться в ситуации, когда ваша база кода низкого качества означает, что добавление функций и исправление ошибок станет невозможным. Это может быть ситуация с устаревшим кодом, проблемами дизайна или архитектуры или когда код больше не служит своей первоначальной цели.

Как делится Дэн Гослен,

«Был ли в вашей карьере программиста момент, когда вам нужно было внести простое изменение, но было трудно реализовать? Код был настолько хрупким, что вы не могли внести изменения, не проведя множество тестов? Или, может быть, это было время, когда вы не могли понять, что вызвало производственную проблему, глядя на источник. Вы не могли понять, какой код был выполнен или с чего начать. Журналы и показатели тоже не помогли ».

В таких сценариях разработчики оказываются узкими местами и замедляются из-за отсутствия рефакторинга.

Между коммитами прошло много времени

По общему признанию, меньшая проблема для тех, кто использует DevOps с небольшими и частыми коммитами; если с момента коммитов прошло много времени, вероятно, ваш код нуждается в обновлении и рефакторинге, прежде чем вы сможете двигаться дальше.

Вы работаете самостоятельно

Вам нравится избегать банальных чатов с водяным охлаждением, но работа в одиночку означает, что у вас может не быть других разработчиков, регулярно просматривающих код, предлагающих свежие точки зрения, правки и рефакторинга коммитов. Отсутствие обратной связи позволяет легко отложить рефакторинг. Может быть, пора пообщаться с другими разработчиками-одиночками, чтобы поработать вместе для получения общей выгоды?

Вы работаете с большим количеством устаревшего кода

Хорошо, возможно, вы не работаете с COBOL в банке или государственном учреждении, но, возможно, унаследовали устаревшую кодовую базу, которую необходимо обновить и распутать, прежде чем вы сможете добавлять новые функции или исправлять ошибки. Если вы учитесь, как все это работает, сейчас самое время сделать заметки о любом необходимом рефакторинге и одновременно составить план по его ускорению.

Технический долг становится тем, что нельзя игнорировать

Отсутствие рефакторинга кода могло привести к созданию еще более крупной программы, которая теперь стоит вашей организации как времени, так и денег с точки зрения разочарования разработчиков и задержки технической задолженности. Как отмечает Джонни,

«Без должной заботы о создании надлежащих абстракций при написании новых модулей или функций технический долг может быстро расти. В agile-ориентированных командах, которые быстро меняются и работают, последствия накопления технического долга могут произойти с негативными последствиями раньше, чем позже ».

Как лучше всего решать технические проблемы?

Если вы столкнулись с техническим долгом и хотите сделать его видимым, используйте расширения Stepsize VSCode или JetBrains. Это хороший способ начать создавать закладки для кода, создавать задачи и задачи и расставлять приоритеты по рефакторингу и обслуживанию.

Проблемы рефакторинга

Посмотрим правде в глаза, с рефакторингом возникает множество проблем, особенно если есть большое отставание и команда людей менее склонных к этому. Вам нужно не только справиться с этим, но и создать рабочий процесс, в котором он больше никогда не сможет достичь гигантских размеров.

Кроме того, эффективный рефакторинг требует от разработчиков достаточных навыков, чтобы исправить любые проблемы. Никто не хочет рисковать взломом кода, а любые непреднамеренные изменения сложных функций затрудняют управление и модульное тестирование.

Слон в комнате: стоит ли просто переписать вместо рефакторинга?

Идея начать с нуля очень привлекательна для многих, особенно если ваши потребности сильно изменились со старой кодовой базы. Николас Тиц-Сокольский из Remesh представляет собой отличный пример того, где переписывание имеет смысл по многим причинам. Во-первых, компания начинала с малого, с низкой скоростью и множеством ошибок продукта. Он отмечает:

«Проблемы были в основном нашей кодовой базой и нашим процессом. Устаревшая кодовая база, над которой мы работали, плохо подходила как для набора навыков нашей команды, так и для задач, которые мы решали, и наш процесс поощрял и полагался на разрозненные знания: в Remesh не было «полного стека» ».

Другие проблемы у них были:

  • Они разработали свое унаследованное приложение для чего-то очень отличного от его нынешнего соответствия рынку и варианту использования. Таким образом, некоторые старые дизайнерские решения больше не имели смысла, и схема нуждалась в серьезных изменениях.
  • Их кодовая база включала функции, закрепленные болтами. Это означало отказ от рефакторинга и плохую практику тестирования, особенно в старом коде.
  • Разработчики Remesh писали код на языках и фреймворках, которые либо не имели данных, либо были недостаточно хорошо известны разработчикам.

Как отмечает Rotate, переписывание - это масштабное мероприятие, требующее много времени, навыков и ресурсов. Исходный код необходимо поддерживать до тех пор, пока вы не сможете интегрировать новый код в проект. Николас отмечает для тех, кто задается вопросом, стоит ли переписывать вместо рефакторинга:

«Исходя из моего опыта здесь, вы, вероятно, не должны, если вы покупаете шумиху, что переписывание никогда не будет правильным решением. В любом случае вам следует по умолчанию придерживаться позиции «нет», а затем очень и очень усердно работать, чтобы оправдать это, если это необходимо ».

Есть множество веских причин для рефакторинга. Чистый код легче поддерживать, расширять и добавлять новые функции. Он удаляет повторяющийся код и упрощает разработку. Ошибки легче найти. Рефакторинг может привести к более стабильным функциям, большей безопасности в ваших приложениях и более оптимизированному процессу разработки.

Дополнительные ресурсы