Русский | English

Привет! Я Миша

Фронтенд-инженер (и немного бэкендер). Пишу на React, Next.js и Expo.

Делаю веб, мобильные и десктопные приложения (Tauri 2 / Rust). Люблю упрощать работу над проектом: автоматизировать рутину, чинить сборки и релизы, удалять мёртвый код.

Связаться: Telegram

---

Стек каждый день

• Frontend: Next.js (App Router, RSC), React, TypeScript, Tailwind CSS, Vite (Rollup/Rolldown)
• Mobile и Desktop: React Native, Expo, Reanimated; Tauri 2, Rust
• Состояние и данные: Zustand, TanStack Query, WebSockets
• Архитектура и качество: Feature-Sliced Design, Vitest, Oxlint, Prettier, Fallow, Lefthook
• AI и процессы: Claude Code, Git, GitLab CI, GitHub Actions

С чем ещё работал

• Web и Desktop: Astro, TanStack Router, React Router, CSS Modules, Turbopack, WebGL, React Flow, dnd-kit
• Mobile: MMKV, Firebase, Gesture Handler, Bottom Sheet
• Состояние и данные: Redux Toolkit, Immer, REST, JSON-RPC
• Инструменты и DevOps: Docker, Nginx, Jest, Knip, Fastlane, Semantic Release, npm, pnpm, Yarn, Bun
• Бэкенд: Node.js, NestJS, Express, FastAPI, PostgreSQL, MongoDB, Laravel

---

Принципы, на которых строю работу

1. Понятная кодовая база

Объём, который можно удержать в голове, ограничен (и у человека, и у AI). Код должен читаться по частям:

• Архитектура и нейминг подсказывают контекст без чтения половины проекта.
• Явные границы модулей: узкий вход и выход, зависимости направлены в одну сторону.
• Документация объясняет почему (причины решений и правила), а не что: это видно из кода.

2. Проверки поверх тестов и линтеров

Результат предсказуем, когда его проверяет независимая автоматика, а не доверие к автору:

• Инварианты проекта проверяются механически: границы слоёв, запрещённые зависимости.
• Быстрый фидбек: ошибка ловится сразу (pre-commit, CI), а не на ревью.
• Тестируется поведение и сквозные сценарии, а проверяющий независим от проверяемого.

3. Измеримое качество ревью

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

• Ревью масштабируется хуже написания кода, поэтому его нужно удешевлять: небольшие изменения с чёткой целью и автоматические проверки до него.
• Изменения в процессе ревью проверяются на регрессии по тому же набору.