Маркина. Системно

🔞 PROVOKE: история, которая началась на улице
Сегодня на Хабре вышла моя статья — первая из серии про наш с Тарасом доклад «PROVOKE: системный анализ между соблазнением, манипуляцией и властью», который занял 3 место на Analyst Days 22.
Она не про слайды, не про структуру и не про то, как мы репетировали. Она про то, как мы придумали тему. Про прогулку по Москве после первой конференции, про разговор на улице, про ужин, про кафе на следующий день. Про то, как идея родилась не тогда, когда мы её искали, а когда просто шли и говорили.
Это история о том, как решение делать доклад вдвоём принимается за один вечер. И о том, почему лучшие решения приходят быстро — без долгих обсуждений, без взвешивания «за» и «против». Просто смотришь на человека и знаешь: да, это он. Это мы.

❓ Зачем пишу этот пост
Во‑первых, чтобы вы знали: Хабр читают. И на нём стоит публиковаться. Если у вас есть что сказать — говорите. Если у вас есть идея — записывайте. Если вы сомневаетесь — попробуйте. Это не первая моя статья на Хабре, но после долгой паузы и я планирую продолжать.
Во‑вторых, анонсирую продолжение. В следующих частях я напишу:
— как мы готовили доклад за 1500 км друг от друга
— с какими сложностями столкнулись, выступая вдвоём
— как мы спорили о каждом слайде и что из этого вышло
Подписывайтесь на мой блог на Хабре, чтобы не пропустить.
В‑третьих, вопрос к вам: читаете ли вы Хабр? Пишете ли сами? Или считаете, что эта площадка уже не та, что была раньше? 👇 Мне правда интересно.
Ссылка на статью
Ссылка на доклад
Ссылка на первую статью на Хабре

#Байки

🫁 Микрофронтенды vs SPA: когда монолит перестаёт дышать
SPA (Single Page Application) — это классика. Один фронтенд-репозиторий, одна сборка, одна точка входа. Загрузился раз — и дальше роутинг живёт внутри браузера без перезагрузок. Всё просто и предсказуемо.
Microfrontends (Микрофронтенды) — это «микросервисы на клиенте». Большое приложение собирается из независимых модулей (виджетов/микро-приложений), каждый из которых может разрабатываться отдельной командой, на своей технологии и выкатываться по своему графику.

⚔️ SPA: плюсы и минусы
✅ Плюсы:
После загрузки — молниеносный роутинг
Один стек на всю команду — проще онбординг
Легко шарить утилиты, UI-кит, логику через общий код
Сборка и деплой — тривиальные (одна команда build)
❌ Минусы:
Первая загрузка может раздуваться до огромных размеров (бандл толстеет со временем)
Код превращается в монолит: страшно менять что-то в «старой» зоне, потому что непонятно, кто ещё это использует
Любое изменение — пересборка и перекат всего приложения целиком
Разные команды в одном репозитории начинают мешать друг другу (конфликты в package.json, разный стиль кода, очереди на деплой)

🧩 Микрофронтенды: плюсы и минусы
✅ Плюсы:
Команды полностью независимы: каждый сам решает, когда выкатывать фичу
Можно обновить один модуль без пересборки всего остального — деплой точечный
Технологическая свобода: команда А пишет на React, команда Б — на Vue, команда В — на Angular (и это реально работает через Module Federation или Single-SPA)
Масштабирование разработки: 10+ команд работают параллельно, не наступая друг другу на пятки
❌ Минусы:
Инфраструктура резко усложняется: нужна сборщица (оркестратор), которая склеивает части в рантайме
Дублирование кода — общая боль. Каждый модуль тащит свою копию React, свои стили, свои утилиты, если не настроить разделение зависимостей
Роутинг и общее состояние (например, корзина в маркетплейсе) требуют отдельной архитектуры, которую надо продумывать с нуля
Высокий порог входа: новому разработчику надо понять, как работают 5 модулей, а не один монолит

