Выпускайте раньше, выпускайте чаще - только не забудьте провести рефакторинг;)

Доставить сейчас

Наша главная цель, как инженеров-программистов, - это делать. Как только наш код работает должным образом, мы фиксируем его, а затем запускаем в конвейере CI / CD.

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

Технический долг сейчас выбирает простое решение вместо того, чтобы использовать лучший подход, который потребовал бы больше времени. Чаще всего многие agile-команды выбирают первое, а не второе.

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

Исправить позже

«Исправить позже» - синоним рефакторинга кода.

Рефакторинг кода - это процесс уточнения и упрощения структуры существующего кода без изменения его поведения.

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

Это имеет огромное значение для крупных проектов.

Код читают чаще, чем пишут

Существует множество сценариев рефакторинга.

Ниже приводится общий список вещей, на которые следует обратить внимание при идентификации кода, который может использовать некоторый рефакторинг:

  • Скопировать и вставить (дублировать) код
  • Неоднозначные имена переменных
  • Неиспользуемые переменные / методы / классы
  • Неоптимальная производительность
  • Код вашего метода длиннее экрана
  • Нарушение DRY, KISS, YAGNI, SOLID и других принципов программной инженерии.

Не стесняйтесь предлагать любые другие сценарии в комментариях.

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

В этом разделе я покажу простой пример кода javascript до и после рефакторинга.

Предварительный рефакторинг

Пост-рефакторинг

Проверка кода

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

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

Заключение

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

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

Выпускайте раньше, выпускайте часто.

Только не забудьте провести рефакторинг;)

Спасибо за чтение - и, пожалуйста, подпишитесь на меня здесь, на Medium, чтобы увидеть больше интересных статей по разработке программного обеспечения!