Обновить
1081.99

Программирование *

Искусство создания компьютерных программ

Сначала показывать
Порог рейтинга

Императивное, декларативное и генеративное программирование.

Создатели фреймворка SwiftUI всегда подчёркивают, что он создан на основе парадигмы декларативного программирования. В отличие от предыдущего фреймворка UIKit, который характеризуется как пример императивного программирования.

Когда речь заходит о том, чем императивное программирование отличается от декларативного, то объяснение чаще всего сводится к тому, что при декларативном программировании разработчику нужно просто сказать, что ему нужно и SwiftUI это сделает. А если используется UIKit, то здесь типа надо все сделать самому.

Честно говоря, не очень внятное объяснение, поэтому попробую описать это различие сам на одном примере.

Итак, если в UIKit нам нужно вывести на экран список элементов, то мы используем TableView или CollectionView, которые уже подписаны на 2 протокола, а затем должны реализовать 3 метода: количество секций, количество строк в секциях, и в третьем методе скомпоновать ячейку и прописать загрузку в неё данных.

Та же задача в SwiftUI решается следующим образом:

List(items) { item in
Text(
item.name) }

Т.е., меньше кода, меньше времени тратится на реализацию задачи.

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

Наконец, самое интересное, что с этой же точки зрения можно рассматривать и программирование с помощью ИИ. Т.е., в тех же UIKit и SwiftUI, и в других языках программирования, разработчик пишет инструкции техническим языком, которые понятны в основном ему как человеку, но не очень понятны обычным людям. А теперь, в промтах, можно использовать уже и не технические инструкции.

Например, уже даже не надо писать команду List и т.д., а достаточно сказать ИИ "сделай список из таких-то элементов".

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

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

В итоге, получаем такую триаду:

  • Императивное программирование

  • Декларативное программирование

  • Генеративное программирование

Теги:
Всего голосов 2: ↑1 и ↓10
Комментарии2

С начала года Anthropic тестирует Claude Code — терминального агента для программирования на больших языковых моделях. Совсем недавно, 4 июня, инструмент добавили в подписки Pro и Max. Энтузиасты с удовольствием принялись тестировать продукт.

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

Вероятно, Claude Code дохимичился до того, что снёс содержимое системного диска. Что конкретно случилось, автор твитов не рассказывает. Указывается лишь, что на этой машине утилита для выполнения команд с полномочиями суперпользователя sudo была настроена с директивой NOPASSWD, чтобы при вызове команды пароль вводить не приходилось.

snwy

К происшествию snwy отнёсся с явным юмором. Он в шутку пообещал добраться до штаб-квартиры Anthropic и надрать Claude зад.

Теги:
Всего голосов 2: ↑2 и ↓0+2
Комментарии0

У ChatGPT появилась память

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

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

Надо сказать, довольно занимательное чтение увидеть себя с его стороны.

Теги:
Всего голосов 4: ↑3 и ↓1+3
Комментарии3

Представлен ультимативный бесплатный гайд по вайб-кодингу, в котором есть всё. Автор — ведущий инженер Google. Внутри проекта описаны лучшие техники промптинга, готовые шаблоны, фреймворки, сценарии — всё продумано до мелочей. Там нет устаревших советов, всё подогнано под новейшие модели и ИИ-сервисы.

Теги:
Всего голосов 4: ↑2 и ↓2+1
Комментарии4

Какую тему для книги можно выбрать в 2025? Современный мир — насыщенный мир. Книг выходит очень много. Как, интересно, можно выбрать тему для книги? От этого зависит конечная аудитория книги всё-таки. Микросервисы? Внедрение зависимостей? Ещё что-нибудь? Я в смятении. А выбирать пора уже. Полгода как прошлая книга вышла...

Теги:
Всего голосов 1: ↑1 и ↓0+1
Комментарии1

Обновляем платформу SourceCraft и открываем доступ к ней для всех разработчиков

