Привет!
Жутиков вам в утреннюю ленту.
В текущем мастере Хибера 1.3М строк Java-кода:
#whynotjpa@ergonomic_code #tools@ergonomic_code
Жутиков вам в утреннюю ленту.
В текущем мастере Хибера 1.3М строк Java-кода:
atomic-armchair : ~/tmp > git clone https://github.com/hibernate/hibernate-orm.git
Cloning into 'hibernate-orm'...
remote: Enumerating objects: 763047, done.
remote: Counting objects: 100% (333/333), done.
remote: Compressing objects: 100% (162/162), done.
remote: Total 763047 (delta 243), reused 171 (delta 171), pack-reused 762714 (from 2)
Receiving objects: 100% (763047/763047), 281.04 MiB | 2.20 MiB/s, done.
Resolving deltas: 100% (471253/471253), done.
atomic-armchair : ~/tmp > cloc hibernate-orm/
17126 text files.
17002 unique files.
204 files ignored.
github.com/AlDanial/cloc v 2.04 T=25.71 s (661.3 files/s, 77566.1 lines/s)
-------------------------------------------------------------------------------
Language files blank comment code
-------------------------------------------------------------------------------
Java 15603 266991 243111 1348435
AsciiDoc 128 10432 660 32337
XML 816 4135 4441 25428
XSD 21 3912 1455 22496
SVG 29 11 28 6548
Gradle 41 788 436 3426
CSS 7 176 184 3164
SQL 218 401 346 2981
ANTLR Grammar 8 414 698 1760
Bourne Shell 13 222 427 1599
Text 46 322 0 1354
Properties 34 179 257 952
DTD 2 143 185 805
YAML 6 37 77 588
Groovy 5 75 63 367
Markdown 6 114 6 302
HTML 2 24 4 256
Maven 7 33 24 225
DOS Batch 2 42 4 138
Dockerfile 5 20 145 75
JavaScript 1 6 0 52
Kotlin 2 6 4 25
-------------------------------------------------------------------------------
SUM: 17002 288483 252555 1453313
-------------------------------------------------------------------------------
#whynotjpa@ergonomic_code #tools@ergonomic_code
Привет!
Запулил статью про sql на хабр и читатели как всегда порадовали - спустя 9 минут после публикации 20 минутной статьи, какой-то скорочитатель заминусил за низкий технический уровень🤦♂️😂
Запулил статью про sql на хабр и читатели как всегда порадовали - спустя 9 минут после публикации 20 минутной статьи, какой-то скорочитатель заминусил за низкий технический уровень🤦♂️😂
Эргономичный код
Привет! Запулил статью про sql на хабр и читатели как всегда порадовали - спустя 9 минут после публикации 20 минутной статьи, какой-то скорочитатель заминусил за низкий технический уровень🤦♂️😂
Кстати, я с предыдущим постом про Чистую архитектуру на 50+ рейтинга попал в программу поддержки авторов и теперь мне при рейтинге поста от 30 накидывают по 3 т.р., а от 50 - по 5 т.р. - так что можете поддержать меня и канал простым кликом:) И вам не сложно, и мне приятно:)
Кое-как с третьей попытки вымучил раздел "Зачем?" главы "Эргономичный подход".
Купили бы книгу с такой постановкой проблемы?:)
———
2.1. Зачем?
Так вышло, что все 20 лет своей карьеры я занимался разработкой "простых" CRUD-приложений.
Они всю свою жизнь (в некоторых случаях - десятилетнюю) хранили данные в реляционной СУБД одного вендора (один раз требовалась поддержка двух вендоров - PostgreSQL и Oracle). Они всю свою жизнь принимали запросы по HTTP и возвращали ответы в формате JSON.
Церемонии Чистой Архитектуры в таких приложениях только мешали.
И в них не было настолько сложной бизнес-логики, чтобы бизнес видел ценность в проведении сессий эвентштроминга с участием экспертов предметной области и трате времени на создание вездесущего языка (Ubiquitous language) и карты контекстов. И они не обслуживали разные отделы бизнеса, с собственными процессами, правилами и языком.
Идея применения DDD в таких приложения умирала на этапе "продажи" бизнесу и команде.
Но назвать эти приложения простыми у меня язык не поворачивается.
Потому что они хранили информацию о десятках и сотнях типов сущностей. У которых были десятки, а иногда и сотни полей.
А "простые" CREATE/UPDATE/DELETE операции затрагивали десятки таблиц, делали пару-тройку походов во внешние сервисы по HTTP, публиковали по сообщению в пару разных брокеров очередей и отправляли емейл "на сладкое".
Сложность этих систем заключалась не в бизнес-правилах и инвариантах, на которых фокусируются Чистая Архитектура и DDD, а в модели данных и взаимодействиях с внешними системами.
И разработчики таких систем оставались без руководства, как проектировать модель данных и эффекты (поведение). И в отсутствии каких-либо ограничений, разработчики шли по пути наименьшего сопротивления и порождали такие модели данных:
Картинка №2
и такие графы вызовов методов:
Картинка №1
Диаграммы выше - это диаграммы построенные по коду реального проекта, с которым мне довелось работать. И я вам скажу, что работать с этим кодом было удовольствием для редкостных гурманов.
На самом деле именно этот проект послужил для меня толчком к поиску способа писать код по другому, который в итоге привёл к созданию Эргономичного подхода и написанию этой книги.
Я создал Эргономичный подход для того, чтобы я сам и другие разработчики "простых" CRUD-приложений могли проектировать сложные модели данных без экспертов предметной области и организовывать код поведения так, чтобы эффекты его работы были очевидными, а задачи по его оптимизации, исправлению и рефакторингу не превращались в детективные триллеры.
#ergo_book@ergonomic_code
Купили бы книгу с такой постановкой проблемы?:)
———
2.1. Зачем?
Так вышло, что все 20 лет своей карьеры я занимался разработкой "простых" CRUD-приложений.
Они всю свою жизнь (в некоторых случаях - десятилетнюю) хранили данные в реляционной СУБД одного вендора (один раз требовалась поддержка двух вендоров - PostgreSQL и Oracle). Они всю свою жизнь принимали запросы по HTTP и возвращали ответы в формате JSON.
Церемонии Чистой Архитектуры в таких приложениях только мешали.
И в них не было настолько сложной бизнес-логики, чтобы бизнес видел ценность в проведении сессий эвентштроминга с участием экспертов предметной области и трате времени на создание вездесущего языка (Ubiquitous language) и карты контекстов. И они не обслуживали разные отделы бизнеса, с собственными процессами, правилами и языком.
Идея применения DDD в таких приложения умирала на этапе "продажи" бизнесу и команде.
Но назвать эти приложения простыми у меня язык не поворачивается.
Потому что они хранили информацию о десятках и сотнях типов сущностей. У которых были десятки, а иногда и сотни полей.
А "простые" CREATE/UPDATE/DELETE операции затрагивали десятки таблиц, делали пару-тройку походов во внешние сервисы по HTTP, публиковали по сообщению в пару разных брокеров очередей и отправляли емейл "на сладкое".
Сложность этих систем заключалась не в бизнес-правилах и инвариантах, на которых фокусируются Чистая Архитектура и DDD, а в модели данных и взаимодействиях с внешними системами.
И разработчики таких систем оставались без руководства, как проектировать модель данных и эффекты (поведение). И в отсутствии каких-либо ограничений, разработчики шли по пути наименьшего сопротивления и порождали такие модели данных:
Картинка №2
и такие графы вызовов методов:
Картинка №1
Диаграммы выше - это диаграммы построенные по коду реального проекта, с которым мне довелось работать. И я вам скажу, что работать с этим кодом было удовольствием для редкостных гурманов.
На самом деле именно этот проект послужил для меня толчком к поиску способа писать код по другому, который в итоге привёл к созданию Эргономичного подхода и написанию этой книги.
Я создал Эргономичный подход для того, чтобы я сам и другие разработчики "простых" CRUD-приложений могли проектировать сложные модели данных без экспертов предметной области и организовывать код поведения так, чтобы эффекты его работы были очевидными, а задачи по его оптимизации, исправлению и рефакторингу не превращались в детективные триллеры.
#ergo_book@ergonomic_code
Эргономичный код
Привет! С подачи Романа Русакова запоем прочитал The API. Очень крутая книга, рекомендую. Роман - спасибо:) Так же вы, возможно, задаётесь вопросом что это я затих. Вряд ли, конечно, но я всё равно отвечу - лопачу джиру Проект Э:) Чтобы понять стоило ли…
Please open Telegram to view this post
VIEW IN TELEGRAM
У вас было такое, что вы пришли на проект и подумали "О, боже! Его делали крутые спецы!"?
Anonymous Poll
49%
Да
51%
Нет
Эргономичный код
У вас было такое, что вы пришли на проект и подумали "О, боже! Его делали крутые спецы!"?
Те, у кого был такой опыт: расскажите, пожалуйста про эти проекты:)
Эргономичный код
У вас было такое, что вы пришли на проект и подумали "О, боже! Его делали крутые спецы!"?
Привет!
Результаты опроса оказались обескураживающими и отрезвляющими для меня.
Ещё вчера я был уверен на 146%, что написать код, который последователи не зачмырят невозможно и в опросе максимум ожидал 80 на 20 в пользу "нет".
А на деле оказалось, что возможно.
Вопрос в том как?
И я думаю в наших силах найти ответ на этот вопрос.
Я думаю, если мы проведём доморощенное исследование, соберём хотя бы те же 80 анкет о "хороших" и "плохих" проектах и сможем найти сильную корреляцию между какими-то атрибутами/характеристиками проектов и их высокой оценкой последователями - то это и будет ответом:)
Я ещё не решился, на то чтобы запустить это исследование, но думаю с высокой вероятностью, на днях приостановлю ретру проекта Р и попробую собрать анкету.
Ещё я бы хотел собрать исследовательскую группу из трёх человек (включая себя), чтобы составить анкету и проанализировать данные. Во-первых, три головы лучше, во-вторых, у меня компетенций в таких исследованиях нет и если кто-то их в группу принесёт - будет очень круто:)
В общем, если хотите поучаствовать в этом движе - пишите в личку.
Если вдруг желающих наберётся больше двух, приоритет будет у тех, кто обладает релевантным опытом (проведение (социологических?) исследований, анализ данных), а потом в порядке получения сообщений.
Результаты опроса оказались обескураживающими и отрезвляющими для меня.
Ещё вчера я был уверен на 146%, что написать код, который последователи не зачмырят невозможно и в опросе максимум ожидал 80 на 20 в пользу "нет".
А на деле оказалось, что возможно.
Вопрос в том как?
И я думаю в наших силах найти ответ на этот вопрос.
Я думаю, если мы проведём доморощенное исследование, соберём хотя бы те же 80 анкет о "хороших" и "плохих" проектах и сможем найти сильную корреляцию между какими-то атрибутами/характеристиками проектов и их высокой оценкой последователями - то это и будет ответом:)
Я ещё не решился, на то чтобы запустить это исследование, но думаю с высокой вероятностью, на днях приостановлю ретру проекта Р и попробую собрать анкету.
Ещё я бы хотел собрать исследовательскую группу из трёх человек (включая себя), чтобы составить анкету и проанализировать данные. Во-первых, три головы лучше, во-вторых, у меня компетенций в таких исследованиях нет и если кто-то их в группу принесёт - будет очень круто:)
В общем, если хотите поучаствовать в этом движе - пишите в личку.
Если вдруг желающих наберётся больше двух, приоритет будет у тех, кто обладает релевантным опытом (проведение (социологических?) исследований, анализ данных), а потом в порядке получения сообщений.
Привет!
Подглядел в канале Давида Шекунца про конкурс (канал: @tg_contest_main) авторских каналов и тоже решил попробовать выйти из информационного пузыря:)
Приходите, читайте, голосуйте:) За кого голосовать - вы знаете :)
Подглядел в канале Давида Шекунца про конкурс (канал: @tg_contest_main) авторских каналов и тоже решил попробовать выйти из информационного пузыря:)
Приходите, читайте, голосуйте:) За кого голосовать - вы знаете :)
tg-contest.tilda.ws
Конкурс авторских Telegram-каналов — найди читателей, найди интересный контент
Конкурс для авторов Telegram-каналов и их читателей. Подайте заявку, найдите новых подписчиков, голосуйте за любимые каналы и откройте для себя лучшие голоса Telegram. Всё по любви и без инфоцыганства.
И я официально объявляю о начале работы над исследованием "Характеристики поддерживаемых кодовых баз бакэндов"!
Решился я во многом благодаря тому, что эту затею решили поддержать два человека.
Представляю наших героев:
- Алексей Голощапов. 11 лет занимается коммерческой разработкой, сейчас работает техлидом в финтехе.
- Виктор. 7 лет разрабатывает по на Java и Kotlin, сейчас работает тимлидом.
— так что у нас набралась исследовательская группа из трёх человек:) Ребята, спасибо вам огромное.
Цель исследования — найти характеристики кодовых баз, часто встречающиеся в проектах, которые новые разработчики сочли поддерживаемыми и редко встречающиеся в неподдерживаемых проектах. И на основе этого понять как делать проекты так, чтобы ваши последователи сочли их поддерживаемыми. Либо увидеть там белый шум и таки убедиться в том, что поддерживаемость проекта не зависит от того, как он написан:)
Так как мы все это будем делать в первый раз, коммитаться на сроки не будем. Но постараемся до 11 июля опубликовать анкету, а результаты анализа и сырые данные опубликовать в сентябре.
Ваша поддержка тоже будет очень важна для нас:
1. самое главное - надо будет заполнить анкету и постараться сделать это максимально аккуратно. А это будет, судя по всему, не просто, так как анкета получается большая
2. можете в комментах накидать вопросы и гипотезы, которые хотели бы увидеть в анкете или проверить с её помощью. Не обещаю, что всё возьмём в чистом виде, но обязательно рассмотрим
3. когда анкета будет готова - надо будет рассказать о ней максимальному количеству разработчиков
В общем, стей тюнед, возможно месяца через три вы узнаете обоснованный ответ на вопрос "Как писать поддерживаемые кодовые базы?" :)
Решился я во многом благодаря тому, что эту затею решили поддержать два человека.
Представляю наших героев:
- Алексей Голощапов. 11 лет занимается коммерческой разработкой, сейчас работает техлидом в финтехе.
- Виктор. 7 лет разрабатывает по на Java и Kotlin, сейчас работает тимлидом.
— так что у нас набралась исследовательская группа из трёх человек:) Ребята, спасибо вам огромное.
Цель исследования — найти характеристики кодовых баз, часто встречающиеся в проектах, которые новые разработчики сочли поддерживаемыми и редко встречающиеся в неподдерживаемых проектах. И на основе этого понять как делать проекты так, чтобы ваши последователи сочли их поддерживаемыми. Либо увидеть там белый шум и таки убедиться в том, что поддерживаемость проекта не зависит от того, как он написан:)
Так как мы все это будем делать в первый раз, коммитаться на сроки не будем. Но постараемся до 11 июля опубликовать анкету, а результаты анализа и сырые данные опубликовать в сентябре.
Ваша поддержка тоже будет очень важна для нас:
1. самое главное - надо будет заполнить анкету и постараться сделать это максимально аккуратно. А это будет, судя по всему, не просто, так как анкета получается большая
2. можете в комментах накидать вопросы и гипотезы, которые хотели бы увидеть в анкете или проверить с её помощью. Не обещаю, что всё возьмём в чистом виде, но обязательно рассмотрим
3. когда анкета будет готова - надо будет рассказать о ней максимальному количеству разработчиков
В общем, стей тюнед, возможно месяца через три вы узнаете обоснованный ответ на вопрос "Как писать поддерживаемые кодовые базы?" :)
Привет!
Вести с исследовательских полей.
Пока идём по графику, вчера закончили этап брейншторма вопросов.
Всего нагенеряли 124 вопроса:
1. 6 про респондента (возраст, пол и т.д.)
2. 19 про "демографию" проекта (возраст, размер и т.д.)
3. 6 про "демографию" респондента на проекте (грейд, время работы и т.д.)
4. 93 про устройство проекта (архитектура, применение различных принципов, тесты, доки и т.д.).
Следующий этап - критический анализ нагенеренных вопросов
Вести с исследовательских полей.
Пока идём по графику, вчера закончили этап брейншторма вопросов.
Всего нагенеряли 124 вопроса:
1. 6 про респондента (возраст, пол и т.д.)
2. 19 про "демографию" проекта (возраст, размер и т.д.)
3. 6 про "демографию" респондента на проекте (грейд, время работы и т.д.)
4. 93 про устройство проекта (архитектура, применение различных принципов, тесты, доки и т.д.).
Следующий этап - критический анализ нагенеренных вопросов
Привет!
Шуточка за триста: что общего у программистов и программистов-исследователей? И те, и другие факапят сроки.
Мы выбились из графика и с учётом того, что 11 июля я уеду на Алтай, заберусь на гору без электричества и связи и буду там сидеть неделю - видимо анкету опубликуем в конце месяца.
Но этап критического анализа мы закончили и вопросов стало... 127:)
Но не переживайте - подавляющее большинство вопросов опциональные и/или являются выбором из вариантов в духе всегда..никогда с опцией "Другое", куда можно вписать "Не знаю, не помню".
Надеюсь, что среднее время заполнения не будет превышать 20 минут - это мы на этапе бета-теста проверим и если будет сильно дольше - наверное всё-таки подрежем вопросы.
Шуточка за триста: что общего у программистов и программистов-исследователей? И те, и другие факапят сроки.
Мы выбились из графика и с учётом того, что 11 июля я уеду на Алтай, заберусь на гору без электричества и связи и буду там сидеть неделю - видимо анкету опубликуем в конце месяца.
Но этап критического анализа мы закончили и вопросов стало... 127:)
Но не переживайте - подавляющее большинство вопросов опциональные и/или являются выбором из вариантов в духе всегда..никогда с опцией "Другое", куда можно вписать "Не знаю, не помню".
Надеюсь, что среднее время заполнения не будет превышать 20 минут - это мы на этапе бета-теста проверим и если будет сильно дольше - наверное всё-таки подрежем вопросы.
OpenIDE + Amplicode сделали мощную заявку на то, чтобы я переехал на них, когда очередной EAP IDEA закончится. Как минимум попробую.
Forwarded from Amplicode
Media is too big
VIEW IN TELEGRAM
🤩 Свежие возможности Amplicode
В недавних обновлениях Amplicode появились два КРУПНЫХ блока нововведений — HTTP Client и Database Client.
Чтобы упростить изучение этих фич, мы создали два новых лендинга на сайте, где вы найдете короткие "How-to" видео с демонстрацией возможностей:
– ConneKt — HTTP-клиент в вашей IDE
– Database Client от Amplicode — управляйте БД прямо из IDE
P.S. К посту прикреплено одно из таких видео: "Просмотр структуры базы данных".
В недавних обновлениях Amplicode появились два КРУПНЫХ блока нововведений — HTTP Client и Database Client.
Чтобы упростить изучение этих фич, мы создали два новых лендинга на сайте, где вы найдете короткие "How-to" видео с демонстрацией возможностей:
– ConneKt — HTTP-клиент в вашей IDE
– Database Client от Amplicode — управляйте БД прямо из IDE
P.S. К посту прикреплено одно из таких видео: "Просмотр структуры базы данных".
Привет!
Третья большая новость наконец дозрела - я утряс все формальности и возобновил работу над Проектом Э!
Пока я пилил #project_r@ergonomic_code, заказчик пилил новый девайс, который делает замеры постоянно. И после его внедрения, нагрузка поднимется с ~3 измерений на пользователя в день до ~700.
А в самом оптимистичном сценарии - дорастёт до 50 RPS. Это ещё не хайлоад, конечно, но уже достаточно серьёзная нагрузка, которая не простит откровенно неэффективных решений.
Соответственно, сейчас моя основная задача немного допилить бэк для поддержки нового устройства и подготовить его к росту нагрузки. Плюс в бэклоге накопилась пачка фич, которые тоже надо будет сделать.
И на мой взгляд, это очень крутая новость для ЭП. Это значит, что у меня будет реальная обратная связь из первых рук о том, как ЭП масштабируется и по размеру проекта (сейчас - 40k строк Котлин-кода и 72 таблицы) и по RPS.
Кроме того, у меня был очень любопытный опыт приёма на поддержку собственного проекта после практически 1.5-летнего перерыва. Там, на самом деле есть прям много чего написать, но, к сожалению, не осилю. Если в целом общие ощущения - нот бэд, но за почти три года с момента начала разработки Проекта Э, Эргономичный подход сделал огромный шаг вперёд, особенно в части тестирования.
Плюс чуть подробнее поделюсь ещё одним инсайтом: идея, что можно в одном модуле попилить проект на вертикальные слайсы в пакетах и покрыть отсутствие циклических зависимостей между ними ArchUnit-тестом, для того чтобы вертикальные кусочки можно было легко вынести - оказалась тупиковой. В моей реализации, по крайней мере.
Во-первых, за 1.5 года в продовый код пробралось несколько циклов. И это при том, что я часа 4 потратил на то, чтобы написать максимально строгий Арч-юнит тест. Но это была меньшая из проблем - их я разорвал за несколько часов.
Потому что во-вторых - в тестах произошла тотальная катастрофа. Там образовался дикий клубок зависимостей, который я распутывал и распиливал неделю. Наверное, тесты надо покрывать ArchUnit-тестами тоже:)
В общем если вы делаете модульный монолит, и хотите иметь возможность быстро выносить модули в отдельные сервисы - не лениесь как я и заводите для них сразу отдельные модули
#project_e@ergonomic_code #ergo_approach@ergonomic_code
Третья большая новость наконец дозрела - я утряс все формальности и возобновил работу над Проектом Э!
Пока я пилил #project_r@ergonomic_code, заказчик пилил новый девайс, который делает замеры постоянно. И после его внедрения, нагрузка поднимется с ~3 измерений на пользователя в день до ~700.
А в самом оптимистичном сценарии - дорастёт до 50 RPS. Это ещё не хайлоад, конечно, но уже достаточно серьёзная нагрузка, которая не простит откровенно неэффективных решений.
Соответственно, сейчас моя основная задача немного допилить бэк для поддержки нового устройства и подготовить его к росту нагрузки. Плюс в бэклоге накопилась пачка фич, которые тоже надо будет сделать.
И на мой взгляд, это очень крутая новость для ЭП. Это значит, что у меня будет реальная обратная связь из первых рук о том, как ЭП масштабируется и по размеру проекта (сейчас - 40k строк Котлин-кода и 72 таблицы) и по RPS.
Кроме того, у меня был очень любопытный опыт приёма на поддержку собственного проекта после практически 1.5-летнего перерыва. Там, на самом деле есть прям много чего написать, но, к сожалению, не осилю. Если в целом общие ощущения - нот бэд, но за почти три года с момента начала разработки Проекта Э, Эргономичный подход сделал огромный шаг вперёд, особенно в части тестирования.
Плюс чуть подробнее поделюсь ещё одним инсайтом: идея, что можно в одном модуле попилить проект на вертикальные слайсы в пакетах и покрыть отсутствие циклических зависимостей между ними ArchUnit-тестом, для того чтобы вертикальные кусочки можно было легко вынести - оказалась тупиковой. В моей реализации, по крайней мере.
Во-первых, за 1.5 года в продовый код пробралось несколько циклов. И это при том, что я часа 4 потратил на то, чтобы написать максимально строгий Арч-юнит тест. Но это была меньшая из проблем - их я разорвал за несколько часов.
Потому что во-вторых - в тестах произошла тотальная катастрофа. Там образовался дикий клубок зависимостей, который я распутывал и распиливал неделю. Наверное, тесты надо покрывать ArchUnit-тестами тоже:)
В общем если вы делаете модульный монолит, и хотите иметь возможность быстро выносить модули в отдельные сервисы - не лениесь как я и заводите для них сразу отдельные модули
#project_e@ergonomic_code #ergo_approach@ergonomic_code
Алексей Жидков
Как я превратил легаси-проект в конфетку за полгода. Том 1 - Алексей Жидков
https://azhidkov.pro/
И к слову, про реальную обратную связь. И про то, что мне не дают покоя лавры анкл Боба:)
Наше исследование идёт своим чередом, и там между делом зашла речь про анкл Боба. В частности, что его идеи не ложатся на реальную практику. Я высказал предположение, что анкл Боб последние лет 20 не участвует в реальной разработке. А потом спросил у гопатыча, дипсика и алисы. Дипсик и алиса подтвердили, гопатыч соврал - сослался сюда и сказал что реальный опыт есть, но по ссылке ничего об этом не написано.
Короче, не слушайте анкл Боба, слушайте меня - у меня каждая идея выстрадана и опробована в коммерческой практике:)
#ergo_approach@ergonomic_code #solid@ergonomic_code #clean_architecture@ergonomic_code
Наше исследование идёт своим чередом, и там между делом зашла речь про анкл Боба. В частности, что его идеи не ложатся на реальную практику. Я высказал предположение, что анкл Боб последние лет 20 не участвует в реальной разработке. А потом спросил у гопатыча, дипсика и алисы. Дипсик и алиса подтвердили, гопатыч соврал - сослался сюда и сказал что реальный опыт есть, но по ссылке ничего об этом не написано.
Короче, не слушайте анкл Боба, слушайте меня - у меня каждая идея выстрадана и опробована в коммерческой практике:)
#ergo_approach@ergonomic_code #solid@ergonomic_code #clean_architecture@ergonomic_code