Часто ли приходилось перерабатывать

Часто ли приходилось перерабатывать

Да, перерабатывание кода (refactoring) — это неотъемлемая часть профессиональной разработки. Я сталкивался с этим регулярно и вижу в этом положительный аспект развития проекта. Расскажу о моем опыте и подходе к refactoring'у.

Частота и типы refactoring'а

Ежедневный refactoring (micro-refactoring)

// Улучшение при code review
// Было
function getUser(id) {
  let user = null;
  fetch(`/api/users/${id}`)
    .then(res => res.json())
    .then(data => {
      user = data;
    });
  return user;
}

// Стало
async function getUser(id) {
  const res = await fetch(`/api/users/${id}`);
  return res.json();
}

К ежедневному refactoring'у относятся:

• Переименование переменных для ясности
• Извлечение методов и функций
• Упрощение условной логики
• Удаление дублирования кода

Еженедельный refactoring (компонентный уровень)

Когда появляется новая функциональность, часто нужно переструктурировать компоненты:

// Было - монолитный компонент
function UserDashboard({ userId }) {
  const [user, setUser] = useState();
  const [posts, setPosts] = useState([]);
  const [followers, setFollowers] = useState([]);
  const [following, setFollowing] = useState([]);
  // ... 200 строк кода
}

// Стало - разделено на компоненты
function UserDashboard({ userId }) {
  return (
    <div className="grid grid-cols-3 gap-4">
      <UserInfo userId={userId} />
      <UserPosts userId={userId} />
      <UserNetwork userId={userId} />
    </div>
  );
}

Ежемесячный refactoring (архитектурный)

Обычно раз в месяц анализируем архитектуру и планируем крупные изменения:

• Реструктуризация папок
• Переход на новый state management
• Оптимизация performance
• Улучшение type safety

Ситуации, когда refactoring критичен

1. Появление новых требований

// Было - поддерживали только активных пользователей
function getActiveUsers() {
  return users.filter(u => u.isActive);
}

// Пришло требование показывать заблокированных
// Стало - более гибкая фильтрация
function filterUsers(status) {
  const statusMap = {
    active: u => u.isActive && !u.isBlocked,
    inactive: u => !u.isActive,
    blocked: u => u.isBlocked,
  };
  return users.filter(statusMap[status]);
}

2. Обнаружение anti-pattern'ов

// Было - prop drilling
function App() {
  return (
    <Parent theme={theme} />
  );
}

function Parent({ theme }) {
  return <Child theme={theme} />;
}

function Child({ theme }) {
  return <GrandChild theme={theme} />;
}

function GrandChild({ theme }) {
  return <div style={{ background: theme.bg }} />;
}

// Стало - использован Context
const ThemeContext = createContext();

function App() {
  return (
    <ThemeContext.Provider value={theme}>
      <Parent />
    </ThemeContext.Provider>
  );
}

function GrandChild() {
  const theme = useContext(ThemeContext);
  return <div style={{ background: theme.bg }} />;
}

3. Performance проблемы

// Было - постоянный рендер
function ProductList({ products }) {
  return (
    <div>
      {products.map(p => <ProductCard key={p.id} product={p} />)}
    </div>
  );
}

// Было - все пересчитывается
function ProductCard({ product }) {
  const discountPrice = product.price * (1 - product.discount / 100);
  return <div>{discountPrice}</div>;
}

// Стало - мемоизация
const ProductCard = memo(function ProductCard({ product }) {
  const discountPrice = useMemo(
    () => product.price * (1 - product.discount / 100),
    [product.price, product.discount]
  );
  return <div>{discountPrice}</div>;
});

4. Type safety

// Было - any типы
function handleUserUpdate(user) {
  // Что здесь в user? Не понятно
  return updateUser(user);
}

// Стало - строгие типы
interface User {
  id: string;
  name: string;
  email: string;
  role: 'admin' | 'user' | 'guest';
}

function handleUserUpdate(user: User): Promise<User> {
  return updateUser(user);
}

Мой подход к refactoring'у

Правило: не рефакторить без тестов

// Сначала пишу тесты
describe('calculateDiscount', () => {
  it('должен корректно рассчитывать скидку', () => {
    expect(calculateDiscount(100, 10)).toBe(90);
  });
  
  it('не должен делать отрицательную цену', () => {
    expect(calculateDiscount(100, 150)).toBe(0);
  });
});

// Потом рефакторю, уверенный в коректности
function calculateDiscount(price, discountPercent) {
  const discount = price * (discountPercent / 100);
  return Math.max(0, price - discount);
}

Маленькие шаги

• Один refactoring = один commit
• Не смешиваю логику с рефакторингом
• После каждого шага прогоняю тесты

Баланс между чистотой и delivery

Не все стоит рефакторить:

// Не рефакторю код, который:
// - Работает и не изменяется
// - Критичен по performance (если refactoring замедлит)
// - Близко к удалению (legacy код)
// - Покрыт контрактом с клиентом

// Рефакторю код, который:
// - Часто меняется (горячие точки)
// - Сложен для понимания
// - Дублируется
// - Содержит баги

Примеры крупных refactoring'ов

1. Миграция с Redux на Context API

// Было - Redux boilerplate
const initialState = { user: null };
function userReducer(state, action) {
  switch(action.type) {
    case 'SET_USER': return { user: action.payload };
    case 'CLEAR_USER': return { user: null };
    default: return state;
  }
}
const store = createStore(userReducer);

// Стало - простой Context + Hook
const UserContext = createContext();

export function useUser() {
  const [user, setUser] = useState(null);
  return { user, setUser };
}

2. Переход на TypeScript

Использовал gradual migration:

// Шаг 1: tsconfig.json с allowJs: true
// Шаг 2: Переименовал .js на .ts
// Шаг 3: Добавлял типы постепенно
// Шаг 4: Исправлял ошибки компилятора

// Результат: полная type safety без перерывов в разработке

3. Code splitting и lazy loading

// Было - один большой бандл
import { Dashboard } from '@/pages/Dashboard';
import { Analytics } from '@/pages/Analytics';

// Стало - lazy loading
const Dashboard = lazy(() => import('@/pages/Dashboard'));
const Analytics = lazy(() => import('@/pages/Analytics'));

Практические вывод

Refactoring — это не "лишняя работа", это инвестиция в:

• Скорость разработки (легче добавлять функции)
• Качество (меньше багов)
• Team happiness (приятнее работать с чистым кодом)
• Контроль над техдолгом

Золотое правило: Don't refactor for refactoring's sake. Рефакторь, когда:

• Нужно добавить функцию (сначала подготовь структуру)
• Нашел баг (поправь и улучши)
• Видишь дублирование (извлеки функцию)
• Performance проблемы (оптимизируй)
• Новый разработчик не понимает код (упрости)