Сегодня Yandex B2B Tech открыла публичный доступ к платформе для разработки SourceCraft и представила её новые возможности. В платформу интегрированы инструменты безопасности, которые обеспечат защищённую разработку программных продуктов. А в ИИ‑помощнике SourceCraft Code Assistant появился чат‑режим, что увеличит скорость и эффективность разработки.

Удобство командной работы повысится за счёт бранч‑ и ревью‑политик, встроенных в интерфейс, а также аутентификации через SSO. Также появляется возможность зеркалирования репозиториев с GitHub и публичный API.

Инструменты безопасности

На платформе стали доступны инструменты безопасной разработки: сканер секретов в коде и анализ зависимостей в кодовой базе.

По данным исследования аналитиков Forrester интеграция инструментов безопасности в разработку на 81% снижает трудозатраты на ИБ‑поддержку всего проекта.

Чат‑режим в SourceCraft Code Assistant

ИИ‑помощником SourceCraft Code Assistant пользуются десятки тысяч разработчиков. Теперь в нём доступен чат‑режим, интегрированный непосредственно в среду разработки. В диалоговом режиме на естественном языке можно задать вопрос ИИ‑ассистенту, сгенерировать код, юнит‑тесты, документацию. Это ускорит поиск необходимой информации и оценку предлагаемых решений. Функциональность доступна в плагинах для VSCode и IDE от JetBrains.

Зеркалирование и бесшовная миграция

Миграция проектов с GitHub становится бесшовной — кроме кода переносятся Issues, PRs, Labels, Milestones, Comments. Также можно выбрать ветки для зеркалирования — непрерывной синхронизации кода.

Также появился федеративный доступ к платформе для компаний — авторизация через SSO.

Публичный API

Благодаря появлению публичного API платформа становится расширяемой. Пользователь сможет взаимодействовать с SourceCraft и обеспечивать автоматизацию и интеграцию с другими приложениями. Первая версия публичного API доступна для управления задачами, список будет пополняться.

Правила работы с ИТ‑проектами

В интерфейсе платформы появились бранч‑ и ревью‑политики — правила работы с ветками и проверками кода, которые интегрируются в систему контроля версий и процессы CI/CD.

Опенсорс

Появился анонимный доступ к публичным репозиториям платформы. Пользователи SourceCraft смогут создавать независимые копии репозиториев (forks) опенсорс‑проектов. Это позволит вносить персональные изменения, не затрагивая напрямую исходную кодовую базу. При этом копия сохраняет связь с оригиналом для получения обновлений.

Удобство работы с кодом

Интерфейс платформы теперь позволяет просматривать структуру файлов для шести языков программирования: Python, C++, Java, Go, TypeScript и JavaScript. Функциональность навигации по коду стала умнее и аналогично теперь поддерживает 6 языков.

Автоматизация CI/CD‑процессов

Среди обновлений, связанных со сборкой и развертыванием кода, появились self‑hosted runners — теперь можно запускать задачи как на виртуальных машинах Yandex Cloud, так и в своём окружении. Также появились flavours — теги для пользовательских задач, за счёт которых можно выбирать, где запускать задачу. Помимо этого в интерфейсе платформы появилась возможность не только разрабатывать, но сразу публиковать мобильные приложения в App Store, Google Play, RuStore, Huawei AppGalery.

Packages

Появилась возможность создавать и использовать собственные программные пакеты популярных форматов: наборы кода, библиотек, модулей или компонентов. Разработчик сможет хранить их в персональном облаке, привязанном к организации SourceCraft, и использовать в своих проектах. Packages также интегрированы с CI/CD платформы.

Вход в SourceCraft реализован через Яндекс ID аккаунт. Зайти на обновлённую платформу можно на сайте SourceCraft.

Теги:
Всего голосов 12: ↑12 и ↓0+13
Комментарии0