🎯 Когда что выбирать
SPA подходит, если:
➖ Команда до 10–15 человек
➖ Приложение не разбито на жёсткие доменные зоны
➖ Вы не переживаете, что не сможете обновить часть без переката всего
➖ Хотите быстро стартовать и минимизировать инфраструктурные затраты
Микрофронтенды оправданы, если:
➖ Команда более 20 разработчиков (или активно растёт)
➖ У приложения есть чёткие домены: каталог, корзина, личный кабинет, админка
➖ Разные команды хотят быть независимыми в выборе технологий и графиков релизов
➖ Это Enterprise, где части продукта могут развиваться разными темпами
Классический пример:
Веб-версия маркетплейса. Команда «Каталог» пишет на React, команда «Корзина» — на Vue, команда «Личный кабинет» — на Angular. Все три собираются в одну страницу через Webpack Module Federation или Single-SPA. Пользователь видит единый сайт, а внутри — модули от разных команд.

🎓 Моё резюме
Микрофронтенды — это не про «круто», а про «больно, но надо, когда выросли». Это те же микросервисы, только на фронте: та же независимость и та же головная боль с инфраструктурой.
Мой совет: не начинайте с микрофронтов. Начните с хорошего SPA-монолита. Используйте правильную архитектуру внутри (FSD, модули, чёткие слои). Когда монолит начнёт душить вас организационно — тогда и задумайтесь о разделении.
А у вас что за проект? SPA или уже микрофронтенды? Если делите — как именно? В рантайме или на сборке? 👇

#Термины #Архитектура

📩 Как принимать критику и не взрываться
В прошлом посте мы говорили о том, как давать конструктивную обратную связь. Но критика — это диалог, и вторая сторона в нём не менее важна. Умение принимать замечания без потери самооценки и отношений — это навык, который открывает двери в карьере и жизни.

🧠 Почему сложно принимать критику
Это не слабость, это биология. Нейровизуализационные исследования (МРТ) показывают, что критика активирует те же зоны мозга, что и физическая боль — особенно переднюю поясную кору и островковую долю. Мозг включает защиту: отрицание, оправдания, контратака.
Это нормальная эволюционная реакция. Но если не научиться её тормозить, вы:
➖ перестанете слышать полезную информацию
➖ испортите отношения с людьми, чьё мнение важно
➖ застрянете в карьере (никто не хочет работать с тем, кто не воспринимает обратную связь)
Важный нюанс: критика особенно ранит перфекционистов и людей с заниженной самооценкой — они склонны воспринимать замечание не как «ошибку в задаче», а как «я неудачник». Этот внутренний перевод «факт → приговор» и есть главный источник боли. Осознание этого механизма уже помогает снизить накал.

🛠 Алгоритм приёма критики (5 шагов)
1️⃣ Остановитесь
Не отвечайте сразу. Сделайте вдох. Скажите: «Спасибо, я услышал. Дай подумать минуту». Эта пауза прерывает автоматическую защитную реакцию.
2️⃣ Отделите факты от интерпретации
Здесь важно различать три уровня:
📌 Факт — объективное событие. Пример: «В двух последних спринтах я сдал задачи на день позже».
📌 Обобщение — преувеличение. Пример: «Ты вечно срываешь сроки».
📌 Интерпретация — оценочный вывод. Пример: «Ты безответственный» или «Твой код — каша».
Ваша задача — отсечь обобщения и интерпретации и остаться в поле фактов. Вместо «мой код — каша» спросите себя: «Какая конкретная часть кода вызвала замечание?» Обычно там оказывается один спорный момент, а не вся ваша профессиональная жизнь.
3️⃣ Уточните, если что-то непонятно
Не достраивайте догадки — задавайте вопросы:
✅ Можешь привести конкретный пример?
✅ Что именно в моей работе тебя не устроило?
✅ Что ты предлагаешь сделать иначе?
4️⃣ Поблагодарите за обратную связь
Даже если критика кажется несправедливой. Фраза «Спасибо, что сказал» не означает «я согласен». Это означает «я услышал и подумаю». Это сохраняет отношения и оставляет вам пространство для манёвра.
5️⃣ Решите, что делать
После паузы возможны варианты:
🔸 согласиться и изменить поведение
🔸 не согласиться и аргументированно объяснить почему (по фактам, а не эмоциям)
🔸 попросить время подумать

