Привет!

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

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

Затем в середине он говорит о выделении кода в слой домена, и с учётом того, что работу с БД он оставляет на уровне выше, то этот код становится чистым и это всё очень начинает напоминать архитектуру функциональное ядро/императивную оболочку.

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

Я снова радуюсь тому, что 90% идей эргономичного подхода разделяют другие разработчики и тому, что я всё ещё вижу потребность в своей работе. На одном из слайдов видно, что мужик объединяет свои базовые кирпичики в некие "фичи", которые очень похожи на мои компоненты, но он не говорит о том как эти фичи находить. Я же - расскажу, покажу и дам практические советы, как эти компоненты-"фичи" находить. На самом деле тизер я уже дал практически год назад. За этот год я эту идею существенно продвинул и опробовал на нескольких проектах.

#talks@ergonomic_code

Привет!

Пока пост про агрегаты варится (настаивается уже), радую вас линко-постами:)

Небольшой пост о том, что будет если слоёную архитектуру перенести на микросервисы.
В монолите, к счастью, операционных проблем нет, но высокая связанность (являющаяся корнем части операционных проблем) - вполне себе есть.

#posts@ergonomic_code #design@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

Привет!

Прочитал Philosophy of Software design, впечатления не однозначные.

Поначалу казалось, что читаю свою книгу, только вместо связанности (copuling) все беды возлагаются на сложность (complexity).

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

Автор также симптомами высокой сложности/связанности называет чрезмерные трудоёмкость изменений и "понимания" софта и невидимые связи.

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

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

Во-первых, автор под модулем понимает в первую очередь класс. И он топит за "глубокие модули" (читай - большие классы). В целом я с ним согласен и это хороший противовес однобокой интерпретации srp - что надо код разбивать на куски, которые делают одну вещь. Но я считаю, что лучших результатов можно добиться, если под модулем понимать пакет - группу классов, за единым интерфейсом. В чём сходимся, так это в том, что пакетироание по слоям ведёт к "поверхностным" модулям в любом понимании.

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

В-третьих, автор утверждает, что код делают очевидным хорошее именование и регулярность (consistency). На мой взгляд они важны, но отсутствие побочных эффектов важнее.

Познавательным для меня оказался блок про комментарии. Автор, вопреки расхожему мнению "вместо того чтобы написать коммент - порефакторьте код", считает, что код без комментариев не может быть хорошим. И рассказывает как писать хорошие комментарии. Тут я с ним теоретически согласен, но пока не готов начать на практике применять его рекомендации.

Ещё интересные тезисы:
1) проблемы дизайна имеют свойство накапливаться. Каждая отдельная проблема выглядит безобидно. Но когда их набирается сотня - развитие проекта парализуется.
2) сложность лучше видна читателю. Если вам на ревью говорят, что код сложно читать, а вы не согласны - лучше привлечь третьего и выбрать вариант, более понятный ему.
3) иногда больше кода - лучше. Например, длинные цыпочки трансформации данных лучше разбавлять присвоением в переменные с промежуточными результатами.
4) при проектировании интерфейсов (в самом широком смысле этого слова) необходимо делать самый распространённый юз кейс максимально простым. А неправильное использование - невозможным.
5) первый шаг к написанию хороших комментариев - использовать в них слова отличные от слов в коде
6) побочный эффект - это любое влияние вызова метода на дальнейшее поведение системы, помимо возврата результата
7) ПО должно проектироваться для упрощения чтения, а не написания

Итого - книга любопытная, содержит много полезной и/или уникальной информации, советую прочитать как минимум для расширения кругозора

#books@ergonomic_code #design@ergonomic_code

Привет!

Наконец-то опубликовал долгожданный (надеюсь:)) пост про агрегаты:)
И это не первоапрельская шутка:)

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

#posts@ergonomic_code #ddd@ergonomic_code #immutable_domain_model@ergonomic_code

эгегей, я включил реакции в канале - не стесняемся, ставим лайки:)

😳😱
Я тут внезапно выяснил, что в идее можно искать зависимости в мавенцентрале не отходя от кассы

#tools@ergonomic_code

Привет!

Прочитал Implementation Patterns Бека.
Я не сторонник императивного ООП, с активным использованием наследования, поэтому опять же не готов занести эту книгу в маст рид.

Но лучше писать код так, как пишет Бек, чем в процедурном стиле с классами.