На днях в офисе я столкнулась с коллегами из направления системного программирования в «Криптоните». Они пишут на С++ — а ошибки на этом языке у нас ещё не было!

Поэтому я попросила их придумать код с ошибкой специально для Хабра — и вот что получилось!

Итак, есть ли в этом коде проблема кроме narrowing conversion? Ждём ваши варианты в комментариях.

#include <cstdint>
#include <vector>

struct Type
{
    Type(uint16_t, uint32_t = {}) 
    {}
};

int main()
{
    std::vector<Type> vector;
    std::uint32_t object_id{};

    // Есть предупреждение о narrowing conversion
    vector.insert(vector.begin(), {0, object_id}); 

    // Нет narrowing conversion
    vector.push_back({0, object_id}); 

    // Нет narrowing conversion
    vector.insert(vector.begin(), Type{0, object_id}); 
}

АККУРАТНО, ДАЛЬШЕ СПОЙЛЕР!

Проблема в том, что в строке

 vector.insert(vector.begin(), {0, object_id});

в вектор вставляется 2 элемента типа Type, а не один, как ожидает программист.

Причина в том, что метод insert у вектора имеет перегрузку (номер 5), которая вторым параметром принимает std::initializer_list. А компилятор, видя фигурные скобки в коде, в первую очередь пытается создать объект такого типа.

И тут ему это удается, потому что у конструктора Type второй параметр имеет значение по умолчанию, следовательно, Type умеет создаваться, если в конструктор передали только один аргумент. В итоге компилятор успешно создает std::initializer_list с двумя элементами типа Type.

Так как создание std::initializer_list выполняется с использованием uniform initialization, то компилятор следит за корректностью преобразований. В примере объект типа std::uint32_t передается в конструктор Type, который принимает первым параметром std::uint16_t. То есть, возникает риск потери точности (32 бита не могут поместиться в 16 бит).

Об этом компилятор и предупреждает. Вот упрощенный пример, где видим то же самое предупреждение.

Может возникнуть вопрос, почему создание Type от 0 не вызывает предупреждение, ведь 0 - это int, а он, скорее всего 32 бита и тоже не помещается в 16 бит. Но тут литерал. Компилятор видит, что 0 вмещается в 16 бит и не предупреждает. Но если поместить int в переменную, то также возникает предупреждение.

Теги:
Всего голосов 3: ↑3 и ↓0+3
Комментарии0

Открытый проект Cursor Free VIP позволяет получить бесплатный доступ к нейросети Сursor Pro для исследовательских целей. Решение я активирует бесконечный триал с откатом данных.

Теги:
Рейтинг0
Комментарии0

Новое средневековье.

Современная интернет-культура, получившая мощнейшую поддержку от LLM, воспроизводит схоластическую парадигму мышления: преобразования текста от считающихся авторитетными источников без опоры на реальный мир. Научная парадигма, опирающаяся на эксперимент, почти полностью забыта массами.

Известно, что когда Аристотель написал, что у мухи 8 ног, то почти полторы тысячи лет это утверждение воспроизводилось со ссылками на авторитет, и никому в голову не приходило пересчитать (ну он там вроде на самом деле писал про подёнок с 4 ногами и 4 крыльями, но кому какое дело). Сейчас эти времена вернулись, любой ребёнок спросит: “Алиса, сколько ног у мухи?” вместо натурного эксперимента.

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

Пруфов не будет.

Теги:
Всего голосов 17: ↑15 и ↓2+17
Комментарии13

Несмотря на кадровый голод в IT занято огромное количество лишних людей деятельность которых в общем-то бесполезна. А все что бесполезно как известно приносит только вред. Возьмем к примеру новомодную отрасль UI/UX которая по задумке должна улучшать пользовательский опыт - так называемый "экспириенс". На планете существует целый зоопарк разных форматов дат: 1 ноября 2000, 01.11.2000 и т.д и т.п. Это мелочь, но и в мелочах можно тот самый "экспириенс" взять да и улучшить. И он был повсеместно "улучшен" до формата "3 года назад". Как правило без какой либо возможности вернуть нормальную дату.