🎯 Кого критикует — так же важно, как и что
Не всякая обратная связь имеет одинаковый вес. Вот простая система оценки, которая поможет не тратить нервы зря:
🔥 Компетентный и доброжелательный — это золотой источник. Слушайте внимательно и благодарите.
🙉 Некомпетентный, но доброжелательный — вежливо выслушайте, но не спешите внедрять. Проверьте факты сами.
⚠️ Компетентный, но недоброжелательный — фильтруйте. Может быть полезно, но перепроверяйте каждое замечание.
🚫 Некомпетентный и недоброжелательный — это не критика, а шум. Пропускайте мимо ушей без чувства вины.
Уважающий вас человек не будет использовать оскорбительные формулировки. Если критикующий не разбирается в вашей работе и не желает вам добра — его мнение можно игнорировать.

❓ Как реагировать на несправедливую критику
Формула: Признание + Вопрос + Переход в конструктив
❌ Ты не прав, у меня всё нормально
✅ Я слышу твою оценку. Можешь привести пример, где я поступил не так?
Если критика — это оскорбление или переход на личности:
«Я готов обсуждать факты и конкретные действия. Если ты переходишь на личности, я вынужден остановить разговор и вернуться к нему, когда мы оба будем готовы к диалогу».
Отдельный случай — троллинг или пассивная агрессия. Если человек не приводит аргументов, использует обобщения («все так говорят») или насмехается — это не критика. Не тратьте время на анализ такого «фидбека». Лучшая реакция — коротко и нейтрально закончить диалог.

🎓 Моё резюме
Принимать критику — навык. Он тренируется. Главные принципы:
➡️ не защищаться сразу — дайте себе паузу
➡️ отделять факты от обобщений и оценок
➡️ уточнять, а не додумывать
➡️ благодарить за обратную связь, даже если она неприятна
➡️ фильтровать источник — не всё сказанное заслуживает вашего внимания
И помните: если вы никогда не получаете критику — вы, скорее всего, стоите на месте. Рост начинается там, где заканчивается зона комфорта.

#Карьера #SoftSkills

🔆 Как давать обратную связь: модели, которые работают
В продолжении поста про конструктивную критику.
🧠 Модель SBI (Situation — Behaviour — Impact)
Разработана в Центре творческого лидерства (CCL). Используется в крупных корпорациях по всему миру.
Situation (ситуация) — когда и где это случилось.
Пример: «На совещании во вторник...»
Behaviour (поведение) — конкретное действие (только факты, без оценок).
Пример: «...ты сказал, что моя идея не сработает, и не объяснил почему»
Impact (влияние) — последствие для дела, команды, процесса.
Пример: «Я растерялся и не стал предлагать ещё одну идею, которая могла быть полезной»
Почему SBI работает:
✅ Конкретика. Человек знает, о каком именно моменте речь.
✅ Нет оценок. Вы говорите про действия, а не про личность.
✅ Понятны последствия. Объясняется, почему проблема важна, а не «потому что я так сказал».

🍞 Про «сэндвич» (похвала — критика — похвала)
Метод всё ещё популярен, но исследования (включая работу профессора Карен Макмиллан) показывают: он чаще вредит.
Почему:
❌ Люди запоминают только середину
❌ Похвала в начале и конце кажется неискренней
❌ Создаётся ощущение манипуляции
Когда сэндвич может работать:
Если у вас доверительные отношения и вы регулярно даёте обратную связь, а не раз в полгода.

🎯 Другие модели
1️⃣ COIN (Context — Observation — Impact — Next steps)
Расширенная версия SBI. В классической версии буква C означает Context (Контекст), а не «Care», как иногда пишут в адаптациях. Контекст помогает ещё точнее обозначить обстоятельства, а уже затем вы переходите к наблюдению и последствиям.
Context (Контекст): «На встрече с заказчиком вчера...»
Observation (Наблюдение): «...ты сказал "это невозможно" без объяснений».
Impact (Влияние): «Заказчик замолчал и теперь не говорит о рисках».
Next steps (Следующие шаги): «Давай в следующий раз фиксировать проблемы словами "я вижу риск", а потом обсуждать решения».
2️⃣ Модель «Я — Мы — Ты» (формула быстрой связи)
Популяризирована консалтинговой компанией Bain & Company как структура для командной динамики. В рабочей практике её часто адаптируют для быстрой постановки задач или срочных правок в переписке.
«Я»: «Я заметил, что отчёт по практике задержался на три дня».
«Мы»: «Нам нужно сдать его к пятнице».
«Ты»: «Можешь прислать черновик завтра к обеду, чтобы я успел проверить?»
⚠️ Эту модель часто путают с Radical Candor («Честность»), но это разные подходы. Radical Candor строится на сочетании личной заботы и прямой конфронтации, а «Я — Мы — Ты» — это просто чёткая структура просьбы.

