https://github.com/mikeoleynik/askserega
https://askserega.ru
https://github.com/mikeoleynik/askserega
Last synced: 7 days ago
JSON representation
https://askserega.ru
- Host: GitHub
- URL: https://github.com/mikeoleynik/askserega
- Owner: mikeoleynik
- License: mit
- Created: 2026-06-20T08:17:31.000Z (16 days ago)
- Default Branch: main
- Last Pushed: 2026-06-20T08:48:02.000Z (16 days ago)
- Last Synced: 2026-06-20T10:19:56.345Z (16 days ago)
- Language: MDX
- Size: 3.09 MB
- Stars: 0
- Watchers: 0
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
- Contributing: CONTRIBUTING.md
- License: LICENSE
- Agents: AGENTS.md
Awesome Lists containing this project
README
# AskSerega — инженерная теория проекта
Каталог фреймворков, который помогает команде **выстроить, зафиксировать и передать** понимание системы — не только код.
> У дизайнеров есть Design System. У разработчиков — архитектурные паттерны.
> Но ни то, ни другое не отвечает на вопрос: **«как у нас устроена эта конкретная система и почему»**.
---
## Зачем это нужно
### У дизайнеров есть Design System, у разработчиков — нет аналога
У дизайнеров есть правила, компоненты, паттерны, токены. Это **общий язык команды**: любой дизайнер смотрит на кнопку и понимает, почему она синяя и как её использовать. Проекты передаются без боли.
У разработчиков — MVC, Clean Architecture, DDD. Они отвечают на вопрос **«как организовать код»**, а не **«как организовать понимание системы»**. Можно знать идеальный паттерн и всё равно не понимать, почему при изменении одного сервиса падает другой.
**Итог:** теория живёт в голове разработчика — уникальная или отсутствующая. Серёга уходит — и его теория умирает вместе с ним.
### Нет стартовой точки
Вы поняли, что теория нужна. Но с чего начать? Какие вопросы задать первыми? Где взять фреймворк, который заставит мозг структурировать уже известное?
В университетах учат коду и алгоритмам. В блогах — инструментам и тестам. Но редко говорят:
- *«Вот три шага, чтобы выявить скрытые допущения вашей теории»*
- *«Вот техника, которая найдёт зависимости, о которых вы не подозревали»*
Вы остаётесь один на один с тысячей деталей — без карты и компаса.
### Онбординг нового разработчика — всегда боль
Новичку дают документацию (часто устаревшую), код («разбирайся») и пару созвонов с обходом папок. Но не дают **модель**, которая была в голове у предыдущих разработчиков.
Онбординг превращается в погружение в хаос. Недели уходят на восстановление чужой теории. Иногда — безуспешно: новый код противоречит неявным решениям прошлого.
---
## Что мы предлагаем
Представьте **систему инженерных моделей, вопросов и артефактов**. Не про код, не про CI/CD — про **ваше понимание системы**.
| Что получаете | Как это работает |
|---|---|
| **Точку входа** | Выбираете боль («не понимаем сервис», «система слишком связана») — получаете упорядоченную цепочку из 4–6 фреймворков с объяснением «сначала X, потому что…» |
| **Материальную теорию** | Каждый фреймворк требует артефакт: MDX, диаграмму, ADR, чеклист. Файл лежит рядом с кодом и передаётся следующему разработчику |
| **Общий язык команды** | «Давай применим C4 к сервису заказов», «проверим допущение о синхронности» — меньше телефонной игры между людьми |
| **Опору для решений** | Теория предсказывает последствия изменений — или честно показывает пробел, который нужно закрыть до рефакторинга |
**Пример:** за 20 минут проходите фреймворк по текущей боли и выходите с картой событий, списком допущений или схемой скрытых связей.
---
## Главная идея
Питер Наур писал: программирование — это не написание кода, а создание **теории** того, как работает система.
Код — текстовый отпечаток этой теории. Если теория в голове умирает, код мгновенно становится legacy: его можно читать, но нельзя развивать — потому что потеряно «почему так сделано».
Когда Серёга увольняется, он должен оставить не только код, а **зафиксированную теорию** — с границами, вопросами и известными пробелами. Новый разработчик открывает её (и цепочку фреймворков, по которым она строилась) — и понимает систему за две недели, а не за два месяца.
**AskSerega** — опора для этого: набор моделей, вопросов и фреймворков, которые помогают постепенно выстроить целостное понимание проекта.
---
## Что такое «теория проекта» на практике
Это не абстракция. Это конкретное знание:
- понимание **границ** системы;
- понимание **причин** архитектурных решений;
- понимание **потока данных**;
- понимание **ограничений** и **инвариантов**;
- понимание того, **как безопасно добавлять новое**;
- понимание того, **что нельзя ломать**.
---
## Шесть слоёв теории
Фреймворки в каталоге распределены по слоям — от «зачем система существует» до «как она эволюционирует».
### 1. Purpose Layer — зачем система существует
- Какая задача мира решается?
- Какие ограничения бизнеса?
- Какая ценность создаётся?
### 2. Domain Layer — как система моделирует реальность
- Какие сущности и bounded contexts?
- Какие правила и термины?
### 3. Structural Layer — как система организована
- Какие модули и зависимости?
- Какие контракты между частями?
### 4. Runtime Layer — как система живёт во времени
- Какие события и потоки данных?
- Где состояние и eventual consistency?
### 5. Operational Layer — поведение под нагрузкой
- Где bottlenecks?
- Какие SLO?
- Как система ломается и деградирует?
### 6. Evolution Layer — как система изменяется
- Что volatile, что стабильно?
- Где точки расширения?
- Какие architectural pressures давят на систему сейчас?
---
## Для разработчиков
### Быстрый старт
```bash
git clone
cd askserega
npm ci
npm run dev
```
Откройте [http://localhost:3000](http://localhost:3000) — главная с болями и каталог фреймворков.
### Структура репозитория
```
content/frameworks/ # MDX-карточки фреймворков (основной контент)
src/ # Next.js UI (askserega.ru)
scripts/ # валидация контента (CI)
```
### Как участвовать
См. [CONTRIBUTING.md](./CONTRIBUTING.md) — добавление фреймворков, правила цепочек, валидация frontmatter.
Лицензия: [MIT](./LICENSE)