Теперь просто хочется простереть руки к небу и крикнуть за что это мне?

Самое печальное в этой ситуации, что исправить ничего нельзя. Этот самый "экспириенс" внедряется крупными корпорациями у которых достаточно ресурса чтобы содержать огромное количество людей не занятых ни какой полезной деятельностью и было бы лучше если бы они вообще ничего не делали. Как в нейросетях лишние веса приносят только вред, так и в индустрии, лишние отрасли приносят пользователям только вред.

Теги:
Всего голосов 12: ↑8 и ↓4+5
Комментарии10

Опыт использования Claude для написания готового приложения

Ну вот и я сподобился - написал приложение полностью на Claude.

Приложение на SwiftUI, не enterprise, но достаточно сложное, из категории Favorite.

Начал на Claude Sonnet 3.7, потом вышел 4, закончил на нем.

Всего 1156 строк кода и без ошибок!

Естественно было несколько итераций. Причём практически все - это уточнение промта.

Кода он наворотил много, по мне так можно было и проще. Но он уж развернулся по полной - структуры, классы, вью, перечисления, состояния, published, state и т.д. и т.п.

Как оно там внутри вертится крутится даже не смотрел. Главное - работает и этого достаточно.

В общем, впечатлён. Не ожидал. Предполагал, что будут ошибки, заторы, что придётся с ними разбираться. Ан нет, все зашло без глюков, с первого раза.

Теги:
Всего голосов 8: ↑1 и ↓7-4
Комментарии15

Задачи Структурных Паттернов: Адаптер и Компоновщик — в чём суть?

В пятой серии открытого курса «Паттерны и практики написания кода» мы начинаем новую объёмную тему — изучение Структурных Паттернов. Она состоит из семи подходов. В эпизоде вместе с бэкенд-инженером Юрой Афанасьевым погрузимся в особенности работы Адаптера и Компоновщика.

Смотреть VK
Смотреть YouTube

Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.

Теги:
Всего голосов 23: ↑22 и ↓1+21
Комментарии0

Как не только быстро развернуть бота в облаке без сложных настроек, но и сэкономить на его поддержке? Обсудим на предстоящем вебинаре 🖥️

Архитектор решений Cloud.ru Илья Смирнов расскажет:

  • как развернуть бота в облаке — варианты, а также плюсы и минусы каждого подхода;

  • в чем особенность развертывания бота;

  • какие нужны компоненты, чтобы построить бота в облаке.

А еще покажет демо по настройке вебхука для Telegram-бота, обработке событий и хранению данных в облаке.

📆 Когда: 5 июня в 11:00 мск

📍 Где: онлайн

Зарегистрироваться 👈

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

Теги:
Рейтинг0
Комментарии2

Ближайшие события

Я устал от форматирования JSON файлов

Я много и часто просматриваю JSON-файлы: от конфигураций сервисов до API ответов и логов. Каждый раз, открывая очередной файл, я форматирую содержимое, чтобы было удобнее читать (ведь JSON не только machine-readable, но и human-readable). И каждый раз я грущу, что все сервисы (онлайн, встроенные средства IDE и даже плагины) предоставляют лишь две крайности: форматировать всё или ничего (минифицировать в одну строку).

Но что, если я хочу отформатировать JSON лишь до определённого уровня? Что, если у меня есть огромный список словарей (возможно, даже глубоких), который при форматировании выглядит как-то так:

[
    {
        "id": 1,
        "name": "Alice",
        "birthday": {
            "day": 5,
            "month": 4,
            "year": 1983
        }
    },
    {
        "id": 2,
        "name": "Bob",
        "birthday": {
            "day": 6,
            "month": 2,
            "year": 1945
        }
    },
    {
        "id": 3,
        "name": "Eve",
        "birthday": {
            "day": 10,
            "month": 11,
            "year": 1978
        }
    }
]

