Выводим Соера на чистую воду разбирая дискуссию с ним про принципы SOLID
Топ перлов
Если ты манки-патчишь объекты, то ты функциональщик.
Ты должен сначала залезть на гору, а потом уже решить надо было тебе сюда или нет.
Если люди по разному воспринимают принцип - это здорово, ведь он подталкивает людей к размышлению.
SOLID позволяет легче (т.е. не задумываясь) принимать не идеальные (т.е. сомнительные) решения.
Упомянутые материалы
Хочу поделиться с вами видением хорошей архитектуры Go проекта, к которой я пришёл на данный момент и также интересно послушать ваши варианты и мнения по данному поводу.
Моё видение:
У нас ядро приложения это сервисный слой (юзкейсы), именно ядро самая основная часть приложения, которая взаимодействует с какой‑то логикой.
Если логика основана на внешних компонентах, то для связи ядра с компонентом(адаптер) и обратно используются абстракции в виде интерфейса(порт). При этом неважно какая связь (от ядра к компоненту или наоборот), внешние компоненты реализуют интерфейсы ядра и не содержат бизнес‑логики, они лишь преобразуют данные к форматам, понятным ядру (интерфейсы также основаны на моделях ядра).
Так как мы не хотим, чтобы логика из ядра уходила во внешние компоненты (по моему мнению, это повлечет переплетение зависимостей и нарушение принципов разделения ответственности), то вся логика должна выполняться на уровне ядра (например, вместо default значений полей в базе, мы создаём модель на уровне ядра, а база служит лишь в качестве хранилища, не выполняя какой‑либо бизнес логики). То есть бизнес‑валидация (инварианты агрегатов) остаётся в ядре, а адаптеры проводят schema‑валидацию (обязательные поля и форматы) до передачи в юзкейсы, тем самым мы избегаем лишних вызовов ядра (при некорректных данных), и не засоряя само ядро валидацией (отличным примером служит то, когда HTTP адаптер валидирует модель до передачи её в юзкейсы).
При этом всё, самое лучше место для интерфейсов (портов) будет отдельный пакет в ядре, к которому могут иметь доступ адаптеры, чтобы проверить реализации контракта (при это адаптеры будут "знать" лишь интерфейсы, а не весь сервисный слой, если бы порты хранились бы в месте использования), а также сами сервисы могут спокойно ссылаться на данные интерфейсы, не подтягивая их с адаптеров (в том случае, если бы мы хранили интерфейсы по месту имплементации).
То есть я считаю идеальной архитектурой для большинства Go проектов, работающих на основании адаптеров (к примеру, REST или gRPC сервис) гексагональную архитектуру с включением подхода DDD.
У меня остались также холиварные вопросы к вам. Как считаете:
Передавать в юзкейсы структуру или поля по отдельности?
Должно ли хранилище, в виде БД например, иметь валидацию данных? Операции по крону? Дефолтные значения полей?
Транзакции: где их начинать/заканчивать?
Когда и где вводить versioning: в HTTP‑уровне, в домене (разные агрегаты) или в репозиториях (Multi‑tenant)?
Должны ли доменные ошибки возвращать rich‑error (с кодом/контекстом) или достаточно обычных error с текстом?
Вы знаете этих людей. Вроде умные, вроде опытные. Говорят правильные слова про 'стратегию', 'масштабируемость', 'долгосрочную перспективу'.
Но почему-то через полгода таких разговоров оказывается, что:
баг, который 'уже почти пофиксили' никуда из прода не девался
фича, которую 'вот-вот запустим' — всё ещё в черновиках
команда уже тихо ненавидит слово 'архитектура'
А техлид? Техлид как будто ничего не замечает.
Как это работает (точнее, не работает)
Слова вместо кода
вместо пулл-реквестов - диаграммы.
демо нет - зато вот вам слайды.
вместо решений 'опять' 'давайте обсудим' (читай: 'я не хочу отвечать').
Бесконечный 'анализ'
'Надо подумать над архитектурой' = 'Я не уверен, но боюсь признаться'
'Это нетривиальная задача' = 'Мне лень разбираться'
Ответственность - это не про нас
Любимый приём - щедро размазать вину:
'Это комплексная проблема' (на самом деле: 'виноваты все, а значит — никто').
Реальный кейс (чтобы было не абстрактно)
В одном проекте (Node.js, если важно) техлид 2 месяца 'прорабатывал подход' к рефакторингу.
Провёл 8 митингов, написал 50 страниц документации.
А потом... уволился.
Оставив после себя:
красивые схемы в Confluence
ни одной строчки кода
команду, которая теперь на рефакторинг смотреть не может
Как понять, что ваш техлид центральная часть системы самообмана?
главный результат его работы - не код, а презентации
коронный вопрос - 'А как мы это будем масштабировать?' (но не сам масштабирует)
после разговора с ним хочется или закодить, или закопать
Что прикажете с этим делать?
тупо запретить 'стратегировать' без кода*
нет пулл-реквеста - нет права говорить про архитектуру.
ввести 'день испанского стыда'
раз в месяц техлид показывает руками, что сделал. Не слайды - код.
Задавать всего один вопрос
'Что конкретно изменится после твоего решения?'
Если ответ начинается со слов 'теоретически....' - это тревога.
Вывод
Хороший техлид — не тот, кто красиво говорит о проблемах.
А тот, кто их решает.
Если ваш 'архитектор' только генерирует документы, но не генерирует код - возможно, он уже ИИ.
P.S. Если после этого текста кто-то узнал своего техлида - это не совпадение
PlantUML | Шаблон для описания таблиц БД
Делюсь с Вами разработанным мною шаблоном, для описания таблицы БД в PlantUML, c элементами автоматизации, описание которых указанно в комментариях.
Всем привет!
Делюсь с Вами разработанным мною шаблоном, для описания таблицы БД в PlantUML, c элементами автоматизации, описание которых указанно в комментариях.
Протестировать можете тут, а сам код шаблона указан ниже:
' Шаблон описания таблицы БД (в PlantUML)
@startuml
skinparam {
' Параметры для управления нижним колонтитулом
FooterFontColor #blue
FooterFontSize 12
' Параметры для управления легендой
LegendBackgroundColor #lightblue
LegendBorderThickness 0
}
' Переменные для ускорения описания таблицы
' - PRIMARY KEY можно указывать как: "$PK"
!$PK=" <size:11><#DarkKhaki:key:></size> (PK) "
' - FOREIGN KEY можно указывать как: "$FK"
!$FK=" <size:11><#DeepPink:key:></size> (FK) "
' - NOT NULL (N-N) можно указывать как: "$NN"
!$NN=" <#LightGreen> **N-N** "
' - NULL можно указывать как: "$N"
!$N = " <#LightCoral> **NULL** "
' Переменные для ускорения добавления информации о таблице
' - Наименование таблицы БД (латинское)
!$table_name="Наимнование_таблицы_БД"
' - Краткое описание таблицы (на русском)
!$description="Краткое описание таблицы (на русском)"
' - Ссылка на описание таблицы (на русском)
!$doc_url="Ссылка"
' Контакты, отображаемые в нижнем колонтитуле
!$autor ="Зимин Антон"
!$email ="antzim_in@ya.ru"
!$telegram="antzim_in"
' Заголовок документа, формируется автоматически из заполненных выше параметров (при необходимости можно удалить)
title $table_name | $description
' Легенда (может быть заполнена любыми необходимыми данными)
' - "right" говорит о том, что легенда будет расположена справа
legend right
**Легенда:**
| Версия документа: | 1.0.0 |
end legend
' Описание таблицы
' - заголовок таблицы, с кликабельной ссылкой (если выгружать в SVG) формируется автоматически
class "[[$doc_url $table_name]] ($description)" as $table_name << (T,#FF5722) >>{
|= PK,FK |= Поле |= Тип |= Обязательность |= Значение\n по умолчанию |= Описание |
| $PK | id | serial | $NN | | Идентификатор записи в таблице |
| $FK | subscriber_id | integer | $NN | | Идентификатор записи в таблице subscriber |
| | electronic_address | varchar(255) | $N | | Электронный адрес \n клиента |
| | created_at | timestampz | $NN | now() | Дата и время создания записи в БД |
| | updated_at | timestampz | $NN | now() | Дата и время обновления записи в БД |
}
' Нижний колонтитул (формируется автоматически из введенных параметров)
footer © $autor | tg: [[https://t.me/$telegram @$telegram]] | email: $email
@enduml
Буду рад Вашим комментариям, отзывам, а если еще и поднимите карму то буду крайне благодарен.
Всем спасибо.
----
Пообщаться со мной можно в telegram: @antzim_in
P.S. Также, если Вам интересно, я веду telegram канал @sa_chulan и буду очень рад Вашей подписке.
Дели код на области (scope) - второй принцип. Полный список принципов здесь
Получил задачу, нужно подумать о области реализации. Иерархия областей такая: бизнес домен -> поддомен -> ... -> поддомен -> модуль(пакет) -> функция.
Чем глубже задача в иерархии декомпозиции, тем глубже область реализации в иерархии областей/слоев. Если ты разработчик, твоя зона: поддомен -> модуль(пакет) -> функция. Может быть так:
эпик содержит общее описание, покрывает несколько поддоменов, про модули тут ничего не понятно
история(сторя) в эпике описывает конкретный вариант использования, покрывает модуль поддомена. Если история покрывает больше одного модуля или поддомена, нужно подумать над декомпозицией.
техническая задача из истории - слой вниутри модуля на фронте или модуль на бэке.
Сore domain и всякие другие domain - это лирика-теория для аналитиков. Для разработчика это лишний информационных шум.
Здесь нужно быть внимательным, потому что:
границы субъективны, зависят от понимания смысла, целей, отвественности компонента,
для бэка и фронта границы областей проходят по разному в рамках одной системы:
для бэка поддомен->модуль совпадает с сервис->модуль/пакет или микросервис. Сервисы типа BFF и GraphQL - исключения, их можно считать частью глобального слоя контроллеров;
для фронта в слое контроллеров UI компоненты имеют свои границы, отличные от границ поддомен->модуль, но в остальных слоях совпадают.
Важно общаться с коллегами при обсуждении задачи, получать обратную связь и добиваться общих критериев для границ.
Допустим, я разработчик бэка. Задача: сделать фасетный и текстовый поиск товаров. Есть сторя с описанием контракта. Тогда моя зона: поддомен -> модуль(пакет) -> функция модуля. Мысли такие:
Поддомен уже понятен - обсудил в процессе декомпозиции эпика с аналитиком. Это будет Каталог. Сделаю его отдельным сервисом.
Модуль примерно понятен: мне нужно сделать фасетный поиск. Скорее всего кроме поиска Каталог-сервис будет выдавать категории, продукты по отдельности и еще что-то. Фасетный поиск - модуль.
Фасетный поиск должен возвращать значения для фасетов и результаты. Кажется, у модуля 2 функции. Может стоит сделать 2 модуля, или это будет 2 интерфейса внутри одного модуля? Решу, когда буду думать над логикой, там станет понятна связанность этих функций. Нужно будет обсудить с коллегами.
На фронте эта же задача выглядит по другому: это будет страница поиска, в ней фасетые фильтры, список товаров, страницы, сортировка. А еще где-то в шапке поле для ввода текста. Тут нет речи о Каталоге, потому что по смыслу это страница и какие-то элементы ввода. Это не страшно. Пусть структура UI компонент соответствует интуитивным ожиданиям фронт разработчиков. Важно, что бы ожидания были у всех одинаковые. Это в слое контроллеров.
В слое приложения лежит логика построения запроса по контракту. Вот здесь появляется Каталог, как поддомен, и модуль фасетного поиска. Позже тут будет модуль категорий и отдельного продукта. Слой контроллеров будет использовать их в разных UI компонентах.
Область и ограниченный контекст - разные вещи. Поэтому мы здесь его не обсуждаем.
Деление на слои и области выглядит как "решётка":
Весь код должен быть раскидан по ячейкам. Рано или поздно у вас появится общий для нескольких модулей код. Он хочет занять несколько ячеек по горизонтали. Скорее всего он выполняет общую служебную функцию внутри слоя. Здесь можно поступить по-разному: вынести в отдельный пакет, модуль с одним слоем, как договоритесь с коллегами.
Как физически организовать решетку и общие пакеты разберемся дальше.
Дели код на слои - первый принцип. Полный список принципов здесь
Я еще не знаю задачу, но уже знаю, что в коде будет 3 слоя: приложение, инфраструктура, контроллеры. Отдельно конфигурация.
Этого достаточно, ведь у меня даже нет задачи. Я начну думать о моделях, адаптерах, объекта‑значениях, когда приступлю обдумыванию бизнес логики и реализации.
Слой приложения «главный». Он устанавливает правила и требования к интерфейсам других слоев. Он никому ничего не должен. Он не знает, как устроены другие слои, и что внутри, потому что он главный. Слой приложения не может требовать от других слоев навыков работы с закрытыми данными. Он не может передать объект с приватными свойствами в другой слой и хотеть, чтобы эти свойства были обработаны.
На фронте слой содержит код, который хранит и управляет состоянием независимо от отображения: сохраняет состояние между переходами по страницам, дает доступ к состоянию из разных шаблонов и т. п.
Для бэка это код, который описывает бизнес правила, отвечает за валидность и целостность данных во время обработки запроса. Такой код может быть реализован по разному:
— как модель, которые хранят состояние пока запрос обрабатывается;
— сервис без состояния
— функция с валидации целостности
Контроллеры — это все, что касается ввода и вывода.
Этот слой обязан знать, что нужно слою приложения, обязан это предоставить в нужном формате. Он не может ничего требовать от слоя приложения, обязан работать с тем, что отдал слой приложения.
На фронте в этот слой попадает всё, что касается взаимодействия с пользователем и обработки событий:
— шаблоны, стили, функции, которые готовят данные для отображения и обрабатывают ввод пользователя
— обработчики событий
— обработчики роутов, потому что роутинг — это интерфейс ввода данных.
— слушатели сокет соединений
На бэке это код, который принимает входящие запросы и отдает ответ, фоновые контроллеры:
— контроллеры gRPC, HTTP,
— слушатели очередей,
— конструкторы ответа, мапперы данных в нужный формат и т. п.
— описание протоколов.
Инфраструктура — помощник слоя приложения помогает получить, передать, сохранить информацию для выполнения бизнес логики.
Инфраструктура
— обязана работать с тем, что отдает слой приложения
— обязана вернуть данные в формате, который требует слой приложения.
Здесь лежат:
— клиенты к хранилищам, другим сервисам, кэшам, очередям и т. п.
— конструкторы запросов к БД, очередям или другим сервисам
— мапперы данных слоя приложения в нужный формат и обратно
Конфигурация — соединяет компоненты из всех слоев в единый модуль, микросервис, приложение. Конфигурация отвечает за передачу настроек и параметров из переменных окружения в компоненты.
Это может быть конфигурация di‑контейнера, место ручного создания компонен. Конфигурация может присутствовать как дополнительные нотации в UI компонентах. Фреймворки и языки имеют разные методы конфигурирования, поэтому конфигурация не является слоем или может быть не явной.
Слой приложения может отсутствовать. Тогда контроллеры и инфраструктура взаимодействуют напрямую. Чтобы сохранить порядок, нужно определить — кто главный. Главным лучше делать того, кто более стабилен.
На фронте слой контроллеров может часто меняться, контракт с бэком более стабилен — инфраструктура главная.
На бэке формат хранения может измениться после MVP, а контракт описан и стабилен — слой контроллеров главный.
Слои зависят друг от друга. Правила организации кода и внедрения зависимостей будут в отдельном посте.
Хочу зафиксировать принципы проектирования, которыми я пользуюсь ежедневно. В этом посте будет обновляемый список, расшифровка каждого принципа - отдельный пост. Это мой личный опыт. Я не претендую на универсальность.
Кто-то решит, что они вредные. Подумайте, прежде чем применять. Кому-то материал покажется очень простым, почти очевидным. Мой опыт показывает, что даже "бывалые" наводят бардак, хотя все всё понимают.
Принципы сформированы на основе практического применения информации из книг:
Эрик Эванс. Предметно-ориентированное проектирование. Структуризация сложных систем.
Вон Вернон. Реализация методов предметно-ориентированного проектирования - DDD.
https://www.infoq.com/minibooks/domain-driven-design-quickly/
Влад Хононов. Изучаем DDD – предметно-ориентированное проектирование.
Роберт Мартин. Чистая архитектура.
В оригиналах некоторые вещи трактуются объемно и широко.
Я про конкретику, практику и про код, поэтому сознательно упростил или выбросил часть информации. Она мешает и запутывает не только новичков, но и опытных разработчиков. Поэтому это не классический DDD или чистая архитектура. Скорее это смешение и личный опыт. Попытаюсь выдавать информацию без "воды".
Погнали:
Полезные расширения для vsCode | просмотр JSON в виде дерева | Json Tree editor
Всем привет, этим постом начинаю серию постов с полезными плагинами для vsCode
🚀 Наименование: Json Tree editor
✍️Описание: расширение VSCode для визуализации данных JSON в виде дерева, с возможность выбора, перемещения и сортировки.
🔗 Ссылка на плагин: https://marketplace.visualstudio.com/items?itemName=GregChamblin.vscode-json-editor
Extension id: GregChamblin.vscode-json-editor
➕Плюсы:
Можно работать с большими файлами json
Есть отдельная кнопка на панели задач
При перетаскивании в дереве элементов, сам json также изменяется онлайн
➖Минусы:
Не выявлено
🚀Делитесь своими плагинами в комментариях.
#vsCode #JSON
Подписывайтесь на меня в телеграмм, там ещё много интересных плагинов @sa_chulan
Выводим Ситника на чистую воду
Топ перлов:
Sync-engine избавляет от однотипного кода по загрузке данных .. он заставляет вас проверять isLoading === true и рисовать крутилку.
Во всех sync-engine используются нормальные стейт менеджеры .. например, nanostore (см. видео с разбором этой библиотеки).
(Я запилил штуку, которая ничего не умеет, но ты можешь поверх этой штуки запилить своих костылей для решения проблем, которые у тебя возникнут из-за моей штуки).
CRDT - это просто лог операций (лог операций - это CmRDT и OT, CvRDT даже близко не лог).
Работать с IndexedDB через скомпилированный под WASM SQLite быстрее, чем напрямую работать с IndexedDB (разве что, если руки заточены под обнимашки).
Упомянутые ссылки:
📦 API for Any(thing)
☝️Возможно ли создать интерфейс для получения любого объекта одинаковым способом?
Продолжаю развивать свою идею архитектуры для 100% инкасуляции, разбития на модули и тестирования всего слоя Model
Хабр
Medium
GitHub
Первая часть доклада теоретическая. В поисках API для любого (Any) объекта
Во второй части доклада практическая реализация 💡
Поделитесь мыслями:
Что думаете про декларативны подход? Описываю результат и получаю нужный объект
Луковая архитектура, и как не заплакать в процессе погружения. Запись митапа
Суть лукового архитектурного подхода (Onion Architecture) — в разделении системы на несколько слоёв, каждый из которых выполняет свою функцию. Такой подход помогает сделать код более чистым и читаемым, обеспечивает удобное разделение бизнес-логики, домена приложения и инфраструктуры.
На внутреннем митапе рассказали, как устроена луковая архитектура, границах применимости и о том, как с пользой начать использовать её в разработке. Затронули теорию и практику: рассмотрели специфику луковой архитектуры на примере конкретного pet-проекта.
Коснулись CQS-CQRS дизайн-паттерна, рассмотрели пайплайн MediatR, реализацию валидаций с FluentValidation, маппинг через AutoMapper, и как организовать сущности доменного слоя.
Остановились на первых двух слоях — Domain.Core и Application. Об устройстве других слоев (Infrastructure и Web API) поговорим на будущих митапах.
Посмотреть запись митапа можно на YouTube или RUTUBE.
P.S. Это запись внутреннего митапа ИТ-команды Сравни — публикуем эпизоды без NDA, но (надеемся) с пользой для внешнего сообщества.
***
Узнавать о выходе наших новых материалов (митапов, лекций, статей), помимо Хабра, можно в тг-канале инженерного сообщества Сравни.
Всем привет!
Расскажу про один поучительный факап из моей практики.
Более 10 лет назад. Стартап. Я на тот момент и СТО, и разработчик в одном лице. Есть задача, в целом понятная. Декомопозирую на микросервисы и подзадачи, начинаю пилить. Дохожу до XML binding - преобразования XML в объекты. Тогда API в основном были XML. Решил погуглить - что есть на рынке. Кроме известного многим JAXB нахожу JiXB. Не известный тогда, тихо умерший сейчас. Читаю описание и нахожу бенчмарк, показывающий что он ... скажем в 1.5 раза быстрее JAXB. Думаю - о, круто, надо брать. Начинаю прикручивать к Spring. Наталкиваюсь на кучу подводных камней - это не работает, документации мало, ошибки не информативные и не гуглятся. В общем убил неделю на прикручивание к проекту одной библиотеки. В итоге все заработало, конечно. А проект не был доведен до работающего состояния и так и не взлетел.
Итоги. До сих пор стыдно за такое решение по следующим причинам:
речь про стартап, т.е. нужно быстро создать работающий прототип, а не исследовать новые технологии
преждевременная оптимизация - данных по требуемому RPS и доступному железу на тот момент у меня не было. Нагрузочное тестирование не проводилось. Стал бы JAXB узким местом - не факт
использовать в промышленной разработке не доказавшие свою зрелость библиотеки - это риск. Очень важны сообщество и работающие без бубна связки, например, Spring+JAXB. А риск должен быть оправдан, а еще должен быть план отката. Не взлетело, сыро - откатываемся на надежный вариант
Всем привет!
Вопрос - где применяется подход DDD?
Аналитика, разработка, тестирование. Конечно архитектура АС, с нее все начинается.
Но это еще не все.
Есть такой класс систем как Data Warehouse (DWH) или аналитическое хранилище данных. В это хранилище попадают данные из всех бизнес-сервисов компании для дальнейшего анализа. Т.об. мы разделяем оперативную БД и аналитическую, снимая лишнюю нагрузку с оперативной БД. Особенность Data Warehouse - технологии обработки и хранения данных отличаются от используемых в системах оперативной обработки данных. Hadoop, Greenplum, ClickHouse... А значит нужны специалисты, которые подготовят хранилище под ваши данные и настроят синхронизацию с оперативной БД. Но эти специалисты не знают ваш домен, в отличие от команды. Плюс они часто становятся "бутылочным горлышком". Плюс структура данных постоянно меняется...
Что делать?
Data Warehouse специалисты готовят инфраструктуру, а за подготовку и синхронизацию данных, актуальность их структуры и способ предоставления этих данных потребителям отвечает бизнес команда. Это же ее bounded context. Подход называется Data Mesh. Вот неплохая статья на эту тему.
P.S. На самом деле DevOps в своем идеальном виде о том же - DevOps инженеры готовят инфраструктуру, а за сборку и деплой отвечает команда.
Всем привет!
Поговорим снова о микросервисах. Я уже писал, почему не стоит делать слишком мелкие микросервисы https://t.me/javaKotlinDevOps/305 (блог в телеге я стал вести сильно раньше, чем на Хабре)
Но встает закономерный вопрос - "сколько вешать в граммах", в смысле - а какого размера должны быть микросервисы?
Обозначим нижний и верхний предел, а для этого придется вспомнить DDD.
Для начала рассмотрим понятие ограниченного контекста (bounded context). Это связанный набор сущностей из реального мира, для наименования которых используется "единый язык" (ubiquitous language) - непротиворечивый набор терминов. Эти сущности описываются в аналитике, тест-кейсах и превращаются в классы в нашем сервисе и в таблицы в БД. Контекстом как правило занимается одна команда - так проще всего поддерживать "единый язык". И за микросервис тоже должна отвечать одна команда. Т.е. ограниченный контекст - это отличный кандидат на микросервис. Но при этом у одной команды может быть несколько микросервисов. И контекст может быть достаточно большим. Т.е. у нас есть верхняя граница микросервиса.
Теперь рассмотрим понятие агрегата - группу сущностей, имеющую уникальный идентификатор, изменение которой производится атомарно. Т.е. агрегат - граница транзакции в БД. А т.к. возможность делегировать управление транзакцией СУБД - это очень крутая штука, то разделять агрегат между разными БД не стоит. При этом один микросервис = одна БД. Поэтому агрегат - нижняя граница микросервиса.
Всем привет!
Недавно посмотрел интересное видео про управление техдолгом https://youtu.be/pvZDcytPU3w
На самом деле видео не про управление техдолгом в целом. Там нет архитектурного техдолга, технологического. Оно про техдолг, возникающий при реализации конкретной фичи - когда появляется TODO в коде.
Речь идет о извечной проблеме разработчика - "сделать все идеально". Но идеально может потребовать дни или даже недели. А у нас Agile, спринты в 2 недели, бизнес ждет свою фичу.
Что предлагается:
не надеяться, что декомпозиция задачи на планировании будет идеальной
если при реализации выясняется, что фичу невозможно сделать в запланированные сроки, а их можно прикинуть исходя из длины спринта, числа задач и их оценки - нужно сделать часть фичи, допускающую продвижение дальше команды. Опять же - декомпозировать сложно, но итеративно это получается лучше.
расставить по коду подробные TODO, рассказать команде что сделано, а что нет и почему, и влить доработку. Т.об. мы гарантировано получаем большую прозрачность. А если правильно удалось определить, что блокер для команды - еще и лучший Lead Time.
далее некий робот сканирует код, находит TODO и делает из них таски в вашем трекере
таски будут оценены на очередном планировании и взяты в работу, возможно другим разработчиком
Самое интересное - для одной и той же задачи пункты 1-5 могут повторяться. Наверное, если это происходит в 5-й раз - стоит детальнее взглянуть на задачу. Похоже она сильно влияет на архитектуру.
Итого - идея мне нравится!
Всем привет!
TDD конечно крутая штука в плане правильного проектирования сервиса. Правильное проектирование - имеется в виду получить публичное Java API, удобное для использования, если не с первого раза, то с меньшим количеством итераций.
Но кажется есть элемент, который можно к этой технике добавить.
Перед тем, как начинать писать первый тест для еще несуществующего класса - выписать как можно больше тестовых кейсов. Не для одного метода или даже класса, а для фичи, которую надо реализовать в текущей итерации. В виде готового набора тестов это сделать сложно, т.к. кода еще нет, поэтому как комментарии.
Что там может быть:
входные данные -> выходные данные
обработка возможных исключений
повторный запуск: идемпотентность, докат или ошибка
параллельный запуск
поведение при различных значениях настроек
поведение при различных настройках кодировки, языка, часового пояса, файловой системы
эффекты из-за отсутствия транзакционности (там где ее нет) ...
И возможно выписывание этих кейсов приведет к изменению дизайна системы. Или к пониманию, что метод\класс\модуль имеет слишком сложную логику. Или в нем много побочных эффектов. Или что есть дублирование логики между классами, которая решается либо их объединением, либо вынесением ее в третий класс. Возможно, стоит изменить границы транзакции.
По сути это формализация процесса проектирования через запись в виде тестовых кейсов. И есть подозрение, что наличие перед глазами набора кейсов сделает процесс написания кода станет более осмысленным.
Всем привет!
Меня зовут Дмитрий. В ИТ я сравнительно недавно, всего 25 лет, из которых последние 22 в банковском секторе (ЦБ, ВТБ, Банк ДОМ.РФ). И за это время я стал смотреть по-другому на многие привычные вещи.
Вот недавно я подумал, что русская народная сказка про царевну-лягушку, это не только про неё. Вы помните: "... нелегко с Кощеем сладить: его смерть ☠️ на конце иглы, та игла в яйце 🥚, яйцо в утке 🦆, утка в зайце 🐇, тот заяц сидит в каменном сундуке 🗃️, а сундук стоит на высоком дубу 🌳, и тот дуб Кощей Бессмертный, как свой глаз, бережёт...".
Будто бы это не и сказка вовсе, а лаконичное описание архитектуры развертывания. Словно «игла» это приложение 🤖, со встроенной killer-feature, при падении которой происходит необратимое последствие - смерть Кощея. Если перевести на бизнесовый - уход ключевого клиента.
А сколько такого в жизни! И Кощей был побеждён лишь потому, что с гео-распределённым решением заморачиваться не стал, или не смог. 🙈
То есть, в переводе на ИТ-шный, намек этой сказки может выглядеть так: хотите чтобы Ваши сервисы жили вечно - не поступайтесь вопросами надежности ИТ архитектуры. 🏛️
А раньше эта сказка мне казалась просто сказкой ... ☀️
Разбор доклада Артёма Арутюняна про Архитектуру и Реактивное Программирование
Топ перлов:
Реактивное программирование - это программирование на событиях.
Реактивность нужна между модулями, а внутри - не нужна.
По одному лишь графу связей можно понять правильно произведена декомпозиция или нет.
Мета: Копилка благодарностей, Новости, Форум
Всем привет!
Попробую немного развить тему с законом Конвея из предыдущего поста. Я достаточно много раз за свою карьеру в разработке сталкивался с упоминанием данного закона. Уже не вспомню где конкретно, но у меня осталось стойкое впечатление, что отношение к нему было как к неизбежности, с которой нужно бороться. Способы борьбы можно вспомнить такие:
корпоративные архитекторы, выравнивающие архитектурные шаблоны
внутренние платформы, обязательные к использованию внутри компании и реализующие единообразно нефункциональные требования
техрадар как способ ограничить технологический стек
единые практики найма и онбординга
корпоративная модель данных — как антипод принципа DDD, когда существует некая общая для организации единственно верная доменная модель...
Так вот — что мне нравится в парадигме DDD, что она говорит — не надо бороться, надо принять как данность, расслабиться и получать удовольствие от своего ограниченного контекста). Ремарка – речь про применение закона в проектировании ПО.