🎓 Моё резюме
Выберите модель, которая удобна вам. SBI — самая универсальная для рабочих ситуаций. COIN — для эмоционально сложных разговоров. «Я — Мы — Ты» — для быстрого решения задач.
Главное в любой модели: конкретика, факты, отсутствие оценок личности и чёткий переход к действиям. Сэндвич оставьте в прошлом.

Что думаете? Какая модель ближе вам в работе? 👇

#Карьера #Инструменты

🖋Конструктивная критика: что это такое (и что — нет)
📖 Определение
Конструктивная критика — форма обратной связи, которая направлена на выявление недостатков и предложений по их устранению, осуществляемая с фокусом на позитивных аспектах работы. Это не просто указание на ошибки, а детальный и обоснованный анализ, который позволяет человеку увидеть свои слабые места и понять, каким образом он может улучшить свою практику.
В более широком философском смысле конструктивная критика — «созидательная критика, предлагающая конкретные пути решения проблем, реальные методы разрешения противоречий, эффективные способы преодоления заблуждений». В отличие от негативной, разрушительной критики («голого» отрицания всего и вся), конструктивная критика не просто отбрасывает критикуемые концепции, но сохраняет их позитивное, рациональное содержание.
Неконструктивная критика — оценка личности, обобщения, эмоции без фактов.

🧠 Ключевое различие: факты vs оценки
Факты можно проверить. Оценки — это чужое мнение, часто эмоциональное.
❌ «Ты вечно опаздываешь» — это оценка, обобщение.
✅ «Ты пришёл на встречу в 10:15 вместо 10:00» — это факт.
❌ «Ты пишешь ужасный код» — оценка личности.
✅ «Этот метод не обрабатывает null» — факт.
❌ «Ты не умеешь писать ТЗ» — оценка.
✅ «В разделе 2 нет ошибочного сценария» — факт.

⚖️ Почему люди боятся критики
Исследования показывают: мозг реагирует на критику так же, как на физическую боль. Поэтому даже нейтральные замечания воспринимаются как угроза.
Конструктивная критика снижает эту реакцию, потому что:
➖даёт понятные рамки («сделай вот это» вместо «ты плохой»)
➖оставляет лицо («я совершил ошибку», а не «я — ошибка»)

📌 Примеры из практики
Ситуация: Коллега перебивает вас на совещаниях.
❌ Неконструктивно: «Ты грубиян, вечно меня перебиваешь».
✅ Конструктивно: «На последних трёх совещаниях, когда я начинал говорить про API, ты вступался в диалог. Мне сложно донести мысль. Давай договоримся: я поднимаю руку или говорю «дай закончить», и ты ждёшь паузы».
Ситуация: Студент сдал отчёт с ошибками в формулах.
❌ Неконструктивно: «Ты безграмотный, не учил матан».
✅ Конструктивно: «В разделе 3 во второй формуле неправильно посчитана дисперсия. Ошибка в знаменателе. Сверься с методичкой на стр. 15 и приди на консультацию завтра».
Ситуация: Разработчик прислал код с проблемами.
❌ Неконструктивно: «Ты халтурщик, переделывай всё».
✅ Конструктивно: «В этом классе нет обработки ошибок при пустом вводе. Пользователь увидит непонятное сообщение. Добавь проверку и верни на ревью».

🎓 Моё резюме
Конструктивная критика — это не про «быть вежливым». Это про точность и полезность. Она — важнейшее условие для профессионального развития. Если вы не можете сформулировать, что конкретно не так или что делать, — не критикуйте. Сначала поймите сами.
#Карьера

📄TypeSpec: новый язык для API или очередная мода?
На Analyst Days 22 Руслан Папенко рассказывал про TypeSpec от Microsoft. Тема действительно горячая, но в индустрии любят волны хайпа — был RAML, был API Blueprint, теперь вот TypeSpec.
Я послушала, сравнила с OpenAPI и альтернативами. Делюсь выжимкой для прагматиков.