Что, если я хочу оставить каждый словарь в более компактном (не совсем минифицированном) виде? Например, таком:

[
    {"id": 1, "name": "Alice", "birthday": {"day": 5, "month": 4, "year": 1983}},
    {"id": 2, "name": "Bob", "birthday": {"day": 6, "month": 2, "year": 1945}},
    {"id": 3, "name": "Eve", "birthday": {"day": 10, "month": 11, "year": 1978}}
]

Или я хочу, чтобы в каждом словаре развёрнуты были только внешние ключи?

[
    {
        "id": 1,
        "name": "Alice",
        "birthday": {"day": 5, "month": 4, "year": 1983}
    },
    {
        "id": 2,
        "name": "Bob",
        "birthday": {"day": 6, "month": 2, "year": 1945}
    },
    {
        "id": 3,
        "name": "Eve",
        "birthday": {"day": 10, "month": 11, "year": 1978}
    }
]

Да, многие текстовые редакторы вроде Sublime Text или VS Code дают возможность свернуть контент до определённого уровня. Но что, если я хочу оставить файл в этом промежуточном виде и просматривать его прямо в терминале, подключившись по ssh? Или я хочу посмотреть файл на гитхабе с телефона? Да, возможно, мои вкусы весьма специфичны, но в существующих реалиях я вынужден грустно довольствоваться лишь полностью развёрнутым вариантом (или делать это вручную). Встроенные средства форматирования JSON в JS или Python также не предоставляют простой возможности ограничить глубину (либо я так и не научился их готовить).

Поэтому я собрался с силами и написал свой форматтер с возможностью ограничить глубину. Помимо базового функционала вроде валидации, минификации и настройки количества отступов, в нём есть настройка максимальной глубины (по умолчанию она равна нулю, что соответствует привычному форматированию без ограничений).

Да, он вряд ли подойдёт, чтобы редактировать на лету гигантские JSON файлы. И он уж точно не пытается стать убийцей какого-либо из существующих онлайн сервисов. В первую очередь он призван решить мою проблему: сделать форматирование JSON чуточку более управляемым. А если и вы сталкивались с подобной проблемой, буду рад, если сервис поможет и вам!

Теги:
Всего голосов 7: ↑7 и ↓0+7
Комментарии0
Вот и я тоже нашёл...
Вот и я тоже нашёл...

TUI Rust, это Хабр. Хабр, я нашёл тебе годноту.

По этой ссылке https://www.youtube.com/watch?v=rWMQ-g2QDsI обнаружилось видео (11:16) с тучей прелюбопытнейших отсылок объединённых идеей использования Rust для написания консольных приложений.

А за ним занятный канал, Автор которого, помимо носительности качественного английского языка, вроде как является приверженцем следующих идей

  • не плоди сущности без необходимости

  • используй меньше чтобы сделать больше

  • велик C и Rust наследует ему

  • всё преходяще, кроме вечного

Рекомендуется к ознакомлению вкатунам и начинающим пользы ради, а остальными удовольствия для.

Конкретика: Uutils, Fish, Nushell, Ripgrep, Fd, Bat, Eza, Zoxide, Xh, Zellij, Gitui, du-dust, dua, starship, yazi, hyperfine, evil-helix, bacon, cargo-info, fselect, ncspot, rusty-man, delta, ripgrep-all, tokei, wiki-tui, just, mask, mprocs, presenterm, kondo, bob-nvim, rtx, espanso.

Теги:
Всего голосов 3: ↑2 и ↓1+2
Комментарии1

«Первая Форма» заняла третье место в рейтинге no-code платформ CNews