Что поддерживаю:
1) Код должен хорошо передавать собственный смысл
2) Симметрия и эстетика являются признаками хорошего кода с практической и экономической точки зрения
3) В целом на главах 1-4 у меня было по несколько закладок на каждой странице - в базовых ценностях и философии программирования мы с Беком сходимся
4) Следует избегать использования геттеров и сеттеров
5) Явное разделение рекомендаций для разработки прикладных программ и фреймворков. Всегда надо держать в голове над каким типом кода вы работаете и принимать это во внимание при принятии всех решений. Например, тот же OCP, значительно менее актуален для разработки прикладных програм

#books@ergonomic_code #oop@ergonomic_code

Привет!

Сегодня для меня и Эргономичного подхода знаменательный день - я объявляю о переходе от прототипирования и проверки гипотезы к стабилизации и продуктизации Эргономичного подхода.

Хочу так же постануть об этом на хабре в "Я пиарюсь", но мне не хватает трёх пунктов кармы - накиньте пожалуйста, у кого есть возможность:)

Привет!

Идея наклянчить кармы с треском провалилась, так что пошёл её зарабатывать опубликовав пост об агрегатах на хабре - ставьте лайки, пишите комменты, всё как обычно:)

Привет!

Мне вчера JPA на пару со Spring подложили очередную свинью.
Хотел показать студентам LazyInitializationException и не смог О_О
Забацал типовой пример - транзакционный сервис возвращает сущность с ленивым полем в контроллер, контроллер его достаёт для ДТО и должен был упасть, но, собака, уверено работал.

Полчаса позора спустя я откопал вот такой нежданчик. Который несёт свой собственный набор граблей. Специалисты по JPA, наверное, о нём в курсе, но вдруг тут есть кто-то ещё из танка, как и я.

#spring@ergonomic_code #jpa@ergonomic_code

Привет!

Идея заработать кармы на посте об агрегатах имела оглушительный успех:)
Итоги:
1) +5 кармы
2) +17 подписчиков канала
3) +15 -1 рейтинг поста

Рад приветствовать новых подписчиков, спасибо что присоединились:)

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

#posts@ergonomic_code #ergo_approach@ergonomic_code

Привет!

Я пропустил, что неделю назад вышел Kotlin 1.6.20 с прототипом соблазнительных, но пугающих context receiver-ов.

#kotlin@ergonomic_code #tools@ergonomic_code

Привет!

Мне уже второй раз предлагают писать посты в блоги на хабре:)

Пользуясь случаем, хочу рассказать что большинство постов я пишу при помощи и поддержке Евгении Пельтек. При том Женя помогает мне не только с оформлением мыслей в виде текста, но и со структурированием, а иногда и генерацией мыслей.

Если решите завести блог или написать книгу - рекомендую:)

Привет!
Ох и тяжко мне мне будет с собственной методикой разработки:)
Но надеюсь удастся выплыть на открытости всех материалов.

Источник

Привет!

Итоги поста на хабр об Эргономичном подходе. Неоднозначные.

С одной стороны:
1) рейтинг +1 (и то, подозреваю, от кого-то из друзей или подписчиков - спасибо)
2) карма +0
3) 0 комментариев
4) 12 закладок
Не густо.

С другой стороны:
1) 0 тухлых помидоров
2) 0 указаний на то, что диаграмму эффектов давно за меня придумали
3) +8 подписчиков
4) +1 одно предложение писать в корп. блог
5) +1 человек, написавший мне в личку с доп. вопросами
А вот это уже успех, на мой взгляд:)

Привет!

Если вдруг новость прошла мимо вас: вышла идея 2022.1 советую всем обновиться и ознакомиться с новшествами - есть прикольные

#tools@ergonomic_code

О, откапал, что в спринге можно размеры данных указывать с суффиксами аля 2mb и прокидывать их в DataSize

#tools@ergonomic_code #spring@ergonomic_code

Привет!

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

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

Микро правило распределённого проектирования Фаулера: My First Law of Distributed Object Design: Don't distribute your objects.

Пост DHH на ту же тему.

Для того чтобы идти в зону боли и страданий распределённое программирование нужны веские причины.

#posts@ergonomic_code #why_no_microservices@ergonomic_code

Привет!

Пост с наикрутейшей подборкой принципов и техник написания хороших тестов. Представитель вида постов занесённых в красную книгу - посты которые я целиком рекомендую безо всяких но и оговорок:)

#posts@ergonomic_code #ergo_testing@ergonomic_code