Forwarded from Russian Association of Software Architects (Eugene Lukianov)
Какую же задачу решает качественный код?
💬 "Nothing kills speed more effectively than poor internal quality."
—"Planning Extreme Programming" by Kent Beck, Martin Fowler
💬 "... the activity of design is not an option. It must be given serious thought for software development to be effective."
—"Extreme Programming Explained" by Kent Beck
💬 "The only way to make the deadline — the only way to go fast — is to keep the code as clean as possible at all times."
—"Clean Code: A Handbook of Agile Software Craftsmanship" by Robert C. Martin
💬 "In most contexts higher quality ⇒ expensive. But high internal quality of software allows us to develop features faster and cheaper."
—"Tradable Quality Hypothesis" by Martin Fowler
💬 "The value of good software design is economic: you can continue to add new functionality quickly even as the code-base grows in size."
—"Design Stamina Hypothesis" by Martin Fowler
💬 "The fundamental role of internal quality is that it lowers the cost of future change. But there is some extra effort required to write good software, which does impose some cost in the short term."
—"Is High Quality Software Worth the Cost?" by Martin Fowler
💬 "The whole point of good design and clean code is to make you go faster - if it didn't people like Uncle Bob, Kent Beck, and Ward Cunningham wouldn't be spending time talking about it."
—"Technical Debt Quadrant" by Martin Fowler
💬 "If you're a manager or customer how can you tell if the software is well designed? It matters to you because poorly designed software will be more expensive to modify in the future."
—"Is Design Dead?" by Martin Fowler
Сама по себе скорость разработки - это еще не цель. Это только задача в достижении цели.
Да, темпы разработки имеют имеют очевидные цели, такие как:
- экономический эффект за счет удешевления разработки,
- уменьшение ущерба упущенной выгоды от задержки выхода на рынок (time-to-market) новых бизнес-фич,
- повышение конкурентоспособности за счет ускорения адаптируемости к скороточно меняющимся условиям рынка...
Но есть еще одна цель, часто упускаемая из виду, та самая, которая имеет фундаментальное значение для анализа и архитектуры. И непонимание этой цели часто приводит к тому, что либо качество кода жертвуется в угоду краткосрочным бизнес-интересам, либо наоборот, качество делается ради качества где надо и не надо, выстраивая тем самым против себя глухую стену непонимания и обороны со стороны представителей бизнеса. Но об этом уже в другой раз.
#SoftwareDesign
💬 "Nothing kills speed more effectively than poor internal quality."
—"Planning Extreme Programming" by Kent Beck, Martin Fowler
💬 "... the activity of design is not an option. It must be given serious thought for software development to be effective."
—"Extreme Programming Explained" by Kent Beck
💬 "The only way to make the deadline — the only way to go fast — is to keep the code as clean as possible at all times."
—"Clean Code: A Handbook of Agile Software Craftsmanship" by Robert C. Martin
💬 "In most contexts higher quality ⇒ expensive. But high internal quality of software allows us to develop features faster and cheaper."
—"Tradable Quality Hypothesis" by Martin Fowler
💬 "The value of good software design is economic: you can continue to add new functionality quickly even as the code-base grows in size."
—"Design Stamina Hypothesis" by Martin Fowler
💬 "The fundamental role of internal quality is that it lowers the cost of future change. But there is some extra effort required to write good software, which does impose some cost in the short term."
—"Is High Quality Software Worth the Cost?" by Martin Fowler
💬 "The whole point of good design and clean code is to make you go faster - if it didn't people like Uncle Bob, Kent Beck, and Ward Cunningham wouldn't be spending time talking about it."
—"Technical Debt Quadrant" by Martin Fowler
💬 "If you're a manager or customer how can you tell if the software is well designed? It matters to you because poorly designed software will be more expensive to modify in the future."
—"Is Design Dead?" by Martin Fowler
Сама по себе скорость разработки - это еще не цель. Это только задача в достижении цели.
Да, темпы разработки имеют имеют очевидные цели, такие как:
- экономический эффект за счет удешевления разработки,
- уменьшение ущерба упущенной выгоды от задержки выхода на рынок (time-to-market) новых бизнес-фич,
- повышение конкурентоспособности за счет ускорения адаптируемости к скороточно меняющимся условиям рынка...
Но есть еще одна цель, часто упускаемая из виду, та самая, которая имеет фундаментальное значение для анализа и архитектуры. И непонимание этой цели часто приводит к тому, что либо качество кода жертвуется в угоду краткосрочным бизнес-интересам, либо наоборот, качество делается ради качества где надо и не надо, выстраивая тем самым против себя глухую стену непонимания и обороны со стороны представителей бизнеса. Но об этом уже в другой раз.
#SoftwareDesign
martinfowler.com
bliki: Tradable Quality Hypothesis
In most contexts higher quality ⇒ expensive. But high internal quality of software allows us to develop features faster and cheaper.
👍4🔥3
Forwarded from Russian Association of Software Architects (Ivan Zakrevsky)
Chat Digest
💬 "Классическая статья Пэта Хэлланда "Data on the Outside vs. Data on the Inside"
- https://news.1rj.ru/str/ru_arc_chat/1136
💬 "Mindmap оп рискам и таксономии целей"
- https://news.1rj.ru/str/ru_arc_chat/1147
💬 "Три опоры архитектора"
- https://news.1rj.ru/str/ru_arc_chat/1168
💬 Что такое Система?
- https://news.1rj.ru/str/ru_arc_chat/1194
- https://news.1rj.ru/str/ru_arc_chat/1195
💬 ISO/IEC/IEEE 15288:2015 Systems and software engineering — System life cycle processes
- https://news.1rj.ru/str/ru_arc_chat/1190
💬 Про умственное жонглирование на почве недостаточного качества кода:
- https://news.1rj.ru/str/ru_arc_chat/1222
💬 Нельзя поддерживать бесконечную гибкость архитектуры - она тоже имеет свою цену:
- https://news.1rj.ru/str/ru_arc_chat/1248
💬 Пара статей о балансе Prediction/Adaptation в SDLC-моделях:
- https://news.1rj.ru/str/ru_arc_chat/1253
💬 Причины отскока маятника от Adaptation к Prediction:
- https://news.1rj.ru/str/ru_arc_chat/1263
💬 О гибридизации Agile и проектных практик:
- https://news.1rj.ru/str/ru_arc_chat/1265
💬 Is Design Dead (for Agile)?
- https://news.1rj.ru/str/ru_arc_chat/1272
💬 Два вида неопределенности требований:
- https://news.1rj.ru/str/ru_arc_chat/1274
💬 CAP-theorem уже устарела. Что изучать?
- https://news.1rj.ru/str/ru_arc_chat/1283
💬 О генерации кода микросервисов по диаграммам Event Storming:
- https://news.1rj.ru/str/ru_arc_chat/1291
💬 Хорошее и простое руководство по Open Agile Architecture, которое отличается хорошим балансом лаконичности и информационной ценности, сопровождаемое демонстрационной моделью в Archi. Если не знаете с чего начать документирование архитектуры в Agile, то это самое оно:
- https://news.1rj.ru/str/ru_arc_chat/1309
#ChatDigest
💬 "Классическая статья Пэта Хэлланда "Data on the Outside vs. Data on the Inside"
- https://news.1rj.ru/str/ru_arc_chat/1136
💬 "Mindmap оп рискам и таксономии целей"
- https://news.1rj.ru/str/ru_arc_chat/1147
💬 "Три опоры архитектора"
- https://news.1rj.ru/str/ru_arc_chat/1168
💬 Что такое Система?
- https://news.1rj.ru/str/ru_arc_chat/1194
- https://news.1rj.ru/str/ru_arc_chat/1195
💬 ISO/IEC/IEEE 15288:2015 Systems and software engineering — System life cycle processes
- https://news.1rj.ru/str/ru_arc_chat/1190
💬 Про умственное жонглирование на почве недостаточного качества кода:
- https://news.1rj.ru/str/ru_arc_chat/1222
💬 Нельзя поддерживать бесконечную гибкость архитектуры - она тоже имеет свою цену:
- https://news.1rj.ru/str/ru_arc_chat/1248
💬 Пара статей о балансе Prediction/Adaptation в SDLC-моделях:
- https://news.1rj.ru/str/ru_arc_chat/1253
💬 Причины отскока маятника от Adaptation к Prediction:
- https://news.1rj.ru/str/ru_arc_chat/1263
💬 О гибридизации Agile и проектных практик:
- https://news.1rj.ru/str/ru_arc_chat/1265
💬 Is Design Dead (for Agile)?
- https://news.1rj.ru/str/ru_arc_chat/1272
💬 Два вида неопределенности требований:
- https://news.1rj.ru/str/ru_arc_chat/1274
💬 CAP-theorem уже устарела. Что изучать?
- https://news.1rj.ru/str/ru_arc_chat/1283
💬 О генерации кода микросервисов по диаграммам Event Storming:
- https://news.1rj.ru/str/ru_arc_chat/1291
💬 Хорошее и простое руководство по Open Agile Architecture, которое отличается хорошим балансом лаконичности и информационной ценности, сопровождаемое демонстрационной моделью в Archi. Если не знаете с чего начать документирование архитектуры в Agile, то это самое оно:
- https://news.1rj.ru/str/ru_arc_chat/1309
#ChatDigest
Telegram
Andrei Gordienkov in RASA Chat
кстати, мы тут вчера обсуждали всякое и затронули немного события, и в этой связи хотелось бы вам напомнить о классической статье Пэта Хэлланда
https://queue.acm.org/detail.cfm?id=3415014
Если еще не читали, то горячо советую ознакомиться, поскольку отсылок…
https://queue.acm.org/detail.cfm?id=3415014
Если еще не читали, то горячо советую ознакомиться, поскольку отсылок…
🔥3👍2😁1
Forwarded from Russian Association of Software Architects (Ivan Zakrevsky)
Сегодня в одном из чатов мне напомнили о том, что существует "Overengeneering", и это, в общем-то, как бы плохо. Отсюда напрашивается вывод, что, мол, не нужно развиваться, чтобы не стать оверинженерным и квазинаучным.
Не берусь судить о том, плохо это, или хорошо, но это неизбежно в процессе профессионального становления специалиста, а раз так, то польза от этого явления, по всей видимости, все-таки перевешивает наносимый урон, поскольку урон этот является однократным явлением, а польза от достигнутого профессионального уровня носит систематический характер.
В индустрии это явление известно как "Синдром второй системы", который гласит, что вторая создаваемая система в практике специалиста обычно обладает переусложненностью.
По этому поводу хорошо выразился И.Е.Репин:
💬 "Сначала художник рисует плохо и просто.
Потом сложно и плохо.
Потом сложно и хорошо.
И только потом - просто и хорошо."
Ладно, И.Е.Репин - не IT-шник:
💬 "Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better."
—Edsger W. Dijkstra, 1984 On the nature of Computing Science (EWD896)
Что можно в этом случае предпринять? Варианта два:
1. Уравновешивать когнитивные искажения технического специалиста, чем, собственно, и должна заниматься организация процессов разработки. По понятным причинам, сейчас мы в неё погружаться не будем. Главное - знать, что эта проблема решаема.
2. Чем большей полнотой знаний обладает специалист, тем большим моментом инерции обладает его устойчивость, тем меньшее воздействие на неё оказывает каждый новый инкремент знаний, и тем лучше достигается сбалансированность решений. Иными словами, лечится это увеличением охвата знаний. Нужно просто не зацикливаться и поскорее пройти этот этап профессионального становления.
Можно ли стать "переусложненным" постоянно развиваясь? Нет, не можно, и это хорошо видно на примере Kent Beck - невероятно эрудированного человека, обладающего редкой способностью объяснять сложные вещи простым языком. Объем списка использованной литературы его книг вызывает состояние легкого удивления, как и простота и ясность его формулировок. Другим таким ярким примером является @vladik_kh .
Объясняется это просто - возможности человеческого мозга ограничены, и, чтобы не потонуть в океане информации, и сохранить какую-то способность ориентироваться в ней, он начинает кристаллизировать её. Постоянно обобщая и систематизируя, он выводит наименее противоречивую форму этой информации. Количество переходит в качество.
Ну а самое главное - overengeneering является как раз следствием недостатка знаний о контексте и моменте своевременности применения тех или иных подходов. Излечить это незнание с помощью информационного голода технически невозможно, т.к. между YAGNI и Spaghetti-code имеется огромная разница, которая заключается именно в полноте знаний.
#SoftSkills #Simplicity
Не берусь судить о том, плохо это, или хорошо, но это неизбежно в процессе профессионального становления специалиста, а раз так, то польза от этого явления, по всей видимости, все-таки перевешивает наносимый урон, поскольку урон этот является однократным явлением, а польза от достигнутого профессионального уровня носит систематический характер.
В индустрии это явление известно как "Синдром второй системы", который гласит, что вторая создаваемая система в практике специалиста обычно обладает переусложненностью.
По этому поводу хорошо выразился И.Е.Репин:
💬 "Сначала художник рисует плохо и просто.
Потом сложно и плохо.
Потом сложно и хорошо.
И только потом - просто и хорошо."
Ладно, И.Е.Репин - не IT-шник:
💬 "Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better."
—Edsger W. Dijkstra, 1984 On the nature of Computing Science (EWD896)
Что можно в этом случае предпринять? Варианта два:
1. Уравновешивать когнитивные искажения технического специалиста, чем, собственно, и должна заниматься организация процессов разработки. По понятным причинам, сейчас мы в неё погружаться не будем. Главное - знать, что эта проблема решаема.
2. Чем большей полнотой знаний обладает специалист, тем большим моментом инерции обладает его устойчивость, тем меньшее воздействие на неё оказывает каждый новый инкремент знаний, и тем лучше достигается сбалансированность решений. Иными словами, лечится это увеличением охвата знаний. Нужно просто не зацикливаться и поскорее пройти этот этап профессионального становления.
Можно ли стать "переусложненным" постоянно развиваясь? Нет, не можно, и это хорошо видно на примере Kent Beck - невероятно эрудированного человека, обладающего редкой способностью объяснять сложные вещи простым языком. Объем списка использованной литературы его книг вызывает состояние легкого удивления, как и простота и ясность его формулировок. Другим таким ярким примером является @vladik_kh .
Объясняется это просто - возможности человеческого мозга ограничены, и, чтобы не потонуть в океане информации, и сохранить какую-то способность ориентироваться в ней, он начинает кристаллизировать её. Постоянно обобщая и систематизируя, он выводит наименее противоречивую форму этой информации. Количество переходит в качество.
Ну а самое главное - overengeneering является как раз следствием недостатка знаний о контексте и моменте своевременности применения тех или иных подходов. Излечить это незнание с помощью информационного голода технически невозможно, т.к. между YAGNI и Spaghetti-code имеется огромная разница, которая заключается именно в полноте знаний.
#SoftSkills #Simplicity
Wikipedia
Эффект второй системы
Эффект второй системы (также синдром второй системы) — тенденция того, что на смену маленьким, элегантным и успешным системам приходят раздутые системы с овер-инжинирингом, вследствие завышенных ожиданий и чрезмерной уверенности в необходимости изменений.
👍12🔥7
Forwarded from Блог Сергея Баранова
Привет!
Приглашаем на очную встречу ArchDays Recap 27 июля (ср) в Москве.
🧚ArchDays Recap — новый для нас формат, на котором приглашенные спикеры предыдущих конференций:
— расскажут о дальнейшем развитии истории из выступления;
— раскроют некоторые аспекты выступлений, важность которых была осознана уже после;
— ответят на вопросы из зала или из формы на сайте.
📍Программа и регистрация: https://archconf.ru/recap-27-07-22
Приглашаем на очную встречу ArchDays Recap 27 июля (ср) в Москве.
🧚ArchDays Recap — новый для нас формат, на котором приглашенные спикеры предыдущих конференций:
— расскажут о дальнейшем развитии истории из выступления;
— раскроют некоторые аспекты выступлений, важность которых была осознана уже после;
— ответят на вопросы из зала или из формы на сайте.
📍Программа и регистрация: https://archconf.ru/recap-27-07-22
👍4🔥3👎2👏1
💬 "The Single Responsibility Principle (SRP):
Gather together those things that change for the same reasons and at the same times. Separate those things that change for different reasons or at different times."
-- Robert C. Martin. Самая последняя редакция от 2022-07-06.
P.S.: Если вдруг кто еще считает, что SRP - это делать одну вещь...
#SoftwareDesign
Gather together those things that change for the same reasons and at the same times. Separate those things that change for different reasons or at different times."
-- Robert C. Martin. Самая последняя редакция от 2022-07-06.
P.S.: Если вдруг кто еще считает, что SRP - это делать одну вещь...
#SoftwareDesign
👍7🔥2
💬 "What a fantastic visualization. What happens with communications on teams and why do we keep them small?" -- Greg Young
#TeamTopologies
#TeamTopologies
👍19🔥7
Блог Сергея Баранова
Привет! Приглашаем на очную встречу ArchDays Recap 27 июля (ср) в Москве. 🧚ArchDays Recap — новый для нас формат, на котором приглашенные спикеры предыдущих конференций: — расскажут о дальнейшем развитии истории из выступления; — раскроют некоторые аспекты…
Я эту встречу тоже планирую посетить, если что. Может быть сходим потом в кафешку (круглосуточную), если будет настроение.
Telegram
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
Привет!
Приглашаем на очную встречу ArchDays Recap 27 июля (ср) в Москве.
🧚ArchDays Recap — новый для нас формат, на котором приглашенные спикеры предыдущих конференций:
— расскажут о дальнейшем развитии истории из выступления;
— раскроют некоторые аспекты…
Приглашаем на очную встречу ArchDays Recap 27 июля (ср) в Москве.
🧚ArchDays Recap — новый для нас формат, на котором приглашенные спикеры предыдущих конференций:
— расскажут о дальнейшем развитии истории из выступления;
— раскроют некоторые аспекты…
🔥5👍1
Друзья, хочу поделиться последними изменениями.
Если вы помните, был опрос о том, нужно ли мне транслировать в этот канал сообщения из канала
https://news.1rj.ru/str/ru_arc , в состав сооснователей которого я вхожу. Простое большинство (1/2) высказалось против, но квалифицированное большинство (2/3) не набралось.
Я думал над этим вопросом и решил поступить следующим образом:
- в этот канал я буду писать то, что узнаю нового сам, и то, что касается моей личной деятельности;
- в @ru_arc я буду писать то, что соответствует редакционной политике канала, преимущественно те знания, которые у меня уже давно выкристаллизовались.
Основную часть свободно времени я был и буду занят разработкой Open Source Reference Application in Golang:
- https://github.com/emacsway/qualifying-grade
Этот проект предназначен для реальной эксплуатации, но выполняется он в виде Reference Application. Начал причесывать свои приватные заметки по этому проекту и публиковать их:
- https://dckms.github.io/system-architecture/emacsway/it/ddd/qualifying-grade/domain/index.html
Проект Устава Общественного объединения ИТ-Архитекторов уже боле-менее стабилизировался, но я пока еще не могу уверенно сказать, что он достиг финализации:
- https://github.com/ru-arc/charter/blob/main/charter.md
Есть вероятность, что в обозримом будущем мы уже утвердим Устав на учредительном собрании.
Традиционно напоминаю, что если кто-то разделяет наши цели, и готов сплотить усилия для их достижения - может обратиться в @ru_arc_bot . Кажется, у нас формируется неплохой дружественный коллектив реально крутых специалистов. На этой неделе к нам добавился один из грамотнейших архитекторов, которого я знаю.
В эту среду увидимся на очной встрече ArchDays Recap https://news.1rj.ru/str/emacsway_log/968
Всем спасибо за проявленный интерес и поддержку!
Если вы помните, был опрос о том, нужно ли мне транслировать в этот канал сообщения из канала
https://news.1rj.ru/str/ru_arc , в состав сооснователей которого я вхожу. Простое большинство (1/2) высказалось против, но квалифицированное большинство (2/3) не набралось.
Я думал над этим вопросом и решил поступить следующим образом:
- в этот канал я буду писать то, что узнаю нового сам, и то, что касается моей личной деятельности;
- в @ru_arc я буду писать то, что соответствует редакционной политике канала, преимущественно те знания, которые у меня уже давно выкристаллизовались.
Основную часть свободно времени я был и буду занят разработкой Open Source Reference Application in Golang:
- https://github.com/emacsway/qualifying-grade
Этот проект предназначен для реальной эксплуатации, но выполняется он в виде Reference Application. Начал причесывать свои приватные заметки по этому проекту и публиковать их:
- https://dckms.github.io/system-architecture/emacsway/it/ddd/qualifying-grade/domain/index.html
Проект Устава Общественного объединения ИТ-Архитекторов уже боле-менее стабилизировался, но я пока еще не могу уверенно сказать, что он достиг финализации:
- https://github.com/ru-arc/charter/blob/main/charter.md
Есть вероятность, что в обозримом будущем мы уже утвердим Устав на учредительном собрании.
Традиционно напоминаю, что если кто-то разделяет наши цели, и готов сплотить усилия для их достижения - может обратиться в @ru_arc_bot . Кажется, у нас формируется неплохой дружественный коллектив реально крутых специалистов. На этой неделе к нам добавился один из грамотнейших архитекторов, которого я знаю.
В эту среду увидимся на очной встрече ArchDays Recap https://news.1rj.ru/str/emacsway_log/968
Всем спасибо за проявленный интерес и поддержку!
Telegram
Russian Association of Software Architects
Канал самоуправляется коллегией: @sergey486 и @emacsway . Бот для вступления в авторский коллектив: @ru_arc_bot
Предложить доклад для митапа: @ru_arc_meetup_bot
Группы:
@ru_arc_chat
@rasa_business
@archicases
Рекламу не размещаем.
Предложить доклад для митапа: @ru_arc_meetup_bot
Группы:
@ru_arc_chat
@rasa_business
@archicases
Рекламу не размещаем.
🔥4👍3
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
Друзья, хочу поделиться последними изменениями. Если вы помните, был опрос о том, нужно ли мне транслировать в этот канал сообщения из канала https://news.1rj.ru/str/ru_arc , в состав сооснователей которого я вхожу. Простое большинство (1/2) высказалось против, но…
EventStorming.png
287.7 KB
Актуальная EventStorming диаграмма к заметке
https://dckms.github.io/system-architecture/emacsway/it/ddd/qualifying-grade/domain/aggregate-boundaries.html
Коммитить в заметку пока не хочу, т.к. много весит и пока еще нестабильна.
Оригинальная модель - в самой репе:
- https://github.com/emacsway/qualifying-grade/tree/main/model
https://dckms.github.io/system-architecture/emacsway/it/ddd/qualifying-grade/domain/aggregate-boundaries.html
Коммитить в заметку пока не хочу, т.к. много весит и пока еще нестабильна.
Оригинальная модель - в самой репе:
- https://github.com/emacsway/qualifying-grade/tree/main/model
👍3🔥2
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
Когда спрашивают зачем нужен слой абстракции от БД:
Очередной ORM ушел на задворки истории:
"go-pg is in a maintenance mode and will NOT receive new features. Please use Bun Golang ORM instead."
- https://pg.uptrace.dev/
Когда спрашивают, является ли ORM слоем абстракции....
"go-pg is in a maintenance mode and will NOT receive new features. Please use Bun Golang ORM instead."
- https://pg.uptrace.dev/
Когда спрашивают, является ли ORM слоем абстракции....
👍9
Forwarded from Russian Association of Software Architects (Ivan Zakrevsky)
Chat Digest
💬 "A Hybrid Software Architecture Evaluation Method for FDD - An Agile Process Model"
- https://news.1rj.ru/str/ru_arc_chat/1325
💬 Менеджеры топят за Agile без архитектуры. Что делать?
- https://news.1rj.ru/str/ru_arc_chat/1326
💬 Awesome workflow engines:
- https://github.com/meirwah/awesome-workflow-engines
💬 Steve McConnell о DDD:
- https://news.1rj.ru/str/ru_arc_chat/1362
💬 "Самовозникающий социальный паттерн" системной динамики - "Стремление к худшему":
https://news.1rj.ru/str/ru_arc_chat/1392
💬 Энтропия системы имеет склонность к росту - Gregor Hohpe:
- https://news.1rj.ru/str/ru_arc_chat/1395
- https://news.1rj.ru/str/ru_arc_chat/1391
💬 Цикл сообщений о роли Semantic Coupling:
- https://news.1rj.ru/str/ru_arc_chat/1411
💬 Типы Coupling:
- https://news.1rj.ru/str/ru_arc_chat/1413
💬 Оригинальная книга "Structured Design: Fundamentals of a Discipline of Computer Program and Systems Design" by Edward Y ourdon and Larry L. Constantine
- https://news.1rj.ru/str/ru_arc_chat/1434
💬 Что такое Coupling от Larry Constantine:
- https://news.1rj.ru/str/ru_arc_chat/1441
💬 DevOps модели:
- https://news.1rj.ru/str/ru_arc_chat/1488
💬 Продакт не выделяет ресурсов на устранение техдолга. Что делать?
- https://news.1rj.ru/str/ru_arc_chat/1490
💬 Когда делать рефакторинг:
- https://news.1rj.ru/str/ru_arc_chat/1508
💬 Как устранять техдолг?
- https://news.1rj.ru/str/ru_arc_chat/1509
- https://news.1rj.ru/str/ru_arc_chat/1510
💬 Влиятельный инструмент на менеджмент:
- https://news.1rj.ru/str/ru_arc_chat/1512
💬 Код - это рабочее место программиста и условия труда:
- https://news.1rj.ru/str/ru_arc_chat/1515
- https://news.1rj.ru/str/ru_arc_chat/1527
💬 Почему придумали Story Point?
- https://news.1rj.ru/str/ru_arc_chat/1518
💬 Кто отвечает за качество кода, Продакт или Команда?
- https://news.1rj.ru/str/ru_arc_chat/1524
💬 Заложить работу с техдолгом в оценку задачи:
- https://news.1rj.ru/str/ru_arc_chat/1548
- https://news.1rj.ru/str/ru_arc_chat/1552
- https://news.1rj.ru/str/ru_arc_chat/1567
- https://news.1rj.ru/str/ru_arc_chat/1573
💬 Является ли Продакт руководителем разработки?
- https://news.1rj.ru/str/ru_arc_chat/1549
💬 Усугубить кризис и решить техдолг под шумок:
- https://news.1rj.ru/str/ru_arc_chat/1564
💬 Что такое Transparency? Означает ли это спрашивать разрешения у Продакта на устранение техдолга?
- https://news.1rj.ru/str/ru_arc_chat/1568
💬 Можно ли удовлетворить интересы всех стейкхолдеров? Как находить сбалансированные решения и взаимокомпенсировать когнитивные искажения сторон. ATAM в Agile?
- https://news.1rj.ru/str/ru_arc_chat/1569
💬 "Синдром второй системы" народным языком:
- https://news.1rj.ru/str/ru_arc_chat/1571
💬 "Правило трех ударов" народным языком:
- https://news.1rj.ru/str/ru_arc_chat/1616
- https://news.1rj.ru/str/ru_arc_chat/1691
💬 ITIL Foundation, практика Problem Management
- https://news.1rj.ru/str/ru_arc_chat/1650
💬 Крутое разъяснение простым языком про обратную корреляцию требований:
- https://news.1rj.ru/str/ru_arc_chat/1669
💬 Крутое разъяснение о том, как относиться к проблемам:
- https://news.1rj.ru/str/ru_arc_chat/1678
#ChatDigest
💬 "A Hybrid Software Architecture Evaluation Method for FDD - An Agile Process Model"
- https://news.1rj.ru/str/ru_arc_chat/1325
💬 Менеджеры топят за Agile без архитектуры. Что делать?
- https://news.1rj.ru/str/ru_arc_chat/1326
💬 Awesome workflow engines:
- https://github.com/meirwah/awesome-workflow-engines
💬 Steve McConnell о DDD:
- https://news.1rj.ru/str/ru_arc_chat/1362
💬 "Самовозникающий социальный паттерн" системной динамики - "Стремление к худшему":
https://news.1rj.ru/str/ru_arc_chat/1392
💬 Энтропия системы имеет склонность к росту - Gregor Hohpe:
- https://news.1rj.ru/str/ru_arc_chat/1395
- https://news.1rj.ru/str/ru_arc_chat/1391
💬 Цикл сообщений о роли Semantic Coupling:
- https://news.1rj.ru/str/ru_arc_chat/1411
💬 Типы Coupling:
- https://news.1rj.ru/str/ru_arc_chat/1413
💬 Оригинальная книга "Structured Design: Fundamentals of a Discipline of Computer Program and Systems Design" by Edward Y ourdon and Larry L. Constantine
- https://news.1rj.ru/str/ru_arc_chat/1434
💬 Что такое Coupling от Larry Constantine:
- https://news.1rj.ru/str/ru_arc_chat/1441
💬 DevOps модели:
- https://news.1rj.ru/str/ru_arc_chat/1488
💬 Продакт не выделяет ресурсов на устранение техдолга. Что делать?
- https://news.1rj.ru/str/ru_arc_chat/1490
💬 Когда делать рефакторинг:
- https://news.1rj.ru/str/ru_arc_chat/1508
💬 Как устранять техдолг?
- https://news.1rj.ru/str/ru_arc_chat/1509
- https://news.1rj.ru/str/ru_arc_chat/1510
💬 Влиятельный инструмент на менеджмент:
- https://news.1rj.ru/str/ru_arc_chat/1512
💬 Код - это рабочее место программиста и условия труда:
- https://news.1rj.ru/str/ru_arc_chat/1515
- https://news.1rj.ru/str/ru_arc_chat/1527
💬 Почему придумали Story Point?
- https://news.1rj.ru/str/ru_arc_chat/1518
💬 Кто отвечает за качество кода, Продакт или Команда?
- https://news.1rj.ru/str/ru_arc_chat/1524
💬 Заложить работу с техдолгом в оценку задачи:
- https://news.1rj.ru/str/ru_arc_chat/1548
- https://news.1rj.ru/str/ru_arc_chat/1552
- https://news.1rj.ru/str/ru_arc_chat/1567
- https://news.1rj.ru/str/ru_arc_chat/1573
💬 Является ли Продакт руководителем разработки?
- https://news.1rj.ru/str/ru_arc_chat/1549
💬 Усугубить кризис и решить техдолг под шумок:
- https://news.1rj.ru/str/ru_arc_chat/1564
💬 Что такое Transparency? Означает ли это спрашивать разрешения у Продакта на устранение техдолга?
- https://news.1rj.ru/str/ru_arc_chat/1568
💬 Можно ли удовлетворить интересы всех стейкхолдеров? Как находить сбалансированные решения и взаимокомпенсировать когнитивные искажения сторон. ATAM в Agile?
- https://news.1rj.ru/str/ru_arc_chat/1569
💬 "Синдром второй системы" народным языком:
- https://news.1rj.ru/str/ru_arc_chat/1571
💬 "Правило трех ударов" народным языком:
- https://news.1rj.ru/str/ru_arc_chat/1616
- https://news.1rj.ru/str/ru_arc_chat/1691
💬 ITIL Foundation, практика Problem Management
- https://news.1rj.ru/str/ru_arc_chat/1650
💬 Крутое разъяснение простым языком про обратную корреляцию требований:
- https://news.1rj.ru/str/ru_arc_chat/1669
💬 Крутое разъяснение о том, как относиться к проблемам:
- https://news.1rj.ru/str/ru_arc_chat/1678
#ChatDigest
Telegram
Ivan Zakrevsky in RASA Chat
По ссылке Len Bass обнаружил вот такой интересный документ по гибридизации:
"A Hybrid Software Architecture Evaluation Method for FDD - An Agile Process Model"
https://www.researchgate.net/publication/224208433_A_Hybrid_Software_Architecture_Evaluation_Method_for_FDD_…
"A Hybrid Software Architecture Evaluation Method for FDD - An Agile Process Model"
https://www.researchgate.net/publication/224208433_A_Hybrid_Software_Architecture_Evaluation_Method_for_FDD_…
👍3🔥1
Шикарная статья для тех, кто намерен использовать PostgreSQL JSONB для хранения Агрегатов:
"Борьба с TOAST или будущее JSONB в PostgreSQL"
- https://habr.com/ru/company/oleg-bunin/blog/646987/
Статья является продолжением статьи
"Проклятье TOAST и с каким маслом его ест JSONB" by Oleg Bartunov
- https://habr.com/ru/company/oleg-bunin/blog/597187/
Обе статьи уместны в контексте статьи "The Ideal Domain-Driven Design Aggregate Store?" by Vaughn Vernon
- https://kalele.io/the-ideal-domain-driven-design-aggregate-store/
#DDD #Database #PostgreSQL
"Борьба с TOAST или будущее JSONB в PostgreSQL"
- https://habr.com/ru/company/oleg-bunin/blog/646987/
Статья является продолжением статьи
"Проклятье TOAST и с каким маслом его ест JSONB" by Oleg Bartunov
- https://habr.com/ru/company/oleg-bunin/blog/597187/
Обе статьи уместны в контексте статьи "The Ideal Domain-Driven Design Aggregate Store?" by Vaughn Vernon
- https://kalele.io/the-ideal-domain-driven-design-aggregate-store/
#DDD #Database #PostgreSQL
Хабр
Борьба с TOAST или будущее JSONB в PostgreSQL
В PostgreSQL есть два типа данных: JSON и JSONB. Первый формат является текстовым хранилищем, в котором json хранится "as is", второй — бинарным, в нем ключи отсортированы (сначала по...
👍4
"UUID версии 7, или как не потеряться во времени при создании идентификатора"
- https://habr.com/ru/post/572700/
Интересны комментарии статьи и ссылки в них.
Thanks to @pantafive )) Кстати, у него недавно появился тг-канал, посвященный разработке на Golang:
- https://news.1rj.ru/str/smokycode
- https://habr.com/ru/post/572700/
Интересны комментарии статьи и ссылки в них.
Thanks to @pantafive )) Кстати, у него недавно появился тг-канал, посвященный разработке на Golang:
- https://news.1rj.ru/str/smokycode
Хабр
UUID версии 7, или как не потеряться во времени при создании идентификатора
Будьте аккуратны, при сохранении даты в UUID В течение многих лет я противостоял засилью UUID как ключей в базах данных, но со временем и практикой до меня дошло. Они действительно удобны, когда речь...
😁2👍1🔥1
Eric Evens в своей синей книге пишет, что, в общем-то не очень хорошо, когда Specification Pattern осведомлен об SQL
💬 "Now this design has some problems. Most important, the details of the table structure have leaked into the DOMAIN LAYER ; they should be isolated in a mapping layer that relates the domain objects to the relational tables. Implicitly duplicating that information here could hurt the modifiability and maintainability of the Invoice and Customer objects, because any change to their mappings now have to be tracked in more than one place. But this example is a simple illustration of how to keep the rule in just one place. Some object-relational mapping frameworks provide the means to express such a query in terms of the model objects and attributes, generating the actual SQL in the infrastructure layer. This would let us have our cake and eat it too."
— "Domain-Driven Design: Tackling Complexity in the Heart of Software" by Eric Evans
В C# для этого есть мощный механизм Expression Tree, что значительно упрощает дело. Примеры хорошо демонстрирует Vladimir Khorikov:
- https://enterprisecraftsmanship.com/posts/specification-pattern-c-implementation/
- https://enterprisecraftsmanship.com/posts/specification-pattern-always-valid-domain-model/
- https://github.com/vkhorikov/SpecificationPattern
- https://github.com/vkhorikov/SpecPattern
В Golang дело немного усложняется отсутствием нативной поддержки Expression Tree, и поддержку этих функций приходится брать на себя.
В общем, как получилась первая итерация (пока еще не финал), можно посмотреть здесь:
Абстрактная реализация + inMemory evaluator:
- https://github.com/emacsway/grade/blob/main/grade/internal/domain/seedwork/specification/
Конкретная реализация inMemory evaluator без использования рефлекции:
- https://github.com/emacsway/grade/blob/main/grade/internal/domain/endorser/specifications.go
Абстрактная реализация строителя PostgreSQL-запроса с учетом приоритетов операторов для исключения лишних скобочек:
- https://github.com/emacsway/grade/blob/main/grade/internal/infrastructure/specification/
Конкретная реализация строителя PostgreSQL-запроса с гибкой возможностью маппинга атрибутов:
- https://github.com/emacsway/grade/blob/main/grade/internal/infrastructure/repositories/endorser/endorser_specifications.go
Заложена (но до конца не раскрыта) возможность просмотра коллекций сущностей внутри агрегата и поиск удовлетворения условия хотя бы одним из элементов коллекции.
#DDD #SoftwareDesign
💬 "Now this design has some problems. Most important, the details of the table structure have leaked into the DOMAIN LAYER ; they should be isolated in a mapping layer that relates the domain objects to the relational tables. Implicitly duplicating that information here could hurt the modifiability and maintainability of the Invoice and Customer objects, because any change to their mappings now have to be tracked in more than one place. But this example is a simple illustration of how to keep the rule in just one place. Some object-relational mapping frameworks provide the means to express such a query in terms of the model objects and attributes, generating the actual SQL in the infrastructure layer. This would let us have our cake and eat it too."
— "Domain-Driven Design: Tackling Complexity in the Heart of Software" by Eric Evans
В C# для этого есть мощный механизм Expression Tree, что значительно упрощает дело. Примеры хорошо демонстрирует Vladimir Khorikov:
- https://enterprisecraftsmanship.com/posts/specification-pattern-c-implementation/
- https://enterprisecraftsmanship.com/posts/specification-pattern-always-valid-domain-model/
- https://github.com/vkhorikov/SpecificationPattern
- https://github.com/vkhorikov/SpecPattern
В Golang дело немного усложняется отсутствием нативной поддержки Expression Tree, и поддержку этих функций приходится брать на себя.
В общем, как получилась первая итерация (пока еще не финал), можно посмотреть здесь:
Абстрактная реализация + inMemory evaluator:
- https://github.com/emacsway/grade/blob/main/grade/internal/domain/seedwork/specification/
Конкретная реализация inMemory evaluator без использования рефлекции:
- https://github.com/emacsway/grade/blob/main/grade/internal/domain/endorser/specifications.go
Абстрактная реализация строителя PostgreSQL-запроса с учетом приоритетов операторов для исключения лишних скобочек:
- https://github.com/emacsway/grade/blob/main/grade/internal/infrastructure/specification/
Конкретная реализация строителя PostgreSQL-запроса с гибкой возможностью маппинга атрибутов:
- https://github.com/emacsway/grade/blob/main/grade/internal/infrastructure/repositories/endorser/endorser_specifications.go
Заложена (но до конца не раскрыта) возможность просмотра коллекций сущностей внутри агрегата и поиск удовлетворения условия хотя бы одним из элементов коллекции.
#DDD #SoftwareDesign
Docs
Деревья выражений - C#
Узнайте о деревьях выражений. Узнайте, как компилировать и запускать код, представленный этими структурами данных, где каждый узел является выражением.
🔥8👍2
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
Eric Evens в своей синей книге пишет, что, в общем-то не очень хорошо, когда Specification Pattern осведомлен об SQL 💬 "Now this design has some problems. Most important, the details of the table structure have leaked into the DOMAIN LAYER ; they should…
Идея экспортера, предложенная by Allen Holub:
- https://www.infoworld.com/article/2072302/more-on-getters-and-setters.html
удачно ложится на полностью искапсулированный объект построения SQL-запроса:
- https://github.com/emacsway/grade/blob/main/grade/internal/infrastructure/repositories/recognizer/insert_query.go
#DDD #OOP #SoftwareDesign
- https://www.infoworld.com/article/2072302/more-on-getters-and-setters.html
удачно ложится на полностью искапсулированный объект построения SQL-запроса:
- https://github.com/emacsway/grade/blob/main/grade/internal/infrastructure/repositories/recognizer/insert_query.go
#DDD #OOP #SoftwareDesign
InfoWorld
More on getters and setters
Allen Holub's past Java Toolbox column, " Why Getter and Setter Methods Are Evil," discussed the downside of the getter/setter idiom. That article presented a design-level solution. (By keeping your design in the problem domain as long as possible and using…
🔥3👍1
💬 "Sometimes, to improve performance, or more likely to tighten security, queries may be implemented on the server as stored procedures. In that case, the SPECIFICATION could carry only the parameters allowed by the stored procedure. For all that, there is no difference in the model between these various implementations. The choice of implementation is free except where specifically constrained by the model. The price comes in a more cumbersome way of writing and maintaining queries.
This discussion barely scratches the surface of the challenges of combining SPECIFICATIONS with databases, and I'll make no attempt to cover all the considerations that may arise. I just want to give a taste of the kind of choices that have to be made."
— "Domain-Driven Design: Tackling Complexity in the Heart of Software" by Eric Evans
Вот так примерно отвечает интеллигентный человек на нечто подобное тому, что в свое время сделала компания LinguaLeo.
#DDD #SoftwareDesign
This discussion barely scratches the surface of the challenges of combining SPECIFICATIONS with databases, and I'll make no attempt to cover all the considerations that may arise. I just want to give a taste of the kind of choices that have to be made."
— "Domain-Driven Design: Tackling Complexity in the Heart of Software" by Eric Evans
Вот так примерно отвечает интеллигентный человек на нечто подобное тому, что в свое время сделала компания LinguaLeo.
#DDD #SoftwareDesign
👍3😁2
Все основные RFC по LDAP в одном месте:
- https://gitlab.com/samba-team/samba/-/tree/master/source4/ldap_server/devdocs
- https://pro-ldap.ru/tr/rfc/ (с переводами)
- https://ldap.com/ldap-related-rfcs/
- https://www.opennet.ru/docs/RUS/ldap_apacheds/apc/
- https://metacpan.org/dist/perl-ldap/view/lib/Net/LDAP/RFC.pod
- https://ldapwiki.com/wiki/LDAP%20Server%20Standards%20and%20Specifications
#LDAP
- https://gitlab.com/samba-team/samba/-/tree/master/source4/ldap_server/devdocs
- https://pro-ldap.ru/tr/rfc/ (с переводами)
- https://ldap.com/ldap-related-rfcs/
- https://www.opennet.ru/docs/RUS/ldap_apacheds/apc/
- https://metacpan.org/dist/perl-ldap/view/lib/Net/LDAP/RFC.pod
- https://ldapwiki.com/wiki/LDAP%20Server%20Standards%20and%20Specifications
#LDAP
GitLab
source4/ldap_server/devdocs · master · The Samba Team / Samba · GitLab
https://gitlab.com/samba-team/samba is the Official GitLab mirror of Samba https://www.samba.org
Forwarded from Evgenia
🔥22👎1🤩1