Портал Cnews опубликовал рейтинг и обзор российских no-code платформ. No-code — это способ разработки ПО без написания кода и участия программиста. С помощью встроенного конструктора и шаблонов в таком решении можно реализовать работу с задачами, кастомизировать интерфейс и не только.

При составлении рейтинга эксперты учитывали следующие критерии:

  1. Возможности для автоматизации бизнес-процессов.

  2. Безопасность и управление доступами.

  3. Интерфейс и персонализация.

  4. Интеграция, документы и обработка данных.

  5. Аналитика, отчётность и визуализация.

BPM-система «Первая Форма» заняла в рейтинге третье место. Эксперты высоко оценили её возможности для автоматизации, интерфейс и множество инструментов для работы с данными. Решение позволяет:

  • просматривать и детализировать бизнес-процессы вплоть до полей в документах;

  • расширять библиотеку функций под потребности компании;

  • просматривать логи по сервисам для оперативного решения проблем;

  • конструировать экранные формы под любые задачи;

  • интегрировать любые внешние сервисы по API и не только.

Полный рейтинг доступен на сайте Cnews.

Теги:
Всего голосов 6: ↑5 и ↓1+4
Комментарии0

Опять попробовали React Native и снова решили, что не хотим его внедрять у себя 🧐

Олег и Денис, наши фронтенд-разработчики, рассказали, почему отказались от этого фреймворка, несмотря на то что потратили на погружение в него немало времени. Это был хороший эксперимент, который дал нам много полезных инсайтов. ✍️

Перед нашей командой стояла задача: написать код один раз, собрать под три платформы и встроить в существующие нативные и веб-приложения. Решили поэкспериментировать с React Native: до этого мы «щупали» фреймворк в 2018-м, но делали новое приложение, опыта разработки SDK у нас не было. Отправились гуглить и узнавать, как это сделать. Начали с разработки под Android, потом подключили в веб, и уже финально — iOS, в котором практически всё заработало по дефолту.

В React Native просто начать делать компоненты, но, погрузившись в нативную часть, мы почувствовали себя джунами — запилить поле ввода с нативной валидацией было непросто.

Вот что мы поняли при разработке:

● Обязательно нужна единая дизайн-система под все три платформы под React Native и библиотека компонентов. А ещё — команда из фронтенд и мобильных разработчиков под iOS и Android: одни будут поддерживать часть React Native, которая относится к нативной платформе, другие — писать бизнес-логику и UI.

● React Native может подойти для проектов, которые начинаешь с нуля и нужно охватить мобильные платформы и веб сразу.

Результаты нашего эксперимента

Хоть и ушло на работу с React Native несколько кварталов, мы решили не внедрять его. Было ли нам обидно? Нет, потому что благодаря эксперименту мы:

✔ Закрепили опыт, что фронтенд-разработчики могут писать на React Native.

✔ Поняли, как всё работает изнутри, какие у фреймворка плюсы и минусы.

Будет ли применимо для нас в будущем — время покажет. Возможно, для новых продуктов это рабочая схема, сейчас — экономически неоправданно.

Теги:
Всего голосов 2: ↑1 и ↓10
Комментарии0

Каковы задачи Абстрактной Фабрики?

Новая серия курса «Паттерны и практики написания кода» целиком посвящена разбору достаточно громоздкого паттерна — Абстрактной Фабрики. Вместе с бэкенд-инженером Юрой Афанасьевым на примерах разберем, что это такое и как она реализуется.

Смотреть VK
Смотреть YouTube

Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.

Теги:
Всего голосов 22: ↑22 и ↓0+22
Комментарии0

Дели код на области (scope) - второй принцип. Полный список принципов здесь

Получил задачу, нужно подумать о области реализации. Иерархия областей такая: бизнес домен -> поддомен -> ... -> поддомен -> модуль(пакет) -> функция.

