tgoop.com »
United States »
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc. » Telegram Web
Forwarded from Event Storming (Sergey Baranov)
Пример того, как отобразить выгрузку из внешней системы (и в целом интеграцию) в терминах предметной области.
👍5👎4🔥1🤔1
This media is not supported in your browser
VIEW IN TELEGRAM
Вот таким должен быть архитектор. Я уже говорил ранее, что архитектор выполняет хищнические функции. И подобно этому орлу, он так же гордо должен расправляться с legacy и с несоответствующими решениями.
👍5🔥4😁3🤯3😱1
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
Бомбовый инструмент управления проектами на простых текстовых файлах. Попробовал - остался в восторге. И уже начал использовать его. - https://github.com/taskjuggler/TaskJuggler Не хватает только работы со среднеквадратичным отклонением оценки (но этим вообще…
Project-Open
TaskJuggler Integration
Project Management, Project Portfolio Management, ERP, Financial Management, Professional Service Automation, Knowledge Management, Workflow, Project Collaboration, Business Process Automatization, Information Management, Invoicing
🔥2👍1
Forwarded from Systems.Education: Анализ и проектирование информационных систем, архитектура, интеграции, бизнес-процессы (Denis Beskov Systems.Education)
Выпустили перевод 5-й главы
Designing Data-Intensive Appications Клеппмана
Репликация база данных
https://systems.education/ddia-replication
что там:
Лидеры и последователи
— Синхронная и асинхронная репликация
— Настройка новых последователей
— Обработка отказов узлов
— Внедрение журналов репликации
Проблемы с задержкой в репликации
— Чтение собственных записей
— Монотонное чтение
— Чтения с согласованным префиксом
— Решения для задержек в репликации
Репликация с несколькими лидерами
— Варианты использования для репликации с несколькими лидерами
— Топологии репликации с несколькими лидерами
Репликация без лидера
— Запись в базу данных, когда узел недоступен
— Ограничения согласованности кворума
— Нестрогие кворумы и направленная передача
— Обнаружение совпадающих записей
#базы_данных #репликация #статьи #книги #переводы
Designing Data-Intensive Appications Клеппмана
Репликация база данных
https://systems.education/ddia-replication
что там:
Лидеры и последователи
— Синхронная и асинхронная репликация
— Настройка новых последователей
— Обработка отказов узлов
— Внедрение журналов репликации
Проблемы с задержкой в репликации
— Чтение собственных записей
— Монотонное чтение
— Чтения с согласованным префиксом
— Решения для задержек в репликации
Репликация с несколькими лидерами
— Варианты использования для репликации с несколькими лидерами
— Топологии репликации с несколькими лидерами
Репликация без лидера
— Запись в базу данных, когда узел недоступен
— Ограничения согласованности кворума
— Нестрогие кворумы и направленная передача
— Обнаружение совпадающих записей
#базы_данных #репликация #статьи #книги #переводы
systems.education
Глава 5. Репликация баз данных. Проектирование высоконагруженных приложений. Мартин Клеппман
.Лидеры и последователи. Проблемы с задержкой в репликации. Репликация с несколькими лидерами
🔥5❤1👍1
Автор книги в представлении не нуждается:
https://www.tgoop.com/nikitapinchuk/309
https://www.tgoop.com/nikitapinchuk/309
Telegram
Nikita Pinchuk professional channel: IT / EA / BA / Architecture
Рефлексия,понимание и мышление в групповой интеллектуальной деятельности.
🔥2👍1
Forwarded from Alexey Neznanov
Именно. На всякий случай краткая борьба с мифами - Dr Cookie and Mr Token - Web Session Implementations and How to Live with Them (https://www.dais.unive.it/~calzavara/papers/itasec18.pdf)
🔥1
Очень интересное обсуждение получилось в чате @ru_arc_chat на тему организации аутентификации в распределенной среде с использованием IAM и BFF/API-Gateway.
🔥4
Forwarded from Евгений Козлов пишет про IT (Eugene Kozlov)
Бесплатная книга по алгоритмам и структурам данных на Python.
Раз уж начал делать посты про алгосики расскажу и про свою недавнюю находку. Офигенная бесплатная книга по алгоритмам. Коротко ознакомившись пришел к выводу что ее можно советовать к ознакомлению всем: и начинающим и опытным😇
Какие темы внутри:
- база Python
- Big O notation
- АТД (Стеки, очереди)
- Рекурсия
- Сортировка и поиск
- Деревья, Графы
По своему опыту могу сказать что представленных тем должно хватить для того чтобы пройти собес в большинство компаний РФ
Приятно, что сайт интерактивный, примеры можно запускать в браузере. А значит можно учиться буквально сразу🙃
Версия на русском
Раз уж начал делать посты про алгосики расскажу и про свою недавнюю находку. Офигенная бесплатная книга по алгоритмам. Коротко ознакомившись пришел к выводу что ее можно советовать к ознакомлению всем: и начинающим и опытным😇
Какие темы внутри:
- база Python
- Big O notation
- АТД (Стеки, очереди)
- Рекурсия
- Сортировка и поиск
- Деревья, Графы
По своему опыту могу сказать что представленных тем должно хватить для того чтобы пройти собес в большинство компаний РФ
Приятно, что сайт интерактивный, примеры можно запускать в браузере. А значит можно учиться буквально сразу🙃
Версия на русском
runestone.academy
Problem Solving with Algorithms and Data Structures using Python — Problem Solving with Algorithms and Data Structures
An interactive version of Problem Solving with Algorithms and Data Structures using Python.
🔥8
"Исследование компании / процесса / продукта …", Сергей Баранов
Блог ScrumTrek
Исследование компании / процесса / продукта … — статья в блоге ScrumTrek
Обратил внимание, что на эту тему очень мало материалов в сети и решил в общих чертах поделиться, как мы проводим комплексное исследование под задачи заказчика.
🔥4
Я решил провести эксперимент, и сделал закрытую тг-группу для специалистов, которым я доверяю как самому себе, и доверил бы им разработку проекта за собственные инвестиции. С некоторыми из них я работал лично на предыдущих проектах, остальные попали в неё по поручительству тех, кому я доверяю. Почти все они выросли из разработки и занимают сейчас ответственные руководящие или архитектурные должности в крупных высокотехнологичных компаниях.
Некоторые из ребят создавали высоконагруженные системы, функционирование которых находилось в поле зрения первых лиц государства и осуществлялось в условиях систематических атак.
Основная специализация ребят: MSA, DDD, CQRS/ES, Clean Architecture, IoT, распределенные системы, системная архитектура, управление SDLC процессами разработки, антикризисное управление. Есть немного AI/ML.
Принципы, которые объединяют участников группы: взаимовыручка, грамотность, профессиональная репутация и уменье.
У группы есть тг-бот @krew_solutions_bot , через который участникам группы можно напрямую написать запрос на услуги Consulting, Enabling, Audit, Outstuff, Outsource, Part-time.
Это не сервер трудоустройства, поэтому, пожалуйста, не нужно никого хантить на Full-time.
Если один из группы берется за предложение, то он в праве рассчитывать на неограниченную информационную поддержку остальных участников группы.
Некоторые из ребят создавали высоконагруженные системы, функционирование которых находилось в поле зрения первых лиц государства и осуществлялось в условиях систематических атак.
Основная специализация ребят: MSA, DDD, CQRS/ES, Clean Architecture, IoT, распределенные системы, системная архитектура, управление SDLC процессами разработки, антикризисное управление. Есть немного AI/ML.
Принципы, которые объединяют участников группы: взаимовыручка, грамотность, профессиональная репутация и уменье.
У группы есть тг-бот @krew_solutions_bot , через который участникам группы можно напрямую написать запрос на услуги Consulting, Enabling, Audit, Outstuff, Outsource, Part-time.
Это не сервер трудоустройства, поэтому, пожалуйста, не нужно никого хантить на Full-time.
Если один из группы берется за предложение, то он в праве рассчитывать на неограниченную информационную поддержку остальных участников группы.
🔥29❤3
Forwarded from Михаил
https://www.codetinkerer.com/2015/12/04/choosing-an-http-status-code.html - прекрасная статья чтобы помочь определиться со статус-кодом "как мы обычно делаем".
по-прежнему ищу статьи про "всегда 200".
по-прежнему ищу статьи про "всегда 200".
codetinkerer.com
Choosing an HTTP Status Code — Stop Making It Hard
What could be simpler than returning HTTP status codes? Did the page render? Great, return 200. Does the page not exist? That’s a 404. Do I want to redirect the user to another page? 302, or maybe 301. I like to imagine that HTTP status codes are like CB…
❤12
💬 Одной из проблем при найме разработчиков является заблуждение о небольшом разбросе в их квалификации – ошибочное мнение, будто программисты не слишком отличаются друг от друга (с точки зрения производительности, качества кода и т. д.). Но исследования показывают, что верхний квартиль по уровню квалификации способен работать примерно вчетверо быстрее, чем нижний [Prechelt00]. Довольно большая разница, согласитесь. Кроме того, модель COCOMO, основанная на многолетних масштабных исследованиях, показывает, что уровень квалификации группы разработчиков – наиболее важный из всех факторов, влияющих на ее производительность [Boehm00]. Наконец, очень слабые программисты в среднем создают код худшего качества (с плохим дизайном) и с большим количеством дефектов, что дополнительно тормозит всю систему.
Но все эти влияния проявляются не немедленно, а с некоторым запозданием. Например, если вы наймете много слабых разработчиков, пройдет относительно много времени, прежде чем начнут ощущаться последствия их плохой работы / некачественного кода. Соответственно среднее снижение скорости поставки новой функциональности (вызванное сильным влиянием разброса квалификации программистов) произойдет не сразу, а спустя какое-то время.
Отложенный характер эффектов негативно влияет на способность системы к обучению и коррекции. Если результат или случайное следствие какого-либо действия проявляется с большой задержкой во времени, люди часто не видят (причинно-следственной) связи между ними, не понимают, что именно A повлияло на Б или, еще сложнее, что A повлияло на Б, а Б в ответ повлияло на А.
Следовательно, люди не учатся и не исправляют ошибки – в правилах, управленческих действиях, инструментах и т. д. Именно из-за отложенных эффектов постепенное улучшение через практику бережливого подхода кайдзен может занимать длительное время: чтобы увидеть, улучшается ли что-то и как, требуется терпение и способность проникать в суть вещей.
-- "Масштабированный скрам. Как организовать гибкую разработку в крупной компании" / Бас Водде, Крэг Ларман, перевод Ирина Евстигнеева
Но все эти влияния проявляются не немедленно, а с некоторым запозданием. Например, если вы наймете много слабых разработчиков, пройдет относительно много времени, прежде чем начнут ощущаться последствия их плохой работы / некачественного кода. Соответственно среднее снижение скорости поставки новой функциональности (вызванное сильным влиянием разброса квалификации программистов) произойдет не сразу, а спустя какое-то время.
Отложенный характер эффектов негативно влияет на способность системы к обучению и коррекции. Если результат или случайное следствие какого-либо действия проявляется с большой задержкой во времени, люди часто не видят (причинно-следственной) связи между ними, не понимают, что именно A повлияло на Б или, еще сложнее, что A повлияло на Б, а Б в ответ повлияло на А.
Следовательно, люди не учатся и не исправляют ошибки – в правилах, управленческих действиях, инструментах и т. д. Именно из-за отложенных эффектов постепенное улучшение через практику бережливого подхода кайдзен может занимать длительное время: чтобы увидеть, улучшается ли что-то и как, требуется терпение и способность проникать в суть вещей.
-- "Масштабированный скрам. Как организовать гибкую разработку в крупной компании" / Бас Водде, Крэг Ларман, перевод Ирина Евстигнеева
👍24
Петли положительной или отрицательной обратной связи[9] и отложенные эффекты – тонкие моменты, которые делают динамику системы еще более сложной и менее понятной. К примеру, как программисты могут повысить свой уровень квалификации? Один из способов – учиться у высококвалифицированных специалистов и видеть много примеров отличного кода. Но компания, в которой работает много (очень дешевых) программистов с низкой квалификацией, производит мало образцов качественного кода, а также не привлекает и не может удержать крутых программистов, которые могли бы играть роль наставников. Те скорее найдут работу в другом месте.
Таким образом, группа разработки входит в самоусиливающуюся нисходящую спираль – последовательность петель положительной обратной связи, где каждая петля усиливает последующую. К счастью, этот нисходящий тренд ограничен бюджетом.
Попробуйте… увидеть в системе петли положительной обратной связи.
По мере того как уходит все больше крутых разработчиков, которые могли бы создавать отличный код и обучать других, у слабых разработчиков становится все меньше возможностей для обучения. Процент слабых разработчиков растет, а качество кода и производительность падают все ниже. Код становится все более грязным, запутанным, с большим количеством повторений, что снижает способность группы быстро реализовывать новую функциональность. Падение скорости реализации новой функциональности вынуждает нанимать еще больше дешевых разработчиков. Короче, в системе создается множество самоусиливающихся петель положительной обратной связи.
-- "Масштабированный скрам. Как организовать гибкую разработку в крупной компании" / Бас Водде, Крэг Ларман, перевод Ирина Евстигнеева
Таким образом, группа разработки входит в самоусиливающуюся нисходящую спираль – последовательность петель положительной обратной связи, где каждая петля усиливает последующую. К счастью, этот нисходящий тренд ограничен бюджетом.
Попробуйте… увидеть в системе петли положительной обратной связи.
По мере того как уходит все больше крутых разработчиков, которые могли бы создавать отличный код и обучать других, у слабых разработчиков становится все меньше возможностей для обучения. Процент слабых разработчиков растет, а качество кода и производительность падают все ниже. Код становится все более грязным, запутанным, с большим количеством повторений, что снижает способность группы быстро реализовывать новую функциональность. Падение скорости реализации новой функциональности вынуждает нанимать еще больше дешевых разработчиков. Короче, в системе создается множество самоусиливающихся петель положительной обратной связи.
-- "Масштабированный скрам. Как организовать гибкую разработку в крупной компании" / Бас Водде, Крэг Ларман, перевод Ирина Евстигнеева
🔥13👍7
"Чтобы жизнь тебя устраивала, сначала устрой её. Иначе она устроит тебя не туда, куда тебя устраивает." — Стас Янковский
Невероятно меткое определение ключевой сути деятельности ИТ-специалиста. Как говорится, если Вы не занимаетесь архитектурой, то архитектура займется вами.
На каждом новом проекте в течении всей своей практики я начинал с того, что создавал себе (и другим) условия работы.
Вначале я научился писать высокоэффективный код. Это когда код качественный и пишется быстро.
Но этого оказалось недостаточно, потому что код пишется в коллективе, и независимо от того, какой код пишешь ты, работать нужно с кодом, который пишут другие. Пришлось развивать в себе учителя и наставника.
Потом я понял, что нужно уметь формировать над командой защитный зонтик, чтоб они умели применять навыки в реальных условиях давления бизнеса. Бизнесу нужно быстро, команде нужно качественно, что означает тоже быстро, но завтра. Но бизнес это не всегда понимает. Найти баланс помогла книга "Extreme Programming Explained" 1st edition by Kent Beck.
Потом я понял, что крутой специалист может изменить все, кроме процессов. И именно безграмотно организованные процессы являются основной причиной утраты наиболее ценных специалистов, что обрело устойчивый термин "голосование ногами". И я начал изучать SDLC.
Потом понял, что для того, чтоб изменить процессы, нужно овладеть управленческой и коммуникативной психологией, а также теорией внедрения изменений.
В принципе, я уже излагал эту историю здесь.
Невероятно меткое определение ключевой сути деятельности ИТ-специалиста. Как говорится, если Вы не занимаетесь архитектурой, то архитектура займется вами.
На каждом новом проекте в течении всей своей практики я начинал с того, что создавал себе (и другим) условия работы.
Вначале я научился писать высокоэффективный код. Это когда код качественный и пишется быстро.
Но этого оказалось недостаточно, потому что код пишется в коллективе, и независимо от того, какой код пишешь ты, работать нужно с кодом, который пишут другие. Пришлось развивать в себе учителя и наставника.
Потом я понял, что нужно уметь формировать над командой защитный зонтик, чтоб они умели применять навыки в реальных условиях давления бизнеса. Бизнесу нужно быстро, команде нужно качественно, что означает тоже быстро, но завтра. Но бизнес это не всегда понимает. Найти баланс помогла книга "Extreme Programming Explained" 1st edition by Kent Beck.
Потом я понял, что крутой специалист может изменить все, кроме процессов. И именно безграмотно организованные процессы являются основной причиной утраты наиболее ценных специалистов, что обрело устойчивый термин "голосование ногами". И я начал изучать SDLC.
Потом понял, что для того, чтоб изменить процессы, нужно овладеть управленческой и коммуникативной психологией, а также теорией внедрения изменений.
В принципе, я уже излагал эту историю здесь.
👍29🔥4❤🔥3👏2🤯1
Чем отличается User Story от Task? Написать пост на эту тему меня потдолкнула недавно опубликованная ссылка на статью о техдолге в чате канала, а именно эти строки:
💬 "Doubtful developers may say, “But what if management deprioritizes or discards the technical debt subitems?”"
В целом статья неплохая, но есть нюанс. Как говорил человек, который создал роль Product Owner и Scrum-Master:
💬 "So I split the role in two, giving the Scrum Master the how and the Product Owner the what.
<...>
The Scrum Master and the team are responsible for how fast they're going and how much faster they can get. The Product Owner is accountable for translating the team's productivity into value."
—"Scrum: The Art of Doing Twice the Work in Half the Time" by Jeffrey Sutherland
Именно команда ответственна за скорость разработки. А скорость разработки напрямую зависит от внутреннего качества программы, т.е. за Software Design. Говоря архитектурным языком, команда отвечает за Quality Attribute Modifiability.
Product Owner описывает в User Story функциональный инкремент, в то время как команда декомпозирует его на Tasks, которые описывают системный инкремент.
Одна и та же функция может поддерживаться различными вариантами конструкций.
В качестве подпорки под дверь можно использовать конструкцию в виде камня, а можно и в виде книги.
И, наоборот, одна и та же конструкция может выполнять разные функции. Например, тот же камень можно использовать в качестве функции якоря, или орехи им колоть. Это т.н. дихотомия функции и конструкции.
Конструкция может совпадать с функцией, а может не совпадать. Как и Bounded Context (Solution Space) может совпадать с Subdomain (Problem Space), а может не совпадать.
На простом примере: у ножниц два функциональных компонента, один - чтоб держать, а другой - чтоб резать. Но конструктивно ножницы состоят их двух половинок и гвоздика. Иногда конструктивный элемент называют модулем, а функциональный - компонентом.
Но вернемся к User Story. Поясню на примере. Камень сам по себе бесполезен для разжигания костра. Два камня бесполезны сами по себе. Но два камня во взаимодействии могут высекать искру. У них появилось новое, emergent свойство, т.е. они образовали систему. Система обладает свойствами, которыми её элементы по отдельности не обладают.
Так вот, Product Owner пишет "нужна искра". Это функциональный инкремент, добавляющий новую, видимую функциональность в систему, которую можно протестировать приёмочными тестами уровня компонентных или сквозных тестов.
Отдельно взятый камень протестировать на уровне компонента или системы нельзя, т.к. он сам по себе не обладает emergent свойствами. Они появятся только тогда, когда будут завершены все необходимые системные инкременты, которые образуют систему.
Product Owner не пишет в User Story "взять один камень, взять другой камень". Это пишет команда в Tasks, на которые декомпозируется User Story. Product Owner отвечат за функцию, а команда - за конструкцию.
Это нерушимое правило, нарушение которого приводит к накоплению техдолга и к деградации темпов разработки, что, в свою очередь, приводит к утрате экономической целесообразности итеративной разработки, поскольку внесение изменений становится дороже заблаговременного проектирования. На эту тему есть у меня хороший Long Read.
Команда не должна согласовывать с Product Owner системный инкремент. Вот что по этому поводу говорит Open Agile Architecture Standard:
💬 Fowler would strongly promote the view that code refactoring requires no justification; rather it is part of a developer's "day job". This does not mean that we have to take on a massive code restructuring exercise for a legacy codebase; on the contrary, there may be no reason whatsoever to restructure the code for a stable legacy project. However, that said, developers should refactor their code when the opportunity arises.
—"Open Agile Architecture™" by The Open Group, Chapter "6.5.1. Justifying Ongoing Investment in Architectural Refactoring"
Подробнее здесь.
Но тут есть еще один нюанс, о котором - в следующем посте.
💬 "Doubtful developers may say, “But what if management deprioritizes or discards the technical debt subitems?”"
В целом статья неплохая, но есть нюанс. Как говорил человек, который создал роль Product Owner и Scrum-Master:
💬 "So I split the role in two, giving the Scrum Master the how and the Product Owner the what.
<...>
The Scrum Master and the team are responsible for how fast they're going and how much faster they can get. The Product Owner is accountable for translating the team's productivity into value."
—"Scrum: The Art of Doing Twice the Work in Half the Time" by Jeffrey Sutherland
Именно команда ответственна за скорость разработки. А скорость разработки напрямую зависит от внутреннего качества программы, т.е. за Software Design. Говоря архитектурным языком, команда отвечает за Quality Attribute Modifiability.
Product Owner описывает в User Story функциональный инкремент, в то время как команда декомпозирует его на Tasks, которые описывают системный инкремент.
Одна и та же функция может поддерживаться различными вариантами конструкций.
В качестве подпорки под дверь можно использовать конструкцию в виде камня, а можно и в виде книги.
И, наоборот, одна и та же конструкция может выполнять разные функции. Например, тот же камень можно использовать в качестве функции якоря, или орехи им колоть. Это т.н. дихотомия функции и конструкции.
Конструкция может совпадать с функцией, а может не совпадать. Как и Bounded Context (Solution Space) может совпадать с Subdomain (Problem Space), а может не совпадать.
На простом примере: у ножниц два функциональных компонента, один - чтоб держать, а другой - чтоб резать. Но конструктивно ножницы состоят их двух половинок и гвоздика. Иногда конструктивный элемент называют модулем, а функциональный - компонентом.
Но вернемся к User Story. Поясню на примере. Камень сам по себе бесполезен для разжигания костра. Два камня бесполезны сами по себе. Но два камня во взаимодействии могут высекать искру. У них появилось новое, emergent свойство, т.е. они образовали систему. Система обладает свойствами, которыми её элементы по отдельности не обладают.
Так вот, Product Owner пишет "нужна искра". Это функциональный инкремент, добавляющий новую, видимую функциональность в систему, которую можно протестировать приёмочными тестами уровня компонентных или сквозных тестов.
Отдельно взятый камень протестировать на уровне компонента или системы нельзя, т.к. он сам по себе не обладает emergent свойствами. Они появятся только тогда, когда будут завершены все необходимые системные инкременты, которые образуют систему.
Product Owner не пишет в User Story "взять один камень, взять другой камень". Это пишет команда в Tasks, на которые декомпозируется User Story. Product Owner отвечат за функцию, а команда - за конструкцию.
Это нерушимое правило, нарушение которого приводит к накоплению техдолга и к деградации темпов разработки, что, в свою очередь, приводит к утрате экономической целесообразности итеративной разработки, поскольку внесение изменений становится дороже заблаговременного проектирования. На эту тему есть у меня хороший Long Read.
Команда не должна согласовывать с Product Owner системный инкремент. Вот что по этому поводу говорит Open Agile Architecture Standard:
💬 Fowler would strongly promote the view that code refactoring requires no justification; rather it is part of a developer's "day job". This does not mean that we have to take on a massive code restructuring exercise for a legacy codebase; on the contrary, there may be no reason whatsoever to restructure the code for a stable legacy project. However, that said, developers should refactor their code when the opportunity arises.
—"Open Agile Architecture™" by The Open Group, Chapter "6.5.1. Justifying Ongoing Investment in Architectural Refactoring"
Подробнее здесь.
Но тут есть еще один нюанс, о котором - в следующем посте.
🔥13👍2
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
Чем отличается User Story от Task? Написать пост на эту тему меня потдолкнула недавно опубликованная ссылка на статью о техдолге в чате канала, а именно эти строки: 💬 "Doubtful developers may say, “But what if management deprioritizes or discards the technical…
Распределение функций между командой и Product Owner работает только тогда, когда достигается цель - поддержание постоянства скорости разработки по мере роста размеров системы. Иными словами, когда команда достаточно грамотна в Software Design. Именно об этом говорит принцип Agile Manifesto:
🔷 "Continuous attention to technical excellence and good design enhances agility."
Именно поэтому, на Snowbird Meeting присутствовал весь архитектурный бомонд того времени. Именно поэтому Agile был создан архитекторами.
Что произойдет, если команда недостаточно подготовлена по Software Design? Кодовая база будет загнивать, темпы разработки будут деградировать, команда утратит доверие со стороны Product Owner, и Product Owner начнет возводить защитные стены от команды, затягивая в свою зону ответственности все решения по системному инкременту. Иными словами, он начнет указывать команде не только то, "что" нужно сделать в User Story, но и "как" команда должна это реализовать. Т.е. возникнет ситуация, описанная в начале предыдущего поста.
Звучать это будет примерно так: "давайте пока поставим костыль, а потом исправим". Естественно, это "потом" никогда не наступит.
Команда тоже начнет возводить свою защитную стену, и начнет твердить, что все нужно сжечь и переписать. И возможно, команда даже уговорит Product Owner, и он выделит ресурсы, но через пару месяцев все снова сгниет. Потому что код или самоочищается, если команда знает Software Design, или загнивает.
Каждая сторона отгородилась от другой стороны непробиваемой стеной. Ключевая цель Agile утрачена. Agile больше не выполняет своих функций.
В моем списке литературы приводятся 5 книг, без которых остается мало шансов организовать эффективную разработку и завоевать доверие Product Owner.
Молодые специалисты часто думают, что они придут в компанию, и их научат работать. В подавляющем большинстве случаев их научат тому, как не нужно строить системы. Практически все известные мне крутые специалисты сформировались не благодаря условиям работы, а вопреки им.
🔷 "Continuous attention to technical excellence and good design enhances agility."
Именно поэтому, на Snowbird Meeting присутствовал весь архитектурный бомонд того времени. Именно поэтому Agile был создан архитекторами.
Что произойдет, если команда недостаточно подготовлена по Software Design? Кодовая база будет загнивать, темпы разработки будут деградировать, команда утратит доверие со стороны Product Owner, и Product Owner начнет возводить защитные стены от команды, затягивая в свою зону ответственности все решения по системному инкременту. Иными словами, он начнет указывать команде не только то, "что" нужно сделать в User Story, но и "как" команда должна это реализовать. Т.е. возникнет ситуация, описанная в начале предыдущего поста.
Звучать это будет примерно так: "давайте пока поставим костыль, а потом исправим". Естественно, это "потом" никогда не наступит.
Команда тоже начнет возводить свою защитную стену, и начнет твердить, что все нужно сжечь и переписать. И возможно, команда даже уговорит Product Owner, и он выделит ресурсы, но через пару месяцев все снова сгниет. Потому что код или самоочищается, если команда знает Software Design, или загнивает.
Каждая сторона отгородилась от другой стороны непробиваемой стеной. Ключевая цель Agile утрачена. Agile больше не выполняет своих функций.
В моем списке литературы приводятся 5 книг, без которых остается мало шансов организовать эффективную разработку и завоевать доверие Product Owner.
Молодые специалисты часто думают, что они придут в компанию, и их научат работать. В подавляющем большинстве случаев их научат тому, как не нужно строить системы. Практически все известные мне крутые специалисты сформировались не благодаря условиям работы, а вопреки им.
Telegram
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
Чем отличается User Story от Task? Написать пост на эту тему меня потдолкнула недавно опубликованная ссылка на статью о техдолге в чате канала, а именно эти строки:
💬 "Doubtful developers may say, “But what if management deprioritizes or discards the technical…
💬 "Doubtful developers may say, “But what if management deprioritizes or discards the technical…
🔥16👍5❤4
Публикуемое интеграционное событие - это:
Anonymous Poll
21%
Порт, т.е. внутренний интерфейс адаптера хексагональной/луковой архитектуры
79%
Это внешний интерфейс адаптера хексагональной архитектуры, а портом является доменное событие.
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
Публикуемое интеграционное событие - это:
Кто голосует за вариант 2, тот признает, что интеграционное событие должно находиться исключительно в инфраструктурном слое приложения. Соответственно, политика (Domain Event Hadler), создающая интеграционное событие, является адаптером, и тоже должна находиться в инфраструктурном слое. Соответственно, демонстрационное приложение от Microsoft содержало ошибку.
GitHub
eShopOnContainers/src/Services/Ordering/Ordering.API/Application/IntegrationEvents at main · dotnet-architecture/eShopOnContainers
Cross-platform .NET sample microservices and container based application that runs on Linux Windows and macOS. Powered by .NET 7, Docker Containers and Azure Kubernetes Services. Supports Visual St...
Принимаемое интеграционное событие - это:
Anonymous Poll
12%
Порт, т.е. внутренний интерфейс хексагональной архитектуры.
72%
Это внешний интерфейс хексагональной архитектуры, транслирущий событие в команду (т.е. в порт)
26%
Портом оно быть точно не может, т.к. событие принадлежит к доменной модели паблишера.