Разработка — это здорово. рефакторинг потрясающий. Не делайте это одновременно

TL;DR: не вносите функциональные изменения и рефакторинг одновременно.

Проблемы

  • Трудно пересматривать решения
  • Объединить конфликты

Решения

  1. Никогда не меняйте функциональность при рефакторинге

Контекст

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

Мы эксперты в обучении.

Мы должны отложить наше решение. Работайте над рефакторингом и продолжайте работать с нашим решением.

Образец кода

Неправильный

getFactorial(n) {
  return n * getFactorial(n);
}

// Rename and Change

factorial(n) {
  return n * factorial(n-1);
}

// This is very small example
// Things go works while dealing with huge code

Верно

getFactorial(n) {
  return n * getFactorial(n);
}
// Change
getFactorial(n) {
  return n * getFactorial(n-1);
}
// Run the tests
factorial(n) {
  return n * factorial(n-1);
}
// Rename

Обнаружение

Это запах рефакторинга.

[Х] Руководство

Теги

  • Рефакторинг

Заключение

Мы должны использовать физический токен.

Либо мы находимся на стадии рефакторинга, либо на стадии разработки.

Отказ от ответственности

Code Smells — это всего лишь мое мнение.

Кредиты

Фото Dannie Jing на Unsplash

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

Мартин Фаулер



Эта статья является частью серии CodeSmell.