Чем глубже задача в иерархии декомпозиции, тем глубже область реализации в иерархии областей/слоев. Если ты разработчик, твоя зона: поддомен -> модуль(пакет) -> функция. Может быть так:

  • эпик содержит общее описание, покрывает несколько поддоменов, про модули тут ничего не понятно

  • история(сторя) в эпике описывает конкретный вариант использования, покрывает модуль поддомена. Если история покрывает больше одного модуля или поддомена, нужно подумать над декомпозицией.

  • техническая задача из истории - слой вниутри модуля на фронте или модуль на бэке.

Сore domain и всякие другие domain - это лирика-теория для аналитиков. Для разработчика это лишний информационных шум.

Здесь нужно быть внимательным, потому что:

  1. границы субъективны, зависят от понимания смысла, целей, отвественности компонента,

  2. для бэка и фронта границы областей проходят по разному в рамках одной системы:

    • для бэка поддомен->модуль совпадает с сервис->модуль/пакет или микросервис. Сервисы типа BFF и GraphQL - исключения, их можно считать частью глобального слоя контроллеров;

    • для фронта в слое контроллеров UI компоненты имеют свои границы, отличные от границ поддомен->модуль, но в остальных слоях совпадают.

Важно общаться с коллегами при обсуждении задачи, получать обратную связь и добиваться общих критериев для границ.

Допустим, я разработчик бэка. Задача: сделать фасетный и текстовый поиск товаров. Есть сторя с описанием контракта. Тогда моя зона: поддомен -> модуль(пакет) -> функция модуля. Мысли такие:

  1. Поддомен уже понятен - обсудил в процессе декомпозиции эпика с аналитиком. Это будет Каталог. Сделаю его отдельным сервисом.

  2. Модуль примерно понятен: мне нужно сделать фасетный поиск. Скорее всего кроме поиска Каталог-сервис будет выдавать категории, продукты по отдельности и еще что-то. Фасетный поиск - модуль.

  3. Фасетный поиск должен возвращать значения для фасетов и результаты. Кажется, у модуля 2 функции. Может стоит сделать 2 модуля, или это будет 2 интерфейса внутри одного модуля? Решу, когда буду думать над логикой, там станет понятна связанность этих функций. Нужно будет обсудить с коллегами.

На фронте эта же задача выглядит по другому: это будет страница поиска, в ней фасетые фильтры, список товаров, страницы, сортировка. А еще где-то в шапке поле для ввода текста. Тут нет речи о Каталоге, потому что по смыслу это страница и какие-то элементы ввода. Это не страшно. Пусть структура UI компонент соответствует интуитивным ожиданиям фронт разработчиков. Важно, что бы ожидания были у всех одинаковые. Это в слое контроллеров.
В слое приложения лежит логика построения запроса по контракту. Вот здесь появляется Каталог, как поддомен, и модуль фасетного поиска. Позже тут будет модуль категорий и отдельного продукта. Слой контроллеров будет использовать их в разных UI компонентах.

Область и ограниченный контекст - разные вещи. Поэтому мы здесь его не обсуждаем.

Деление на слои и области выглядит как "решётка":

Весь код должен быть раскидан по ячейкам. Рано или поздно у вас появится общий для нескольких модулей код. Он хочет занять несколько ячеек по горизонтали. Скорее всего он выполняет общую служебную функцию внутри слоя. Здесь можно поступить по-разному: вынести в отдельный пакет, модуль с одним слоем, как договоритесь с коллегами.

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

Теги:
Всего голосов 2: ↑1 и ↓10
Комментарии1

О компиляторах.

Если проект не содержит в себе один или несколько проприетарных компиляторов, предназначенных для сборки именно этого проекта - то это не очень большой проект.

Ядро Linux по этому определению может называться очень большим проектом. Под него специально затачивается gcc.

У IBM есть даже специальный язык PL/S, используемый специально для написания операционной системы. Компилятор PL/S не доступен вне IBM.

Теги:
Всего голосов 4: ↑4 и ↓0+5
Комментарии0

Вклад авторов