🧐 Что такое TypeSpec
TypeSpec — это предметно-ориентированный язык (DSL) для описания API. Он не заменяет OpenAPI напрямую, а компилируется в него (и не только). Релиз — апрель 2024, Microsoft, открытый исходный код.
Синтаксис напоминает TypeScript. Вы описываете модели данных, операции, а генератор выдаёт:
➖ спецификацию OpenAPI (YAML/JSON)
➖ документацию (например, HTML/Markdown)
➖ клиентские SDK на нескольких языках (основная поддержка TypeScript, .NET, Java, Python)
➖ генерация серверных заглушек (ограничена в основном .NET и JavaScript)
Звучит круто. Но давайте по фактам.

⚔️ Почему OpenAPI уже не торт
Презентация Руслана на Analyst Days и мнения инженеров со всего мира сходятся: OpenAPI, при всей своей популярности, доставляет много боли.
❌ Проблема №1: Нечеловеческий синтаксис
OpenAPI использует YAML или JSON — форматы, удобные для машин, но не для людей. Описания получаются многословными, часто похожими на «спагетти» из вложенных блоков. А разработчики с усталостью вспоминают, что им постоянно приходится подсматривать в документацию даже для простых вещей.
❌ Проблема №2: Сложность на масштабе
Если в проекте больше пары десятков эндпоинтов, спецификация превращается в гигантский файл (условно на 2000-3000+ строк). Отладка и поддержка такой простыни становятся крайне трудоёмкими.
❌ Проблема №3: Design-First страдает
OpenAPI создавался как формат документации готового API, не спорю, что далее он уже развивалась как формат для Design first. Если мы говорим про объёмные enterprise-системы, то вносить точечные изменения в разросшиеся YAML-файлы — пытка, да — есть визуальные редакторы...

💡 Чем TypeSpec лучше
Если взять простой пример (приводить не буду, был на конференции и полно в "интернетах"), то разница очевидна, разница будет раза в 3 по количеству строк.
✅ Композиция без боли
✅ Не привязан к REST
Описав модели, можно сгенерировать не только OpenAPI, но и gRPC (protobuf), AsyncAPI для сообщений, даже GraphQL.
✅ Один источник правды
Меняете модель — перегенерировали клиента, документацию, моки. Забыли обновить документацию вручную — не ваш случай.

🔄 Полная картина: какие есть альтернативы
Вопрос рёбром: инновация или тренд? Хочу расширить контекст. TypeSpec — не единственный игрок на поле «API как код».
1️⃣ Design First
Платформы вроде Apidog или Stoplight Studio отходят от сырого YAML . Они предлагают визуальные редакторы, схемы перетаскиванием, авто-моки и документацию на лету.
Плюсы: GUI понятен даже нетехническим специалистам. Минусы: GitHub не всегда удобен для ревью тяжелых PNG.
2️⃣ Code First
Инструменты вроде Swaggo (Go) или SpringDoc (Java) парсят комментарии в коде и генерируют OpenAPI.
Плюсы: Документация всегда соответствует коду. Минусы: Код обрастает аннотациями, сложно охватить всю систему целиком.
3️⃣ Альтернативные DSL и Protocol Buffers
Если TypeSpec от Microsoft, то Smithy от Amazon (используется в AWS) существует дольше.
Protocol Buffers (protobuf) от Google — вообще тяжёлая артиллерия для микросервисов.
Плюсы: Скорость, строгая типизация, поддержка в любом языке. Минусы: Бинарный протокол, REST вы получаете через транзакцию.

🎓 Моё резюме
Инструмент действительно зрелый, но ещё не полностью готов для промышленного использования всеми командами в любом масштабе.
Пробовали уже TypeSpec? Или всё ещё на YAML? 👇

#Инструменты

🗓 Мой тайм-менеджмент: списки, лягушки и никакой магии
Меня часто спрашивают: «Как ты всё успеваешь? Преподавание, ТризТех (PT), конференции, канал...».
Отвечу честно: никакой магии. Просто система. И работает она не всегда, но чаще да.
Пост по следам моего спикера Анастасии «Приготовления зелий продуктивности», ей отдельная благодарность за отличное выступление. Делюсь своей системой — и новыми ингредиентами.

✅ Списки — база
Каждый день 10–17 задач и встречи в календаре. Не в голове — меньше стресса. Как выполнила или вечером проставляю галочки и выдыхаю.

