Привет!
Линко пост. "Что почитать архитектору?" по версии какого-то мужика в интернете:)
#posts@ergonomic_code #books@ergonomic_code
Линко пост. "Что почитать архитектору?" по версии какого-то мужика в интернете:)
#posts@ergonomic_code #books@ergonomic_code
The Architect Elevator
The Architect’s Path (Part 2 - Bookshelf)
Growing an architect is different from growing a system. This bookshelf will help.
Привет!
Рубрика "ссылки наших читателей":) Один из читателей канала скинул ссылку на пост, о том какнаши западные коллеги изобретают эргономичный подход:) . Только я буду разбирать первоисточник, т.к. не верю переводчикам.
ТЛДР-мальчик становится мужчиной 5-летний "техлид" начинает понимать суть своего карго культа, нахапанного в интернете, и встаёт на путь к эргономичному подходу:)
А теперь подробнее:)
Во-первых, заголовок явно кликбейтный (или как оно называется?). Я работал с кодом стартапа из долины и постоянно читаю про "зарубежный опыт" - у них там буквально всё тоже самое, один в один.
Во-вторых, это личное мнение одного автора, а не всего "зарубежа".
В-третьих, автор закончил в универ в 17ом году - а я не верю в техлидов с 5 годами опыта (добавка после прочтения поста - и правильно делаю, что неверю)
Но, справедливости ради, у него есть пост про отказ от юнит тестов - плюсик.
> For us, this has reduced the size of a regular feature, such as a new microservice endpoint for updating or reading data, from a total of approximately 25 files down to just 5, that’s an 80% reduction with the majority of code simply having been deleted, all while simultaneously improving code readability
Ох, ну у меня по дефолту на эндпоинт надо вообще 4-5 классов - контроллер, сервис приложения, репоз, агрегат и опциональный сервис домена
А на фоне оверхеда который приносят микросервисы всё что описано позже - экономия на спичках. Из поста не ясно, есть ли к системе требования, обосновывающие применение МС.
> meaning that we want to keep abstractions to a minimum and only introduce complexity when it provides a significant and real benefit
С этим тезисом в целом согласен - поэтому, например, отказался от чисто архитектуры по дефолту и практически никогда не завожу интерфейсы с одной реализацией.
С другой стороны, не опробовав на практике идею отказаться от сервисов-обёрток вокруг репозов, типа:
> each class should only have one reason to change, or, they should only have one job
Чувак не понимает SRP
Но при том понимает, что SRP в его интерпретации - вреден - плюсик
Судя по второй картинке - он юзал заголовочные интерфейсы. Понял что это лишнее - плюсик
Судя по ней же - он поклонник карго культа - использует концепцию repository для read model. Насколько я знаю, не существует альтернативной ДДДшной и распространённой концепции репозитория. А в ДДД репозитории используются только для write-модели.
Судя по ней же, можно предположить что они ещё и юзают Event Sourcing. Опять же из поста не понятно, есть ли в нём необходимость, и если он так же взят потому что модно - то этому парню ещё многое предстоит узнать о преждевременных всяких разных штуках:)
> Introducing various programming design patterns before their benefit is really needed is another common pitfall
вот поэтому техлиды должны иметь хотя бы лет 10 опыта - чтобы успеть наигарться во всякие прикольные штуки.
Я паттернами сейчас практически не пользуюсь.
Плюсик, что понял
> Another pattern used extensively is the Command and Publish-Subscribe Pattern
В целом согласен. Я видел как эвент басы используют для вызова методов в одном процессе - это характеризуется "событиями", названы как указания - SendHttpRequest(dest), ровно одним обработчиком "события", катастрофичными последствиями, если событие не будет обработано мгновенно.
Но если вам над расцепить слабосвязанные компоненты (т.е. вам ок, если обработчик сработает завтра) - то эвент бас один из основных инструментов для этого.
#posts@ergonomic_code #ergo_approach@ergonomic_code
Рубрика "ссылки наших читателей":) Один из читателей канала скинул ссылку на пост, о том как
ТЛДР-
А теперь подробнее:)
Во-первых, заголовок явно кликбейтный (или как оно называется?). Я работал с кодом стартапа из долины и постоянно читаю про "зарубежный опыт" - у них там буквально всё тоже самое, один в один.
Во-вторых, это личное мнение одного автора, а не всего "зарубежа".
В-третьих, автор закончил в универ в 17ом году - а я не верю в техлидов с 5 годами опыта (добавка после прочтения поста - и правильно делаю, что неверю)
Но, справедливости ради, у него есть пост про отказ от юнит тестов - плюсик.
> For us, this has reduced the size of a regular feature, such as a new microservice endpoint for updating or reading data, from a total of approximately 25 files down to just 5, that’s an 80% reduction with the majority of code simply having been deleted, all while simultaneously improving code readability
Ох, ну у меня по дефолту на эндпоинт надо вообще 4-5 классов - контроллер, сервис приложения, репоз, агрегат и опциональный сервис домена
А на фоне оверхеда который приносят микросервисы всё что описано позже - экономия на спичках. Из поста не ясно, есть ли к системе требования, обосновывающие применение МС.
> meaning that we want to keep abstractions to a minimum and only introduce complexity when it provides a significant and real benefit
С этим тезисом в целом согласен - поэтому, например, отказался от чисто архитектуры по дефолту и практически никогда не завожу интерфейсы с одной реализацией.
С другой стороны, не опробовав на практике идею отказаться от сервисов-обёрток вокруг репозов, типа:
fun findById(id: Long) = repo.findbyId(id), я снова начинаю склоняться к тому, что они всё-таки нужны для определения публичного интерфейса модуля. Но тут ещё буду думать.> each class should only have one reason to change, or, they should only have one job
Чувак не понимает SRP
Но при том понимает, что SRP в его интерпретации - вреден - плюсик
Судя по второй картинке - он юзал заголовочные интерфейсы. Понял что это лишнее - плюсик
Судя по ней же - он поклонник карго культа - использует концепцию repository для read model. Насколько я знаю, не существует альтернативной ДДДшной и распространённой концепции репозитория. А в ДДД репозитории используются только для write-модели.
Судя по ней же, можно предположить что они ещё и юзают Event Sourcing. Опять же из поста не понятно, есть ли в нём необходимость, и если он так же взят потому что модно - то этому парню ещё многое предстоит узнать о преждевременных всяких разных штуках:)
> Introducing various programming design patterns before their benefit is really needed is another common pitfall
вот поэтому техлиды должны иметь хотя бы лет 10 опыта - чтобы успеть наигарться во всякие прикольные штуки.
Я паттернами сейчас практически не пользуюсь.
Плюсик, что понял
> Another pattern used extensively is the Command and Publish-Subscribe Pattern
В целом согласен. Я видел как эвент басы используют для вызова методов в одном процессе - это характеризуется "событиями", названы как указания - SendHttpRequest(dest), ровно одним обработчиком "события", катастрофичными последствиями, если событие не будет обработано мгновенно.
Но если вам над расцепить слабосвязанные компоненты (т.е. вам ок, если обработчик сработает завтра) - то эвент бас один из основных инструментов для этого.
#posts@ergonomic_code #ergo_approach@ergonomic_code
Хабр
Зарубежный опыт: как избавиться от 80% кода, увеличить скорость разработки и уменьшить количество ошибок
Мы продолжаем знакомить читателей нашего блога с интересными международными публикациями. Ранее мы перевели материал с практическими советами по обучению для ИТ-специалистов , сегодня же коснемся темы...
> CQRS essentially implies that you have two separate data models ... The huge downside of this pattern is the fact that a whole separate data model needs to be built and maintained
С этим я и согласен и не согласен.
Я применяю разные модели для записи и чтения не столько из соображений производительности (что является следствием), сколько из соображений декомпозиции информации на управляемые кусочки. Но я согласен что это существенный оверхед, оправданность которого весьма спорна и ищу способы уменьшить его.
Так же, http - это одна из самых жёстких системных границ и если что и стоит усилий дизайна - так это хттп интерфейс. Особенно апи опубликовано (список клиентов не известен), либо среди клиентов есть мобильные приложения (которые невозможно обновить без согласия пользователя). И в этом случае использовать единую модель и внутри и в АПИ записи и в АПИ чтения - дорога в ад.
> Low coupling introduced everywhere
Парень забыл про high cohesion - coupling & cohesion всегда идут вместе
> An isolated feature does not need low coupling and interfaces between the elements inside it
Бинго! "isolated feature" по определению является высоко связной - а декаплинг реализации изолированной фичи запрещён конвенцией по правам фичей.
> Also, if you are merely using interfaces to allow mocking in tests, seriously consider switching to a mocking library that allows mocking concrete classes to avoid the overhead.
А вот тут парню ещё предстоит пролить пот и кровь - правильный ответ "следует отказаться от мокирования на уровне классов"
> If you are feeling particularly adventurous, you can go the extra mile and move separate classes into the same file
парень открыл рискованную штуку, рекомендованную в официальном соглашении о кодировании Котлина.
> This is essentially favoring a Vertical Slice Architecture over the more classical Onion Architecture
А вот он дошёл и до концептульной декомпозиции. Только непонятно почему он поместил это в раздел для особо смелых.
> For this reason, we have dropped this kind of unit testing entirely and opted for a completely different approach to automated testing
А вот он таки и дошёл до нормального тестирования.
И того, для того чтобы избавиться от 80% кода наши зарубежные коллеги открыли эргономичный подход:
1) интеграционное тестирование, вместо моков
2) концептуальная декомпозиция, вместо слоёной
3) заявка на декларативный стиль через разделения команд и запросов (CQRS), вместо повсеместного императивного стиля. Но тут нашим молодым западным коллегам ещё предстоит нас догнать, в понимании, что в императивных командах так же надо стремиться выделять декларативный трансформации
#posts@ergonomic_code #ergo_approach@ergonomic_code
С этим я и согласен и не согласен.
Я применяю разные модели для записи и чтения не столько из соображений производительности (что является следствием), сколько из соображений декомпозиции информации на управляемые кусочки. Но я согласен что это существенный оверхед, оправданность которого весьма спорна и ищу способы уменьшить его.
Так же, http - это одна из самых жёстких системных границ и если что и стоит усилий дизайна - так это хттп интерфейс. Особенно апи опубликовано (список клиентов не известен), либо среди клиентов есть мобильные приложения (которые невозможно обновить без согласия пользователя). И в этом случае использовать единую модель и внутри и в АПИ записи и в АПИ чтения - дорога в ад.
> Low coupling introduced everywhere
Парень забыл про high cohesion - coupling & cohesion всегда идут вместе
> An isolated feature does not need low coupling and interfaces between the elements inside it
Бинго! "isolated feature" по определению является высоко связной - а декаплинг реализации изолированной фичи запрещён конвенцией по правам фичей.
> Also, if you are merely using interfaces to allow mocking in tests, seriously consider switching to a mocking library that allows mocking concrete classes to avoid the overhead.
А вот тут парню ещё предстоит пролить пот и кровь - правильный ответ "следует отказаться от мокирования на уровне классов"
> If you are feeling particularly adventurous, you can go the extra mile and move separate classes into the same file
парень открыл рискованную штуку, рекомендованную в официальном соглашении о кодировании Котлина.
> This is essentially favoring a Vertical Slice Architecture over the more classical Onion Architecture
А вот он дошёл и до концептульной декомпозиции. Только непонятно почему он поместил это в раздел для особо смелых.
> For this reason, we have dropped this kind of unit testing entirely and opted for a completely different approach to automated testing
А вот он таки и дошёл до нормального тестирования.
И того, для того чтобы избавиться от 80% кода наши зарубежные коллеги открыли эргономичный подход:
1) интеграционное тестирование, вместо моков
2) концептуальная декомпозиция, вместо слоёной
3) заявка на декларативный стиль через разделения команд и запросов (CQRS), вместо повсеместного императивного стиля. Но тут нашим молодым западным коллегам ещё предстоит нас догнать, в понимании, что в императивных командах так же надо стремиться выделять декларативный трансформации
#posts@ergonomic_code #ergo_approach@ergonomic_code
Tedinski
System boundaries: the focus of design
Efforts must be focused on where the system cannot evolve gracefully.
Привет!
У меня есть две новости:)
1) Я собрал первый черновик поста про агрегаты. Он на 20 минут
2) К нему будет ещё 3 поста-приквела. И потом ещё будет отдельный пост сиквел с примером:)
Поэтому сегодня линка на чужой, но готовый пост по агрегатам:)
#posts@ergonomic_code #ddd@ergonomic_code
У меня есть две новости:)
1) Я собрал первый черновик поста про агрегаты. Он на 20 минут
2) К нему будет ещё 3 поста-приквела. И потом ещё будет отдельный пост сиквел с примером:)
Поэтому сегодня линка на чужой, но готовый пост по агрегатам:)
#posts@ergonomic_code #ddd@ergonomic_code
Alibaba Cloud Community
An In-Depth Understanding of Aggregation in Domain-Driven Design
This article discusses the definition, value, and practices of aggregation in domain-driven design (DDD)
Привет!
Тихой сапой прочитал Next Generation Databases.
В целом хорошее краткое изложение (по сути - 200 страниц с картинками) истории, текущего состояния и будущего систем хранения данных.
Книги уже 7 лет, но на удивление с тех пор ничего особо не поменялось.
Любопытный факт - по мнению автора РСУБД всё ещё лучший выбор для подавляющего большинства приложений.
Хотя архитектура всех основных современных РСУБД, уходящая корнями в System R 70-ых годов изрядно устарела.
О чём пишет Стоунбрейкер в The End of an Architectural Era (It's Time for a Complete Rewrite)
В этой статье он расписывает почему текущие архитектуры устарели и как надо по другому.
"По другому" можно уже сейчас попробовать в его VoltDB и Datomic Рича Хикки.
Это "по другому" среди прочего предполагает переход на хранимые процедуры. Потому что все наши проблемы с ленивой загрузкой и/или монструозными запросами для вытаскивания всех данных в один заход вызваны компромиссным решением разнести код и данные по разным узлам. И кажется подходит время это решение пересмотреть.
При том и VoltDB и Datomic требует, чтобы хранимки были чистыми. Так что ФП - наше всё.
Как вы понимаете, в этом канале я, конечно же, не могу не упомянуть эргономичный подход:)
Эргономичный подход к тестированию в новой реальности будет чувствовать себя прекрасно - для него это будет невидимая низкоуровневая деталь реализации.
Выделение максимума кода в чистое ядро тоже будет как дома в завтрашнем дне - чистое ядро просто уйдёт в хранимки.
А вот с концептуальной декомпозицией системы, кажется, придётся повозиться. Но, справедливости ради, я и в текущей реальности эту часть не довёл до логического завершения.
В общем у нас впереди предстоит много интересного:)
#books@ergonomic_code #databases@ergonomic_code
Тихой сапой прочитал Next Generation Databases.
В целом хорошее краткое изложение (по сути - 200 страниц с картинками) истории, текущего состояния и будущего систем хранения данных.
Книги уже 7 лет, но на удивление с тех пор ничего особо не поменялось.
Любопытный факт - по мнению автора РСУБД всё ещё лучший выбор для подавляющего большинства приложений.
Хотя архитектура всех основных современных РСУБД, уходящая корнями в System R 70-ых годов изрядно устарела.
О чём пишет Стоунбрейкер в The End of an Architectural Era (It's Time for a Complete Rewrite)
В этой статье он расписывает почему текущие архитектуры устарели и как надо по другому.
"По другому" можно уже сейчас попробовать в его VoltDB и Datomic Рича Хикки.
Это "по другому" среди прочего предполагает переход на хранимые процедуры. Потому что все наши проблемы с ленивой загрузкой и/или монструозными запросами для вытаскивания всех данных в один заход вызваны компромиссным решением разнести код и данные по разным узлам. И кажется подходит время это решение пересмотреть.
При том и VoltDB и Datomic требует, чтобы хранимки были чистыми. Так что ФП - наше всё.
Как вы понимаете, в этом канале я, конечно же, не могу не упомянуть эргономичный подход:)
Эргономичный подход к тестированию в новой реальности будет чувствовать себя прекрасно - для него это будет невидимая низкоуровневая деталь реализации.
Выделение максимума кода в чистое ядро тоже будет как дома в завтрашнем дне - чистое ядро просто уйдёт в хранимки.
А вот с концептуальной декомпозицией системы, кажется, придётся повозиться. Но, справедливости ради, я и в текущей реальности эту часть не довёл до логического завершения.
В общем у нас впереди предстоит много интересного:)
#books@ergonomic_code #databases@ergonomic_code
⚡️Spring рекомендует концептуальную декомпозицию!
И называет это разумным способом структурирования приложения
Вы, возможно, скажете, что заводить по пакету на таблицу - это маразм.
И я с вами соглашусь. Надо заводить по пакету на ДДД-агрегат или даже на группу сильно связанных агрегатов. Пост по агрегатам (не считая трёх постов прелюдии:) ) уже наполовину отредактирован:)
#posts@ergonomic_code #ergo_arch@ergonomic_code #spring@ergonomic_code
И называет это разумным способом структурирования приложения
Вы, возможно, скажете, что заводить по пакету на таблицу - это маразм.
И я с вами соглашусь. Надо заводить по пакету на ДДД-агрегат или даже на группу сильно связанных агрегатов. Пост по агрегатам (не считая трёх постов прелюдии:) ) уже наполовину отредактирован:)
#posts@ergonomic_code #ergo_arch@ergonomic_code #spring@ergonomic_code
Привет!
В догонку к понедельничному посту - ещё одна СУБД с похожей архитектурой.
Mnesia - Erlang-овская СУБД, которая объединяет код и данные на одной машине и требует, чтобы функции транзакций были чистыми.
Для Джавы тоже есть встроенная СУБД - MicroStream. Но у них нет транзакций из коробки, хотя они позволяют атомарно сохранять несколько объектов
Ну и кубит тоже в ту же сторону:) Там прямо сейчас есть традиционное АПИ с begin-commit-rollback, но я его выпилю, как руки дойдут.
#ergo_persistance@ergonomic_code
В догонку к понедельничному посту - ещё одна СУБД с похожей архитектурой.
Mnesia - Erlang-овская СУБД, которая объединяет код и данные на одной машине и требует, чтобы функции транзакций были чистыми.
Для Джавы тоже есть встроенная СУБД - MicroStream. Но у них нет транзакций из коробки, хотя они позволяют атомарно сохранять несколько объектов
Ну и кубит тоже в ту же сторону:) Там прямо сейчас есть традиционное АПИ с begin-commit-rollback, но я его выпилю, как руки дойдут.
#ergo_persistance@ergonomic_code
MicroStream is now EclipseStore: Databaseless Java-Native Persistence for Microservices, Serverless, Mobile & Edge
Home
EclipseStore is a breakthrough Java-native persistence layer built for cloud-native microservices and serverless systems. EclipseStore is also great for big monoliths and runs on Android mobile, edge, and embedded devices.
Привет!
Мужик рассказывает про подход к разработке, очень близкий к эргономичному
Начинает он с того, что пинает слоёную архитектуру и в замен предлагает архитектуру вертикальной нарезки. Это очень похоже на то, что я называю концептуальной декомпозицией, хотя он там пляшет исключительно от операций системы, а я ищу нарезку инакпсулирующую состояние системы в отдельных модулях - я год спустя вернулся к переосмысленной идеи компонентов.
Затем в середине он говорит о выделении кода в слой домена, и с учётом того, что работу с БД он оставляет на уровне выше, то этот код становится чистым и это всё очень начинает напоминать архитектуру функциональное ядро/императивную оболочку.
И в конце он коротенько говорит о тестировании через парадный вход и окружении максимально приближенное к продовому - это очень напоминает то, что я называю детроитской школой тестирования.
Я снова радуюсь тому, что 90% идей эргономичного подхода разделяют другие разработчики и тому, что я всё ещё вижу потребность в своей работе. На одном из слайдов видно, что мужик объединяет свои базовые кирпичики в некие "фичи", которые очень похожи на мои компоненты, но он не говорит о том как эти фичи находить. Я же - расскажу, покажу и дам практические советы, как эти компоненты-"фичи" находить. На самом деле тизер я уже дал практически год назад. За этот год я эту идею существенно продвинул и опробовал на нескольких проектах.
#talks@ergonomic_code
Мужик рассказывает про подход к разработке, очень близкий к эргономичному
Начинает он с того, что пинает слоёную архитектуру и в замен предлагает архитектуру вертикальной нарезки. Это очень похоже на то, что я называю концептуальной декомпозицией, хотя он там пляшет исключительно от операций системы, а я ищу нарезку инакпсулирующую состояние системы в отдельных модулях - я год спустя вернулся к переосмысленной идеи компонентов.
Затем в середине он говорит о выделении кода в слой домена, и с учётом того, что работу с БД он оставляет на уровне выше, то этот код становится чистым и это всё очень начинает напоминать архитектуру функциональное ядро/императивную оболочку.
И в конце он коротенько говорит о тестировании через парадный вход и окружении максимально приближенное к продовому - это очень напоминает то, что я называю детроитской школой тестирования.
Я снова радуюсь тому, что 90% идей эргономичного подхода разделяют другие разработчики и тому, что я всё ещё вижу потребность в своей работе. На одном из слайдов видно, что мужик объединяет свои базовые кирпичики в некие "фичи", которые очень похожи на мои компоненты, но он не говорит о том как эти фичи находить. Я же - расскажу, покажу и дам практические советы, как эти компоненты-"фичи" находить. На самом деле тизер я уже дал практически год назад. За этот год я эту идею существенно продвинул и опробовал на нескольких проектах.
#talks@ergonomic_code
YouTube
Vertical Slice Architecture - Jimmy Bogard
Don't forget to check out our links below!
https://ndcporto.com/
https://ndcconferences.com/
Moving from a layered architecture to a vertical slice architecture can be a bit daunting. We remove abstractions, complex structures, and focus building on the…
https://ndcporto.com/
https://ndcconferences.com/
Moving from a layered architecture to a vertical slice architecture can be a bit daunting. We remove abstractions, complex structures, and focus building on the…
Привет!
Пока пост про агрегаты варится (настаивается уже), радую вас линко-постами:)
Небольшой пост о том, что будет если слоёную архитектуру перенести на микросервисы.
В монолите, к счастью, операционных проблем нет, но высокая связанность (являющаяся корнем части операционных проблем) - вполне себе есть.
#posts@ergonomic_code #design@ergonomic_code
Пока пост про агрегаты варится (настаивается уже), радую вас линко-постами:)
Небольшой пост о том, что будет если слоёную архитектуру перенести на микросервисы.
В монолите, к счастью, операционных проблем нет, но высокая связанность (являющаяся корнем части операционных проблем) - вполне себе есть.
#posts@ergonomic_code #design@ergonomic_code
Michaelnygard
The Entity Service Antipattern - Wide Awake Developers
In my last post I talked about the need to keep things separated once they've been decoupled. Let's look at one of the ways this breaks down: entity services. If a pattern is a solution to a problem in a context, what is an antipattern? An antipattern is…
Привет!
Давно двигаю тезис, что типовой подход к разработке с примитивными сущностями и всей логикой в сервисах - это процедурное программирование, доказавшее свою неэффективность 50 лет назад.
И вот наткнулся на этот же тезис у Фаулера в статье об анемичной доменной модели:
> The anemic domain model is really just a procedural style design, exactly the kind of thing that object bigots like me (and Eric) have been fighting since our early days in Smalltalk. What's worse, many people think that anemic objects are real objects, and thus completely miss the point of what object-oriented design is all about.
#posts@ergonomic_code #oop@ergonomic_code
Давно двигаю тезис, что типовой подход к разработке с примитивными сущностями и всей логикой в сервисах - это процедурное программирование, доказавшее свою неэффективность 50 лет назад.
И вот наткнулся на этот же тезис у Фаулера в статье об анемичной доменной модели:
> The anemic domain model is really just a procedural style design, exactly the kind of thing that object bigots like me (and Eric) have been fighting since our early days in Smalltalk. What's worse, many people think that anemic objects are real objects, and thus completely miss the point of what object-oriented design is all about.
#posts@ergonomic_code #oop@ergonomic_code
martinfowler.com
bliki: Anemic Domain Model
If you use an object-oriented domain model, and you don't put behavior in your objects, you're missing out on most of the benefits of that pattern.
Привет!
Прочитал Philosophy of Software design, впечатления не однозначные.
Поначалу казалось, что читаю свою книгу, только вместо связанности (copuling) все беды возлагаются на сложность (complexity).
Автор также считает, что задача декомпозиции программ одновременно является наиболее важной для создания поддерживаемых программ и наименее покрытой обучающими материалами и курсами.
Автор также симптомами высокой сложности/связанности называет чрезмерные трудоёмкость изменений и "понимания" софта и невидимые связи.
Автор также говорит о тактическом (самое быстрее решение задачи) и стратегическом (самое поддерживаемое решение задачи) программировании и так же утверждает, что стратегическое программирование начинает окупаться буквально через несколько месяцев. А экономия на дизайне не позволить зарелизить даже первую версию проекта быстрее, если на её разработку надо 4-6 месяцев.
Но как только дело доходит до мяса, начинает обнаруживаться расхождения во взглядах.
Во-первых, автор под модулем понимает в первую очередь класс. И он топит за "глубокие модули" (читай - большие классы). В целом я с ним согласен и это хороший противовес однобокой интерпретации srp - что надо код разбивать на куски, которые делают одну вещь. Но я считаю, что лучших результатов можно добиться, если под модулем понимать пакет - группу классов, за единым интерфейсом. В чём сходимся, так это в том, что пакетироание по слоям ведёт к "поверхностным" модулям в любом понимании.
Во-вторых, автор совершенно ничего не говорит о состоянии и побочных эффектов. А на мой взгляд именно они являются основным источниками сложности понимания кода и скрытых свзязей.
В-третьих, автор утверждает, что код делают очевидным хорошее именование и регулярность (consistency). На мой взгляд они важны, но отсутствие побочных эффектов важнее.
Познавательным для меня оказался блок про комментарии. Автор, вопреки расхожему мнению "вместо того чтобы написать коммент - порефакторьте код", считает, что код без комментариев не может быть хорошим. И рассказывает как писать хорошие комментарии. Тут я с ним теоретически согласен, но пока не готов начать на практике применять его рекомендации.
Ещё интересные тезисы:
1) проблемы дизайна имеют свойство накапливаться. Каждая отдельная проблема выглядит безобидно. Но когда их набирается сотня - развитие проекта парализуется.
2) сложность лучше видна читателю. Если вам на ревью говорят, что код сложно читать, а вы не согласны - лучше привлечь третьего и выбрать вариант, более понятный ему.
3) иногда больше кода - лучше. Например, длинные цыпочки трансформации данных лучше разбавлять присвоением в переменные с промежуточными результатами.
4) при проектировании интерфейсов (в самом широком смысле этого слова) необходимо делать самый распространённый юз кейс максимально простым. А неправильное использование - невозможным.
5) первый шаг к написанию хороших комментариев - использовать в них слова отличные от слов в коде
6) побочный эффект - это любое влияние вызова метода на дальнейшее поведение системы, помимо возврата результата
7) ПО должно проектироваться для упрощения чтения, а не написания
Итого - книга любопытная, содержит много полезной и/или уникальной информации, советую прочитать как минимум для расширения кругозора
#books@ergonomic_code #design@ergonomic_code
Прочитал Philosophy of Software design, впечатления не однозначные.
Поначалу казалось, что читаю свою книгу, только вместо связанности (copuling) все беды возлагаются на сложность (complexity).
Автор также считает, что задача декомпозиции программ одновременно является наиболее важной для создания поддерживаемых программ и наименее покрытой обучающими материалами и курсами.
Автор также симптомами высокой сложности/связанности называет чрезмерные трудоёмкость изменений и "понимания" софта и невидимые связи.
Автор также говорит о тактическом (самое быстрее решение задачи) и стратегическом (самое поддерживаемое решение задачи) программировании и так же утверждает, что стратегическое программирование начинает окупаться буквально через несколько месяцев. А экономия на дизайне не позволить зарелизить даже первую версию проекта быстрее, если на её разработку надо 4-6 месяцев.
Но как только дело доходит до мяса, начинает обнаруживаться расхождения во взглядах.
Во-первых, автор под модулем понимает в первую очередь класс. И он топит за "глубокие модули" (читай - большие классы). В целом я с ним согласен и это хороший противовес однобокой интерпретации srp - что надо код разбивать на куски, которые делают одну вещь. Но я считаю, что лучших результатов можно добиться, если под модулем понимать пакет - группу классов, за единым интерфейсом. В чём сходимся, так это в том, что пакетироание по слоям ведёт к "поверхностным" модулям в любом понимании.
Во-вторых, автор совершенно ничего не говорит о состоянии и побочных эффектов. А на мой взгляд именно они являются основным источниками сложности понимания кода и скрытых свзязей.
В-третьих, автор утверждает, что код делают очевидным хорошее именование и регулярность (consistency). На мой взгляд они важны, но отсутствие побочных эффектов важнее.
Познавательным для меня оказался блок про комментарии. Автор, вопреки расхожему мнению "вместо того чтобы написать коммент - порефакторьте код", считает, что код без комментариев не может быть хорошим. И рассказывает как писать хорошие комментарии. Тут я с ним теоретически согласен, но пока не готов начать на практике применять его рекомендации.
Ещё интересные тезисы:
1) проблемы дизайна имеют свойство накапливаться. Каждая отдельная проблема выглядит безобидно. Но когда их набирается сотня - развитие проекта парализуется.
2) сложность лучше видна читателю. Если вам на ревью говорят, что код сложно читать, а вы не согласны - лучше привлечь третьего и выбрать вариант, более понятный ему.
3) иногда больше кода - лучше. Например, длинные цыпочки трансформации данных лучше разбавлять присвоением в переменные с промежуточными результатами.
4) при проектировании интерфейсов (в самом широком смысле этого слова) необходимо делать самый распространённый юз кейс максимально простым. А неправильное использование - невозможным.
5) первый шаг к написанию хороших комментариев - использовать в них слова отличные от слов в коде
6) побочный эффект - это любое влияние вызова метода на дальнейшее поведение системы, помимо возврата результата
7) ПО должно проектироваться для упрощения чтения, а не написания
Итого - книга любопытная, содержит много полезной и/или уникальной информации, советую прочитать как минимум для расширения кругозора
#books@ergonomic_code #design@ergonomic_code
👍1
Привет!
Наконец-то опубликовал долгожданный (надеюсь:)) пост про агрегаты:)
И это не первоапрельская шутка:)
Как я и говорил, этот пост идёт третьим в серии и первые два ещё не готовы. Но в последние полтора месяца писательство у меня идёт со скрипом. Поэтому когда я допишу эти посты я не знаю и чтобы готовый материал не гнил я решил опубликовать его сейчас. На всякий случай добавил ссылки на черновики постов-приквелов, но они ещё совсем сырые.
#posts@ergonomic_code #ddd@ergonomic_code #immutable_domain_model@ergonomic_code
Наконец-то опубликовал долгожданный (надеюсь:)) пост про агрегаты:)
И это не первоапрельская шутка:)
Как я и говорил, этот пост идёт третьим в серии и первые два ещё не готовы. Но в последние полтора месяца писательство у меня идёт со скрипом. Поэтому когда я допишу эти посты я не знаю и чтобы готовый материал не гнил я решил опубликовать его сейчас. На всякий случай добавил ссылки на черновики постов-приквелов, но они ещё совсем сырые.
#posts@ergonomic_code #ddd@ergonomic_code #immutable_domain_model@ergonomic_code
Алексей Жидков
Агрегаты - Алексей Жидков
В основе поддерживаемых информационных систем лежат агрегаты. В этом посте я расскажу что такое агрегат, как его проектировать и какие ошибки проектирования агрегатов встречаются чаще всего
🔥10
эгегей, я включил реакции в канале - не стесняемся, ставим лайки:)
👍8❤2👏2🔥1🤩1
image_2022-04-01_19-02-02.png
85.2 KB
😳😱
Я тут внезапно выяснил, что в идее можно искать зависимости в мавенцентрале не отходя от кассы
#tools@ergonomic_code
Я тут внезапно выяснил, что в идее можно искать зависимости в мавенцентрале не отходя от кассы
#tools@ergonomic_code
👍2
Привет!
Прочитал Implementation Patterns Бека.
Я не сторонник императивного ООП, с активным использованием наследования, поэтому опять же не готов занести эту книгу в маст рид.
Но лучше писать код так, как пишет Бек, чем в процедурном стиле с классами.
Что поддерживаю:
1) Код должен хорошо передавать собственный смысл
2) Симметрия и эстетика являются признаками хорошего кода с практической и экономической точки зрения
3) В целом на главах 1-4 у меня было по несколько закладок на каждой странице - в базовых ценностях и философии программирования мы с Беком сходимся
4) Следует избегать использования геттеров и сеттеров
5) Явное разделение рекомендаций для разработки прикладных программ и фреймворков. Всегда надо держать в голове над каким типом кода вы работаете и принимать это во внимание при принятии всех решений. Например, тот же OCP, значительно менее актуален для разработки прикладных програм
#books@ergonomic_code #oop@ergonomic_code
Прочитал Implementation Patterns Бека.
Я не сторонник императивного ООП, с активным использованием наследования, поэтому опять же не готов занести эту книгу в маст рид.
Но лучше писать код так, как пишет Бек, чем в процедурном стиле с классами.
Что поддерживаю:
1) Код должен хорошо передавать собственный смысл
2) Симметрия и эстетика являются признаками хорошего кода с практической и экономической точки зрения
3) В целом на главах 1-4 у меня было по несколько закладок на каждой странице - в базовых ценностях и философии программирования мы с Беком сходимся
4) Следует избегать использования геттеров и сеттеров
5) Явное разделение рекомендаций для разработки прикладных программ и фреймворков. Всегда надо держать в голове над каким типом кода вы работаете и принимать это во внимание при принятии всех решений. Например, тот же OCP, значительно менее актуален для разработки прикладных програм
#books@ergonomic_code #oop@ergonomic_code
Привет!
Сегодня для меня и Эргономичного подхода знаменательный день - я объявляю о переходе от прототипирования и проверки гипотезы к стабилизации и продуктизации Эргономичного подхода.
Хочу так же постануть об этом на хабре в "Я пиарюсь", но мне не хватает трёх пунктов кармы - накиньте пожалуйста, у кого есть возможность:)
Сегодня для меня и Эргономичного подхода знаменательный день - я объявляю о переходе от прототипирования и проверки гипотезы к стабилизации и продуктизации Эргономичного подхода.
Хочу так же постануть об этом на хабре в "Я пиарюсь", но мне не хватает трёх пунктов кармы - накиньте пожалуйста, у кого есть возможность:)
Алексей Жидков
Эргономичный подход v1.0M1 - Алексей Жидков
Или как создавать программы, которые всем стейкхолдерам приносят больше положительных эмоций
🔥3🎉3
Привет!
Идея наклянчить кармы с треском провалилась, так что пошёл её зарабатывать опубликовав пост об агрегатах на хабре - ставьте лайки, пишите комменты, всё как обычно:)
Идея наклянчить кармы с треском провалилась, так что пошёл её зарабатывать опубликовав пост об агрегатах на хабре - ставьте лайки, пишите комменты, всё как обычно:)
Хабр
Агрегаты
Этот материал является кросс-постом из моего блога Следить за обновлениями блога можно в моём канале: Эргономичный код Введение Я считаю, что именно агрегаты из Domain-Driven Design лежат в основе...
👍1
Привет!
Мне вчера JPA на пару со Spring подложили очередную свинью.
Хотел показать студентам LazyInitializationException и не смог О_О
Забацал типовой пример - транзакционный сервис возвращает сущность с ленивым полем в контроллер, контроллер его достаёт для ДТО и должен был упасть, но, собака, уверено работал.
Полчаса позора спустя я откопал вот такой нежданчик. Который несёт свой собственный набор граблей. Специалисты по JPA, наверное, о нём в курсе, но вдруг тут есть кто-то ещё из танка, как и я.
#spring@ergonomic_code #jpa@ergonomic_code
Мне вчера JPA на пару со Spring подложили очередную свинью.
Хотел показать студентам LazyInitializationException и не смог О_О
Забацал типовой пример - транзакционный сервис возвращает сущность с ленивым полем в контроллер, контроллер его достаёт для ДТО и должен был упасть, но, собака, уверено работал.
Полчаса позора спустя я откопал вот такой нежданчик. Который несёт свой собственный набор граблей. Специалисты по JPA, наверное, о нём в курсе, но вдруг тут есть кто-то ещё из танка, как и я.
#spring@ergonomic_code #jpa@ergonomic_code
Хабр
Open Session In View в Spring Boot: Скрытая угроза
Все здесь правы, каждый по-своему, и, следовательно, все здесь не правы. "Сказка о Тройке" (А. и Б. Стругацкие)Если вы используете Spring Data JPA, то после обно...
🔥4
Привет!
Идея заработать кармы на посте об агрегатах имела оглушительный успех:)
Итоги:
1) +5 кармы
2) +17 подписчиков канала
3) +15 -1 рейтинг поста
Рад приветствовать новых подписчиков, спасибо что присоединились:)
А теперь к главному - я запулил пост на хабр об эргономичном подходе. Ставьте лайки, пишите коменты, делайте репосты, буду благодарен за любую поддержку.
#posts@ergonomic_code #ergo_approach@ergonomic_code
Идея заработать кармы на посте об агрегатах имела оглушительный успех:)
Итоги:
1) +5 кармы
2) +17 подписчиков канала
3) +15 -1 рейтинг поста
Рад приветствовать новых подписчиков, спасибо что присоединились:)
А теперь к главному - я запулил пост на хабр об эргономичном подходе. Ставьте лайки, пишите коменты, делайте репосты, буду благодарен за любую поддержку.
#posts@ergonomic_code #ergo_approach@ergonomic_code
Хабр
Эргономичный подход к разработке информационных систем v1.0M1
Этот материал является кросс-постом из моего блога Следить за обновлениями блога можно в моём канале: Эргономичный код Предисловие Работу над Эргономичным подходом я начал весной 2020 года. Причиной...
👍4🔥1
Привет!
Я пропустил, что неделю назад вышел Kotlin 1.6.20 с прототипом соблазнительных, но пугающих context receiver-ов.
#kotlin@ergonomic_code #tools@ergonomic_code
Я пропустил, что неделю назад вышел Kotlin 1.6.20 с прототипом соблазнительных, но пугающих context receiver-ов.
#kotlin@ergonomic_code #tools@ergonomic_code
Kotlin Help
What's new in Kotlin 1.6.20 | Kotlin
Привет!
Мне уже второй раз предлагают писать посты в блоги на хабре:)
Пользуясь случаем, хочу рассказать что большинство постов я пишу при помощи и поддержке Евгении Пельтек. При том Женя помогает мне не только с оформлением мыслей в виде текста, но и со структурированием, а иногда и генерацией мыслей.
Если решите завести блог или написать книгу - рекомендую:)
Мне уже второй раз предлагают писать посты в блоги на хабре:)
Пользуясь случаем, хочу рассказать что большинство постов я пишу при помощи и поддержке Евгении Пельтек. При том Женя помогает мне не только с оформлением мыслей в виде текста, но и со структурированием, а иногда и генерацией мыслей.
Если решите завести блог или написать книгу - рекомендую:)