Вам (не) нужен рефакторинг

За всю мою карьеру в 80% «полезный» рефакторинг приводил к случаям: «ой у нас отвалилось треть функционала».

👨‍💻Рефакторинг это норма и конечно можно и нужно его делать. Но вот когда все работает и когда есть бизнес фичи ЗАЧЕМ?)

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

Кайф да и только 😋😍

🚫 КАК НЕЛЬЗЯ ВНЕДРЯТЬ AI / CHATGPT

Расскажу, как на моём реальном проекте внедряются нейронки 🤖
Это не просто

«отправил данные по API с токеном и визуализировал результат»

1️⃣ Системный промпт 🧠

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

export const SYSTEM_PROMPT_V1 = `
You are an assistant helping to analyze user input.
Rules:
- Return JSON only
- If data is insufficient, return "INSUFFICIENT_DATA"
Output format:
{
  "summary": string,
  "confidence": number
}
`;

2️⃣ Анонимизация данных 🔐

Перед тем как отправить персональные данные, их обязательно нужно обезличить.
Мы сделали отдельный сервис анонимизации, который:
🧹 удаляет / маскирует персональные данные
🏷️ заменяет сущности на нейтральные имена
🛡️ гарантирует, что модель не видит реальные данные

Внутри сервиса анонимизации крутится отдельная логика замены данных.

POST /anonymize
{
  "text": "Иван Иванов работает в компании X и живет в Москве"
}

function anonymize(text: string) {
  return text
    .replace(/[А-ЯЁ][а-яё]+ [А-ЯЁ][а-яё]+/g, "USER_NAME")
    .replace(/Москва|Санкт-Петербург/g, "CITY");
}

3️⃣ Оркестратор вместо прямого вызова AI 🧩

Мы не дергаем ChatGPT напрямую ❌
Есть оркестратор, который:
🔁 управляет пайплайном
🤖 решает, какую модель использовать
🧠 оперирует контекстом, если он есть

async function aiPipeline(rawInput: UserInput) {
  const anonymized = await anonymizeService(rawInput);

  const preparedPrompt = buildPrompt({
    system: promptRegistry.v1,
    user: anonymized.text,
  });

  const aiResponse = await callLLM(preparedPrompt);

  const validated = validate(aiResponse);

  return postProcess(validated);
}

4️⃣ Пост-обработка ответа ✅
Ответ модели это не конец. После ответа LLM мы:
🧪 валидируем структуру
🚫 фильтруем некорректные данные
🎯 приводим результат к виду, пригодному для UI / API

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

При интеграции важно учесть архитектуру, безопасность, контроль и ограничения

Микрофронтенды

Микрофронты — это подход, при котором большое фронтенд-приложение разбивается на независимые части, каждая из которых:
🚧 разрабатывается отдельно
🚀 может деплоиться независимо
👥 имеет свою команду и ответственность

По сути, это микросервисы, но для фронтенда 🧩

🤔 Зачем это делают?

Тут похоже как с микросервисами:
желание поделить монолит на независимые куски,
чтобы не зависеть от других команд / функционала.

👨‍💻 Как это выглядит в коде

SPA composition (через роутинг)

Shell-приложение решает, какое SPA показывать по URL:

// shell/App.tsx
import { BrowserRouter, Routes, Route } from "react-router-dom";

export function App() {
  return (
    <BrowserRouter>
      <Routes>
        <Route path="/profile/*" element={<ProfileApp />} />
        <Route path="/billing/*" element={<BillingApp />} />
      </Routes>
    </BrowserRouter>
  );
}

✅ Плюсы очевидны:
- независимые релизы
- масштабирование команд
- изоляцию ошибок
- можно использовать React, Vue, Angular одновременно

❌ Минусы тоже есть:
- сложнее инфраструктура
- сложнее дебаг
- выше требования к архитектуре

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

Микрофронты оправданы, если вы работаете на большом проекте 🏗️

В моей практике я использовал микрофронты на очень больших проектах:
🏦 2 больших банка и 🛒 маркетплейс.

Есть несколько вариантов реализации: Module Federation, iframe, SPA composition

// profile/webpack.config.js
new ModuleFederationPlugin({
  name: "profile",
  exposes: {
    "./ProfileWidget": "./src/ProfileWidget",
  },
});

<iframe
  src="https://billing.example.com"
  style="width:100%; height:100%; border:0"
/>

Самая дорогая фронтенд-архитектура

Есть фронтенд-навыки, которые просто закрывают задачи.
А есть те, которые повышают ценность разработчика на рынке.

💫 Микрофронты из второй категории.

их сильно ценят крупные компании — и готовы за это платить.

Микрофронты появляются, когда продукт становится большим:
много команд, независимые релизы, сложные домены.

В этот момент фронтенд перестаёт быть приложением
и становится сложной системой.

В которой вопросы без простых ответов:
— какие зависимости shared?
— кто владеет роутингом?
— где границы ответственности?

shared: {
  react: { singleton: true },
  'react-dom': { singleton: true }
}

Одна строка здесь уже архитектурное решение.
Поэтому микрофронты — одна из самых сложных
и самых дорогих архитектур во фронтенде.

На этом и построен мой интенсив по микрофронтам:
архитектура, реальные кейсы и мышление сильного инженера .

Если хочешь прокачать навык, который реально ценят работодатели смотри пробный урок.

👉 ПРОБНЫЙ УРОК

❗️Узнать детальнее в личке

👉 ПОЛУЧИТЬ ДОСТУП