Привет!
Пока пост про агрегаты варится (настаивается уже), радую вас линко-постами:)
Небольшой пост о том, что будет если слоёную архитектуру перенести на микросервисы.
В монолите, к счастью, операционных проблем нет, но высокая связанность (являющаяся корнем части операционных проблем) - вполне себе есть.
#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
Привет!
Мне уже второй раз предлагают писать посты в блоги на хабре:)
Пользуясь случаем, хочу рассказать что большинство постов я пишу при помощи и поддержке Евгении Пельтек. При том Женя помогает мне не только с оформлением мыслей в виде текста, но и со структурированием, а иногда и генерацией мыслей.
Если решите завести блог или написать книгу - рекомендую:)
Мне уже второй раз предлагают писать посты в блоги на хабре:)
Пользуясь случаем, хочу рассказать что большинство постов я пишу при помощи и поддержке Евгении Пельтек. При том Женя помогает мне не только с оформлением мыслей в виде текста, но и со структурированием, а иногда и генерацией мыслей.
Если решите завести блог или написать книгу - рекомендую:)
image_2022-04-22_16-19-19.png
182.2 KB
Привет!
Ох и тяжко мне мне будет с собственной методикой разработки:)
Но надеюсь удастся выплыть на открытости всех материалов.
Источник
Ох и тяжко мне мне будет с собственной методикой разработки:)
Но надеюсь удастся выплыть на открытости всех материалов.
Источник
Привет!
Итоги поста на хабр об Эргономичном подходе. Неоднозначные.
С одной стороны:
1) рейтинг +1 (и то, подозреваю, от кого-то из друзей или подписчиков - спасибо)
2) карма +0
3) 0 комментариев
4) 12 закладок
Не густо.
С другой стороны:
1) 0 тухлых помидоров
2) 0 указаний на то, что диаграмму эффектов давно за меня придумали
3) +8 подписчиков
4) +1 одно предложение писать в корп. блог
5) +1 человек, написавший мне в личку с доп. вопросами
А вот это уже успех, на мой взгляд:)
Итоги поста на хабр об Эргономичном подходе. Неоднозначные.
С одной стороны:
1) рейтинг +1 (и то, подозреваю, от кого-то из друзей или подписчиков - спасибо)
2) карма +0
3) 0 комментариев
4) 12 закладок
Не густо.
С другой стороны:
1) 0 тухлых помидоров
2) 0 указаний на то, что диаграмму эффектов давно за меня придумали
3) +8 подписчиков
4) +1 одно предложение писать в корп. блог
5) +1 человек, написавший мне в личку с доп. вопросами
А вот это уже успех, на мой взгляд:)
👍2
Привет!
Если вдруг новость прошла мимо вас: вышла идея 2022.1 советую всем обновиться и ознакомиться с новшествами - есть прикольные
#tools@ergonomic_code
Если вдруг новость прошла мимо вас: вышла идея 2022.1 советую всем обновиться и ознакомиться с новшествами - есть прикольные
#tools@ergonomic_code
JetBrains
What's New in IntelliJ IDEA
Explore IntelliJ IDEA's latest features and updates to elevate your professional Java and Kotlin development experience.
О, откапал, что в спринге можно размеры данных указывать с суффиксами аля 2mb и прокидывать их в DataSize
#tools@ergonomic_code #spring@ergonomic_code
#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
Я пошёл дописывать пост по диаграмме эффектов, думаю это займёт ещё недели две, так что пока перехожу в режим линко постинга.
И сегодня будет ещё пара линок о том, что микросервисы не должны быть выбором по умолчанию.
Микро правило распределённого проектирования Фаулера: My First Law of Distributed Object Design: Don't distribute your objects.
Пост DHH на ту же тему.
Для того чтобы идти в
#posts@ergonomic_code #why_no_microservices@ergonomic_code
martinfowler.com
bliki: First Law
a bliki entry for First Law
Привет!
Пост с наикрутейшей подборкой принципов и техник написания хороших тестов. Представитель вида постов занесённых в красную книгу - посты которые я целиком рекомендую безо всяких но и оговорок:)
#posts@ergonomic_code #ergo_testing@ergonomic_code
Пост с наикрутейшей подборкой принципов и техник написания хороших тестов. Представитель вида постов занесённых в красную книгу - посты которые я целиком рекомендую безо всяких но и оговорок:)
#posts@ergonomic_code #ergo_testing@ergonomic_code
Philipp Hauer's Blog
Modern Best Practices for Testing in Java
Modern best practices for unit tests and integration tests in Java and in general
👍2
Привет!
Увидев единомышленника в авторе поста о модульном программировании на спринге решил прочитать и его книгу о Чистой архитектуре. С робкой надеждой найти там методику декомпозиции системы на модули.
Но мои надежды не оправдались - как и во всех других книгах эта тема осталась не раскрытой. Всю книгу автор рассматривал структуру реализации одного, спущенного свыше модуля - account. Откуда он взялся, как связан с другими модулями, какой у него интерфейс - это всё осталось за кадром.
На мой взгляд, именно проектирование модулей является самой сложной и самой важной частью создания эргономичных программ (пост о том, как это делаю я - читайте в мае на всех экранах страны). А уш как реализовать эти модули - в эргономичном стиле, по чистой архитектуре или божественным объектом - это детали реализации.
Вообще в книге есть здравые мысли касательно сокрытия реализации модулей - это стоит почитать. Там есть подробная инструкция как нагенерять гору абстракций и бойлерплейта по чистой архитектуре - это можно почитать, если задача требует жёсткой изоляции домена. И есть глава которую лучше пропустить целиком - 7. Testing Architecture Elements. В этой главе собрана подборка рецептов, как попасть в ад - пирамида тестирования, тестирование отдельных классов, активное использование моков.
Вердикт - рекомендую, при условии, что вы понимаете зачем вам нужна Чистая архитектура и это не карго культ. С другой стороны, если в это понимаете, то и книга вряд ли будет содержать что-то новое для вас.
#books@ergonomic_code
Увидев единомышленника в авторе поста о модульном программировании на спринге решил прочитать и его книгу о Чистой архитектуре. С робкой надеждой найти там методику декомпозиции системы на модули.
Но мои надежды не оправдались - как и во всех других книгах эта тема осталась не раскрытой. Всю книгу автор рассматривал структуру реализации одного, спущенного свыше модуля - account. Откуда он взялся, как связан с другими модулями, какой у него интерфейс - это всё осталось за кадром.
На мой взгляд, именно проектирование модулей является самой сложной и самой важной частью создания эргономичных программ (пост о том, как это делаю я - читайте в мае на всех экранах страны). А уш как реализовать эти модули - в эргономичном стиле, по чистой архитектуре или божественным объектом - это детали реализации.
Вообще в книге есть здравые мысли касательно сокрытия реализации модулей - это стоит почитать. Там есть подробная инструкция как нагенерять гору абстракций и бойлерплейта по чистой архитектуре - это можно почитать, если задача требует жёсткой изоляции домена. И есть глава которую лучше пропустить целиком - 7. Testing Architecture Elements. В этой главе собрана подборка рецептов, как попасть в ад - пирамида тестирования, тестирование отдельных классов, активное использование моков.
Вердикт - рекомендую, при условии, что вы понимаете зачем вам нужна Чистая архитектура и это не карго культ. С другой стороны, если в это понимаете, то и книга вряд ли будет содержать что-то новое для вас.
#books@ergonomic_code
reflectoring.io
Structuring and Testing Modules and Layers with Spring Boot
Slice your Spring Boot applications into vertical modules and make them testable in isolation using Spring Boot's testing features.
👍4
Привет!
Прочитал одну из самых крутых книг по разработке информационных систем в своей жизни - Unit Testing Principles, Practices, and Patterns.
Не дайте ввести себя в заблуждение скромному названию - эта книга представляет собой кладезь мудрости и принципов программирования и проектирования в целом. Плюс в ней представлено лучшее из известных мне на данный момент описание прагматичной (без монад) функциональной архитектуры.
В некоторых деталях я с автором не согласен, но в целом эта книга чуть менее, чем полностью раскрывает два из трёх столпов Эргономичного подхода - тестирование на соответствие требованиям и декларативный стиль.
Вердикт - маст рид вне очереди.
Апдейт статуса поста по диаграмме эффектов - первый драфт с подробным описанием примера построения готов. Но предстоит ещё как минимум несколько итераций ревью и вычитки, плюс у меня буквально сегодня ночью появились идеи изменения нотации, поэтому релиз будет недели через две минимум. Стей тюнед, вобщем:)
#books@ergonomic_code #ergo_testing@ergonomic_code #functional_architecture@ergonomic_code
Прочитал одну из самых крутых книг по разработке информационных систем в своей жизни - Unit Testing Principles, Practices, and Patterns.
Не дайте ввести себя в заблуждение скромному названию - эта книга представляет собой кладезь мудрости и принципов программирования и проектирования в целом. Плюс в ней представлено лучшее из известных мне на данный момент описание прагматичной (без монад) функциональной архитектуры.
В некоторых деталях я с автором не согласен, но в целом эта книга чуть менее, чем полностью раскрывает два из трёх столпов Эргономичного подхода - тестирование на соответствие требованиям и декларативный стиль.
Вердикт - маст рид вне очереди.
Апдейт статуса поста по диаграмме эффектов - первый драфт с подробным описанием примера построения готов. Но предстоит ещё как минимум несколько итераций ревью и вычитки, плюс у меня буквально сегодня ночью появились идеи изменения нотации, поэтому релиз будет недели через две минимум. Стей тюнед, вобщем:)
#books@ergonomic_code #ergo_testing@ergonomic_code #functional_architecture@ergonomic_code
👍7