🐸 Лягушка на завтрак
Самую противную задачу — первой. Сегодня это был сложный отзыв на ВКР. Сделала — и день пошёл.

⏱️ Правило 10 минут
Не идёт задача? Завожу таймер на 10 минут и просто начинаю. Через 10 минут спрашиваю себя: «Хочу продолжать?».
Часто — да. А если нет, значит, задача реально не сегодня. Но первые 10 минут ломают лёд.

✂️ Дробление задач
Вместо «Написать отзывы на ВКР»: «Найти старый шаблон отзыва» → «Обновить шаблон отзыва» → «Написать отзыв на ВКР студента А» → «Написать отзыв на ВКР студента Б». Маленькие шаги не пугают.

🚫 WIP Limits — не брать много
Work In Progress Limits — правило: одновременно не больше 2–3 задач. Иначе мозг перегружается, и ни одна не делается до конца.

❌ Что не зашло (на данный момент)
Геймификация — превращать работу в игру не люблю.
Прогрессивная нагрузка — мой ритм и так хаотичный.
Парное присутствие — если собака спящая рядом не считается, то мне никто не нужен для работы.
Метод помодоро — с моим количеством задач и переключений 25-минутные интервалы только сбивают. Заменила на правило 10 минут + дробление.

🎓 Моё резюме
Тайм-менеджмент — это не магия. Это набор приёмов. Берите то, что работает для вас.
Мой набор сейчас: списки + лягушка + правило 10 минут + дробление задач + WIP Limits.
Какие техники помогают вам? 👇

#Карьера #Инструменты

🤯 Vertical Slice Architecture vs Onion Architecture — не надо выбирать, берите оба
Спойлер: они про разное. И отлично уживаются вместе.

🧅 Луковая архитектура (Onion Architecture)
Придумал Джеффри Палермо в 2008.
Идея: код — как луковица, в центре бизнес-логика, вокруг слои: инфраструктура, API, базы данных.
Главное правило: зависимости только внутрь. Внешние слои знают про центр, центр — не знает про них.
Зачем:
✅ Бизнес‑логика не зависит от технологий
✅ Легко менять базу данных или API
✅ Всё можно протестировать изолированно
Минус: слоёв много. Для простой фичи приходится править файлы в трёх местах.

🍕 Вертикальные срезы/слайсы (Vertical Slice Architecture)
Продвинул Джимми Богард в 2018.
Идея: не делить код на слои (контроллеры, сервисы, репозитории), а группировать по фичам.
В одной папке лежит всё, что нужно для выполнения одного сценария: от запроса до SQL.
Зачем:
✅ Одну фичу может делать один разработчик — не конфликтуют
✅ Фичу легко удалить — просто стереть папку
✅ Не нужно лазить по всему проекту
Минус: если не следить, код дублируется в разных слайсах.

🔥 А теперь главное: как их соединять
Многие думают, что это взаимоисключающие подходы, но это не так
Схема «брак по расчёту»:
На верхнем уровне — вертикальные слайсы.
Делим проект по фичам: Orders, Products, Users. Каждая фича — независимая папка.
Внутри каждой фичи — луковая архитектура.
Свои слои: бизнес‑логика, инфраструктура, API. Зависимости — строго внутрь.
Что получается:
Вертикальные слайсы отвечают на вопрос: Как сгруппировать код, чтобы не мешать друг другу?
Луковая архитектура отвечает на вопрос: Как организовать зависимости, чтобы бизнес‑логика не привязывалась к базе данных?
Внутри одного слайса PlaceOrder вы можете использовать MediatR, CQRS, чёткие слои. Но соседний слайс CancelOrder об этом ничего не знает.

📦 Пример на пальцах
src/
├── Features/
│ ├── Orders/
│ │ ├── PlaceOrder/ # Вертикальный слайс
│ │ │ ├── Domain/ # Луковая архитектура внутри
│ │ │ ├── Application/
│ │ │ ├── Infrastructure/
│ │ │ └── Presentation/
│ │ └── CancelOrder/ # Другой слайс
│ └── Products/

🎓 Моё резюме
Onion защищает бизнес‑логику от внешнего мира.
Vertical Slice защищает разработчиков друг от друга.
Не выбирайте один подход. Берите лучшее от каждого. Архитектура должна работать на проект, а не проект на архитектуру.

#Инструменты #Термины