Forwarded from Russian Association of Software Architects (Ivan)
"Developer to Architect :: Training and resources for the journey from software developer to software architect"
by Mark Richards, Software Architect and Founder
- https://www.developertoarchitect.com/lessons/
#SoftwareArchitecture
by Mark Richards, Software Architect and Founder
- https://www.developertoarchitect.com/lessons/
#SoftwareArchitecture
Developertoarchitect
Software Architecture Monday | Developer to Architect | Mark Richards
Software Architecture Lessons
🔥12
Forwarded from Russian Association of Software Architects (Ivan)
Mo - Monads and popular FP abstractions, powered by Go 1.18+ Generics (Option, Result, Either...)
- https://github.com/samber/mo
#FunctionalProgramming #Golang
- https://github.com/samber/mo
#FunctionalProgramming #Golang
GitHub
GitHub - samber/mo: 🦄 Monads and popular FP abstractions, powered by Go 1.18+ Generics (Option, Result, Either...)
🦄 Monads and popular FP abstractions, powered by Go 1.18+ Generics (Option, Result, Either...) - samber/mo
🔥6👍1
Forwarded from Russian Association of Software Architects (Ivan)
На Snowbird meeting обсуждались принципы "Bill of Rights", один из которых гласит:
📝 "You [programmer] have the right to produce quality work at all times."
Причем:
📝 "During the Snowbird meeting, Kent Beck said that the goal of Agile was to heal the divide between business and development."
-- "Clean Agile: Back to Basics" by Robert C. Martin - организатор той встречи.
Недавно состоялся опрос, по результатам которого выяснилось, что 20% участников опроса демотивированы загниванием кода по причине отсутствия понимания со стороны Product Owner (Project Manager). Эту проблему хорошо освещали многие известные авторы: Kent Beck, Robert Martin, Jeff Sutherland, Martin Fowler, Craig Larman, Henrik Kniberg, Dean Leffingwell, Kenneth Rubin, Ward Cunningham и другие.
Как могло получиться, что, используя Agile, разработчики, вместо "produce quality work at all times", вынуждены копаться в коде, который по своей консистенции не сильно отличается от свалки? Терпения на такие "условия работы" хватает не у всех, что является одной из распространенных причин текучки кадров.
На эту тему было много написано, да мало делается. Недостаточная информированность технических специалистов делает из них легкую добычу психологических манипуляций, вынужденную принимать всю вину на свой счет, и непонимающую, как выйти из замкнутого круга. Отличительным симптомом такой ситуации являются постоянно "горящие" и вечно "сорванные" сроки, отсутствие взаимовыручки и перекладывание вины.
Это только одна из многих проблем, которые мы наблюдаем в отрасли, и для решения которых мы и решили объединить усилия в этом канале.
Знакома ли вам эта проблема? Удалось ли её решить? Каким образом?
#SoftwareDesign #SDLC
📝 "You [programmer] have the right to produce quality work at all times."
Причем:
📝 "During the Snowbird meeting, Kent Beck said that the goal of Agile was to heal the divide between business and development."
-- "Clean Agile: Back to Basics" by Robert C. Martin - организатор той встречи.
Недавно состоялся опрос, по результатам которого выяснилось, что 20% участников опроса демотивированы загниванием кода по причине отсутствия понимания со стороны Product Owner (Project Manager). Эту проблему хорошо освещали многие известные авторы: Kent Beck, Robert Martin, Jeff Sutherland, Martin Fowler, Craig Larman, Henrik Kniberg, Dean Leffingwell, Kenneth Rubin, Ward Cunningham и другие.
Как могло получиться, что, используя Agile, разработчики, вместо "produce quality work at all times", вынуждены копаться в коде, который по своей консистенции не сильно отличается от свалки? Терпения на такие "условия работы" хватает не у всех, что является одной из распространенных причин текучки кадров.
На эту тему было много написано, да мало делается. Недостаточная информированность технических специалистов делает из них легкую добычу психологических манипуляций, вынужденную принимать всю вину на свой счет, и непонимающую, как выйти из замкнутого круга. Отличительным симптомом такой ситуации являются постоянно "горящие" и вечно "сорванные" сроки, отсутствие взаимовыручки и перекладывание вины.
Это только одна из многих проблем, которые мы наблюдаем в отрасли, и для решения которых мы и решили объединить усилия в этом канале.
Знакома ли вам эта проблема? Удалось ли её решить? Каким образом?
#SoftwareDesign #SDLC
martinfowler.com
Writing The Agile Manifesto
A long-form article ennoscriptd: "Writing The Agile Manifesto"
🔥7👍4
Forwarded from Russian Association of Software Architects (Ivan)
"Help geeks feel safe in the world" - карьерная миссия Kent Beck очень близка целям нашего объединения. На прошлой неделе он посвятил этому вопросу целую статью: "Help Geeks Feel Safe In The World: My Personal Mission".
Роль Kent Beck в индустрии сложно переоценить: Design Patterns, xUnit, TDD, Refactoring, Extreme Programming и существенное влияние на Agile Manifesto. Невероятно эрудированный человек, обладающий редкой способностью объяснять сложные вещи простым языком.
#Goal
Роль Kent Beck в индустрии сложно переоценить: Design Patterns, xUnit, TDD, Refactoring, Extreme Programming и существенное влияние на Agile Manifesto. Невероятно эрудированный человек, обладающий редкой способностью объяснять сложные вещи простым языком.
#Goal
Medium
Help Geeks Feel Safe In The World: My Personal Mission
Twenty five years into my career and I finally figured out my mission. This was after patterns, after xUnit, after TDD, after Extreme…
🔥4👍2
Forwarded from Russian Association of Software Architects (Ivan)
Мы продолжаем информировать вас о целях нашего объединения, поскольку, как говорится, важно не объединение само по себе, а те принципы, на которых оно основано. Сообщения о наших целях мы будем помечать тегом #Goal .
Как говорил Gregor Hohpe:
"There's a definite Dunning-Kruger effect for authors.
The people who hold a ton of knowledge hesitate because they find their insights "obvious" or "nothing special".
Then you have people who write a lot but do little real work that they could base their writing on..."
Это формирует противоречие в информационном пространстве, которое мы наблюдаем. С одной стороны - перегруженность и захламленность информационного пространства. С другой стороны - стесненность ресурсов времени практикующих специалистов на отсев информационных помех и поиск релевантной информации.
Поэтому, мы видим свою задачу в выявлении и поддержке перспективных авторов, блогеров и докладчиков, в объединении их усилий в авторском коллективе этого канала и объединенного архитектурного руководства, призванного облегчить навигацию в информационном пространстве. А также в организации серии митапов с их участием.
Наш принцип: практикующий специалист имеет право на легкий доступ к качественной информации. И это право не должно ущемляться правом других на свободу распространения информации.
#Goal
Как говорил Gregor Hohpe:
"There's a definite Dunning-Kruger effect for authors.
The people who hold a ton of knowledge hesitate because they find their insights "obvious" or "nothing special".
Then you have people who write a lot but do little real work that they could base their writing on..."
Это формирует противоречие в информационном пространстве, которое мы наблюдаем. С одной стороны - перегруженность и захламленность информационного пространства. С другой стороны - стесненность ресурсов времени практикующих специалистов на отсев информационных помех и поиск релевантной информации.
Поэтому, мы видим свою задачу в выявлении и поддержке перспективных авторов, блогеров и докладчиков, в объединении их усилий в авторском коллективе этого канала и объединенного архитектурного руководства, призванного облегчить навигацию в информационном пространстве. А также в организации серии митапов с их участием.
Наш принцип: практикующий специалист имеет право на легкий доступ к качественной информации. И это право не должно ущемляться правом других на свободу распространения информации.
#Goal
👍11🔥4
Forwarded from Russian Association of Software Architects (Ivan)
Список рекомендуемой литературы от Gregor Hohpe:
1. "The Architect's Path (Part 1 - Model)"
2. "The Architect's Path (Part 2 - Implementation)"
#SoftwareArchitecture
1. "The Architect's Path (Part 1 - Model)"
2. "The Architect's Path (Part 2 - Implementation)"
#SoftwareArchitecture
🔥7👍3
Forwarded from Russian Association of Software Architects (Gennadiy Kruglov)
Это ресурсы для 1-ой очереди изучения, то есть базовые, необходимые в первую очередь.
В перечне только актуальные и "свежие" ресурсы, за исключением (древней) книги Эванса по DDD. Эта книга по-прежнему полностью актуальна
Блоги:
https://martin.kleppmann.com/
https://berndruecker.io/
https://architectelevator.com/
Каталоги паттернов:
https://www.enterpriseintegrationpatterns.com/
https://microservices.io/
Базовые знания:
https://www.amazon.com/Designing-Data-Intensive-Applications-Reliable-Maintainable-ebook/dp/B06XPJML5D/
https://www.amazon.com/Balancing-Coupling-Software-Design-Addison-wesley/dp/0137353480
DDD:
https://www.amazon.com/Domain-Driven-Design-Tackling-Complexity-Software-ebook/dp/B00794TAUG/
https://www.amazon.com/Learning-Domain-Driven-Design-Aligning-Architecture/dp/1098100131/
Микросервисная архитектура:
https://www.amazon.com/Microservices-Patterns-examples-Chris-Richardson/dp/1617294543/
Workflow Management:
https://www.amazon.com/Practical-Process-Automation-Orchestration-Microservices/dp/149206145X/
Исследование предметной области:
https://www.eventstorming.com/
Архитектурные фреймворки:
https://pubs.opengroup.org/architecture/o-aa-standard/
Методологии разработки и орг архитектура:
https://teamtopologies.com/
Важнейшие статьи:
https://martinfowler.com/articles/architect-elevator.html
https://martinfowler.com/bliki/MonolithFirst.html
https://martinfowler.com/bliki/SacrificialArchitecture.html
В перечне только актуальные и "свежие" ресурсы, за исключением (древней) книги Эванса по DDD. Эта книга по-прежнему полностью актуальна
Блоги:
https://martin.kleppmann.com/
https://berndruecker.io/
https://architectelevator.com/
Каталоги паттернов:
https://www.enterpriseintegrationpatterns.com/
https://microservices.io/
Базовые знания:
https://www.amazon.com/Designing-Data-Intensive-Applications-Reliable-Maintainable-ebook/dp/B06XPJML5D/
https://www.amazon.com/Balancing-Coupling-Software-Design-Addison-wesley/dp/0137353480
DDD:
https://www.amazon.com/Domain-Driven-Design-Tackling-Complexity-Software-ebook/dp/B00794TAUG/
https://www.amazon.com/Learning-Domain-Driven-Design-Aligning-Architecture/dp/1098100131/
Микросервисная архитектура:
https://www.amazon.com/Microservices-Patterns-examples-Chris-Richardson/dp/1617294543/
Workflow Management:
https://www.amazon.com/Practical-Process-Automation-Orchestration-Microservices/dp/149206145X/
Исследование предметной области:
https://www.eventstorming.com/
Архитектурные фреймворки:
https://pubs.opengroup.org/architecture/o-aa-standard/
Методологии разработки и орг архитектура:
https://teamtopologies.com/
Важнейшие статьи:
https://martinfowler.com/articles/architect-elevator.html
https://martinfowler.com/bliki/MonolithFirst.html
https://martinfowler.com/bliki/SacrificialArchitecture.html
👍17🔥2
Forwarded from Russian Association of Software Architects (Ivan Zakrevsky)
В последнее время многие обсуждают DDD, но не все понимают что это такое. От этого страдает качество подобных обсуждений. И найти внятное определение DDD в литературе, действительно, непросто. Ниже приводится определение DDD от первоисточника:
I. Putting the Model to Work
Domain-Driven Design is an approach to the development of complex software in which we:
1. Focus on the core domain.
2. Explore models in a creative collaboration of domain practitioners and software practitioners.
3. Speak a ubiquitous language within an explicitly bounded context.
This three-point summary of DDD depends on the definition of the terms, which are defined in this booklet.
Many projects do modeling work without getting much real benefit in the end. The patterns of DDD distill successful practices from projects where dramatic benefits have come from modeling. Taken together, they lay out a quite different approach to modeling and software development that runs from fine details to high-level vision. Rigorous modeling conventions must be balanced with free exploration of models in collaboration with non-technical people.
Tactics and strategy must be combined to succeed, and DDD addresses both tactical and strategic design.
-- "Domain-Driven Design Reference" by Eric Evans
#DDD
I. Putting the Model to Work
Domain-Driven Design is an approach to the development of complex software in which we:
1. Focus on the core domain.
2. Explore models in a creative collaboration of domain practitioners and software practitioners.
3. Speak a ubiquitous language within an explicitly bounded context.
This three-point summary of DDD depends on the definition of the terms, which are defined in this booklet.
Many projects do modeling work without getting much real benefit in the end. The patterns of DDD distill successful practices from projects where dramatic benefits have come from modeling. Taken together, they lay out a quite different approach to modeling and software development that runs from fine details to high-level vision. Rigorous modeling conventions must be balanced with free exploration of models in collaboration with non-technical people.
Tactics and strategy must be combined to succeed, and DDD addresses both tactical and strategic design.
-- "Domain-Driven Design Reference" by Eric Evans
#DDD
Domain Language
DDD Reference - Domain Language
A summary of the patterns and definitions of DDD. This document is meant as a convenient reference for those who know the principles of Domain-Driven Design (DDD). It does not contain full explanations of DDD or even of the terms and patterns covered. It…
👍4🔥2
Forwarded from Russian Association of Software Architects (Ivan Zakrevsky)
Пять монументальных статей о размере микросервиса:
- "Microservices and [Micro]services" by Vaughn Vernon
- "Monolith -> Services: Theory & Practice" by Kent Beck
- "Tackling Complexity in Microservices" by Vladik Khononov
- "About Bounded Contexts and Microservices" by Alberto Brandolini
- "Размер микросервиса", Сергей Баранов
#DDD #MSA
- "Microservices and [Micro]services" by Vaughn Vernon
- "Monolith -> Services: Theory & Practice" by Kent Beck
- "Tackling Complexity in Microservices" by Vladik Khononov
- "About Bounded Contexts and Microservices" by Alberto Brandolini
- "Размер микросервиса", Сергей Баранов
#DDD #MSA
Kalele
Microservices and [Micro]services | Kalele
Kalele Vaughn Vernon discusses whether the size of a microservice matters. What do Domain-Driven Design Bounded Contexts have to do with Microservices.
🔥5👍3
Forwarded from Russian Association of Software Architects (Ivan Zakrevsky)
Читал на днях книгу Alberto Brandolini "Leanpub: Introducing EventStorming", где он говорит о распространенной ловушке моделирования агрегатов, когда на него возлагают функции Read Model:
📝 "A shopping cart will include the list of the items to be purchased, with the associated quantity and price.
Bread and butter, apparently, except that we now should be asking ourselves whether we need to include the
Hmmm… not. Sorry for the detour, but these are not the aggregates we’re looking for. “data to be displayed to a user in order to make a decision” will be a Read Model. Aggregates are something else, but we have to be aware of this vicious temptation of superimposing what we need to see on the screen on the internal structure of our model."
-- "Leanpub: Introducing EventStorming" by Alberto Brandolini
#DDD #Microservices
📝 "A shopping cart will include the list of the items to be purchased, with the associated quantity and price.
Bread and butter, apparently, except that we now should be asking ourselves whether we need to include the
ItemDenoscription in the ItemInCart. Feels like we should, because we’ll need to display the ShoppingCart info to the customer, in order to review the cart before proceeding to checkout “is this really the stuff you intended to buy? Have you looked at the grand total?”. Things might get awkward when starting to consider events like ItemPriceUpdated or ItemDenoscriptionUpdated, that should have us thinking whether we should include a copy of the entire denoscription of the selected item, or just a reference to the Item in stock.Hmmm… not. Sorry for the detour, but these are not the aggregates we’re looking for. “data to be displayed to a user in order to make a decision” will be a Read Model. Aggregates are something else, but we have to be aware of this vicious temptation of superimposing what we need to see on the screen on the internal structure of our model."
-- "Leanpub: Introducing EventStorming" by Alberto Brandolini
#DDD #Microservices
👍4🔥2
Forwarded from КБ
This media is not supported in your browser
VIEW IN TELEGRAM
В США медведь отбил пятюню водителю
🔥11👍5👎1🤯1
Несколько мыслей о профессиональных общественных объединениях.
Слово организация происходит из др.-греч. ὄργανον «орудие, инструмент; машина; орган», далее из праиндоевр. *worg- (*werg-) «делать».
А слово объединение - от слова единство. Праслав. *edinъ, *edьnъ — из *ed- (ср.: русск. едва) и стар. числит. *jьnъ (ср.: русск. иной). "Едва иной" - т.е. чистый, концентрированный, без примесей.
Залогом успешности организации являются "единство целей" и "люди дела".
Организация - это концентрированное выражение воли к достижению цели. Иными словами, важно не объединение само по себе, а те принципы, на которых оно основано.
Задачей организации является концентрация усилий, образующих организованную силу. А нашей силой и оружием является, как известно, наше знанье.
Концентрация сил необходима для преодоления сил сопротивления 🏋, подпитывающих (решаемую) проблему.
Цели - это то, в чем заключается смысл существования организации. Без общих целей организация быстро превращается в площадку для самоутверждения и достижения личных интересов, которые легко могут входить в противоречие с личными интересами других участников. Такое объединение не только лишено смысла, но еще и ни на что не способно, т.к. уже не выполняет функции концентрации организованной силы ввиду того, что её усилия взаимно компенсируются внутренними разногласиями. Такая организация борется не с проблемами индустрии, а сама с собой, и никакой решающей внешней силы из себя не представляет. Увы, но сражения выигрывает строй, а не индивидуальная исключительность.
Носителем целей организации является ее коллектив. Изменяя состав участников, можно легко переориентировать организацию. Неприступные крепости берутся всегда изнутри. Именно такая участь часто постигает организации, которые не способны сохранить свои цели в силу отсутствия самоорганизованности. Организация, не способная организовать себя, не способна изменить окружающий мир. Осознавая бесполезность такого объединения, его покидает опорный фундамент - последние носители его целей. Организация становится реакционной к своим прежним целям.
Именно Устав является заградительным барьером от таких "примесей". Именно Устав делает коллектив носителями принципов и превращает его в организованную силу. Каждый новый участник или принимает эти принципы, или же он сам не принимается коллективом по результатам кандидатского испытательного периода. Третьего не дано. Как говорится, важно не мнение само по себе, а его содержимое. Именно так и происходит концентрация силы - основная задача организации. Прежде чем вступить в схватку с проблемами отрасли, организация должна сама избавиться от проблем.
Устав - это скелет ☠️, на котором нарастает плоть 💪.
Устав - это стяг 🏴☠️, объединяющий людей, разделяющих его цели, и на корню пресекающий попытки посгательства на способ существования организации, поскольку именно он и стал причиной вступления человека в организацию. А следствие, как известно, не может бороться со своей причиной.
Устав - это гарантия устойчивости организации 🏰 в условиях любых эмоциональных потрясений 🌪⚡.
А казалось бы, такая формальность...
#Goal
Слово организация происходит из др.-греч. ὄργανον «орудие, инструмент; машина; орган», далее из праиндоевр. *worg- (*werg-) «делать».
А слово объединение - от слова единство. Праслав. *edinъ, *edьnъ — из *ed- (ср.: русск. едва) и стар. числит. *jьnъ (ср.: русск. иной). "Едва иной" - т.е. чистый, концентрированный, без примесей.
Залогом успешности организации являются "единство целей" и "люди дела".
Организация - это концентрированное выражение воли к достижению цели. Иными словами, важно не объединение само по себе, а те принципы, на которых оно основано.
Задачей организации является концентрация усилий, образующих организованную силу. А нашей силой и оружием является, как известно, наше знанье.
Концентрация сил необходима для преодоления сил сопротивления 🏋, подпитывающих (решаемую) проблему.
Цели - это то, в чем заключается смысл существования организации. Без общих целей организация быстро превращается в площадку для самоутверждения и достижения личных интересов, которые легко могут входить в противоречие с личными интересами других участников. Такое объединение не только лишено смысла, но еще и ни на что не способно, т.к. уже не выполняет функции концентрации организованной силы ввиду того, что её усилия взаимно компенсируются внутренними разногласиями. Такая организация борется не с проблемами индустрии, а сама с собой, и никакой решающей внешней силы из себя не представляет. Увы, но сражения выигрывает строй, а не индивидуальная исключительность.
Носителем целей организации является ее коллектив. Изменяя состав участников, можно легко переориентировать организацию. Неприступные крепости берутся всегда изнутри. Именно такая участь часто постигает организации, которые не способны сохранить свои цели в силу отсутствия самоорганизованности. Организация, не способная организовать себя, не способна изменить окружающий мир. Осознавая бесполезность такого объединения, его покидает опорный фундамент - последние носители его целей. Организация становится реакционной к своим прежним целям.
Именно Устав является заградительным барьером от таких "примесей". Именно Устав делает коллектив носителями принципов и превращает его в организованную силу. Каждый новый участник или принимает эти принципы, или же он сам не принимается коллективом по результатам кандидатского испытательного периода. Третьего не дано. Как говорится, важно не мнение само по себе, а его содержимое. Именно так и происходит концентрация силы - основная задача организации. Прежде чем вступить в схватку с проблемами отрасли, организация должна сама избавиться от проблем.
Устав - это скелет ☠️, на котором нарастает плоть 💪.
Устав - это стяг 🏴☠️, объединяющий людей, разделяющих его цели, и на корню пресекающий попытки посгательства на способ существования организации, поскольку именно он и стал причиной вступления человека в организацию. А следствие, как известно, не может бороться со своей причиной.
Устав - это гарантия устойчивости организации 🏰 в условиях любых эмоциональных потрясений 🌪⚡.
А казалось бы, такая формальность...
#Goal
🔥6👍3🤔1
Является ли Post Code Review (Pre-Integration Review) эффективной практикой? Давайте посмотрим, какие исходы обычно возникают в результате Code Review:
1. Когда новый инкремент знаний получен, тогда возникает:
1.1. Конесенсус (обоюдное согласие на едином решении), который формируется, как правило, новым инкрементом знаний, полученным в процессе обсуждения Pull Request.
Или:
1.2. Психологическая защита. Чувство ущербности на фоне грамотного спикера вынуждает специалиста защищать свою зону комфорта и социальное положение путем агрессивных попыток дискредитации носителя неудобных компетенций. Увы, подобные случаи происходили даже в практике достаточно известных авторов по архитектуре. Иными словами, мало знать, нужно уметь еще донести.
📝 "Там, где заканчивается знание, начинается мнение".
-- "Философия: Энциклопедический словарь." — М.: Гардарики. Под редакцией А.А. Ивина. 2004.
2. Если знание по своему определению непротиворечиво и способно привести к обоюдному согласию (пусть и не всегда), то недостаток знаний (для качественной аргументации позиции) приводит к соперничеству мнений за лидерство. Тогда возникает:
2.1. Внешний конформизм, когда одному из участников Code Review не удалось аргументированно пояснить свою позицию другому, и тот решил прекратить прения, оставшись внутри себя несогласным.
Или:
2.2. Эффект иррационального усиления - когда психологически сложно расстаться с проделанным трудом.
Во всех перечисленных случаях, кроме первого, это приводит к демотивации и усиливает текучку кадров. Что, в свою очередь вызывает ущерб упущенной выгоды из-за сдвига графика выхода на рынок новых бизнес-фич в результате простаивания незаполненных вакансий, проблемы Брукса (отвлекания опытных специалистов на обучение новых, низкая эффективность новых специалистов из-за недостатка знаний и трат времени на освоение новых знаний), прямые потери (обучение, поиск соискателей) и т.п.
Поскольку ключевым условием достижения консенсуса ревьюера и автора Pull Request является новый инкремент знаний, резонно возникает вопрос: а нужно ли получение этого инкремента привязывать по времени к инспекции уже воплощенной реализации? Design Review? Continuous Code Review? Refinement Code Review?
#SDLC #Management #Psychology
1. Когда новый инкремент знаний получен, тогда возникает:
1.1. Конесенсус (обоюдное согласие на едином решении), который формируется, как правило, новым инкрементом знаний, полученным в процессе обсуждения Pull Request.
Или:
1.2. Психологическая защита. Чувство ущербности на фоне грамотного спикера вынуждает специалиста защищать свою зону комфорта и социальное положение путем агрессивных попыток дискредитации носителя неудобных компетенций. Увы, подобные случаи происходили даже в практике достаточно известных авторов по архитектуре. Иными словами, мало знать, нужно уметь еще донести.
📝 "Там, где заканчивается знание, начинается мнение".
-- "Философия: Энциклопедический словарь." — М.: Гардарики. Под редакцией А.А. Ивина. 2004.
2. Если знание по своему определению непротиворечиво и способно привести к обоюдному согласию (пусть и не всегда), то недостаток знаний (для качественной аргументации позиции) приводит к соперничеству мнений за лидерство. Тогда возникает:
2.1. Внешний конформизм, когда одному из участников Code Review не удалось аргументированно пояснить свою позицию другому, и тот решил прекратить прения, оставшись внутри себя несогласным.
Или:
2.2. Эффект иррационального усиления - когда психологически сложно расстаться с проделанным трудом.
Во всех перечисленных случаях, кроме первого, это приводит к демотивации и усиливает текучку кадров. Что, в свою очередь вызывает ущерб упущенной выгоды из-за сдвига графика выхода на рынок новых бизнес-фич в результате простаивания незаполненных вакансий, проблемы Брукса (отвлекания опытных специалистов на обучение новых, низкая эффективность новых специалистов из-за недостатка знаний и трат времени на освоение новых знаний), прямые потери (обучение, поиск соискателей) и т.п.
Поскольку ключевым условием достижения консенсуса ревьюера и автора Pull Request является новый инкремент знаний, резонно возникает вопрос: а нужно ли получение этого инкремента привязывать по времени к инспекции уже воплощенной реализации? Design Review? Continuous Code Review? Refinement Code Review?
#SDLC #Management #Psychology
🔥6🤔4👍2
Grady Booch - Software Architecture for a Post AI and Post Quantum World
- https://youtu.be/MyVKoV1Nru8
- https://iasaglobal.org/Public/News/Articles/BILT-Modern_Software_Architecture-Session-11.aspx
#SoftwareArchitecture
- https://youtu.be/MyVKoV1Nru8
- https://iasaglobal.org/Public/News/Articles/BILT-Modern_Software_Architecture-Session-11.aspx
#SoftwareArchitecture
Simon Brown - Visualising Software Architecture with the C4 Model
- https://youtu.be/I3F7G5yxzqs
- https://iasaglobal.org/Public/News/Articles/BILT-Modern_Software_Architecture-Session-4.aspx
#SoftwareArchitecture
- https://youtu.be/I3F7G5yxzqs
- https://iasaglobal.org/Public/News/Articles/BILT-Modern_Software_Architecture-Session-4.aspx
#SoftwareArchitecture
Mark Richards & Neal Ford - Modern Tradeoff Analysis For Distributed Architectures
- https://youtu.be/mT7CT2Sg_L8
- https://iasaglobal.org/Public/News/Articles/BILT-Modern_Software_Architecture-Session-6.aspx
#SoftwareArchitecture
- https://youtu.be/mT7CT2Sg_L8
- https://iasaglobal.org/Public/News/Articles/BILT-Modern_Software_Architecture-Session-6.aspx
#SoftwareArchitecture
👍2
И куча других интересных видео:
- https://iasaglobal.org/Public/Public/News/News.aspx
[UPDATE]: если у кого-то не работает, то все видео здесь:
- https://m.youtube.com/c/IasaGlobalVideo
#SoftwareArchitecture
- https://iasaglobal.org/Public/Public/News/News.aspx
[UPDATE]: если у кого-то не работает, то все видео здесь:
- https://m.youtube.com/c/IasaGlobalVideo
#SoftwareArchitecture
Старина Kent Beck написал очередную бомбовую статью про качественный код:
"Tune Software Development for Rate of Change, not Rate of Progress"
https://medium.com/@kentbeck_7670/tune-software-development-for-rate-of-change-not-rate-of-progress-56f93c15a769
Очередной бесценный аргумент для тех, кто вынужден спегетти-кодить не по своему желанию.
#SoftwareDesign
"Tune Software Development for Rate of Change, not Rate of Progress"
https://medium.com/@kentbeck_7670/tune-software-development-for-rate-of-change-not-rate-of-progress-56f93c15a769
Очередной бесценный аргумент для тех, кто вынужден спегетти-кодить не по своему желанию.
#SoftwareDesign
Medium
Tune Software Development for Rate of Change, not Rate of Progress
Folks seem to tune software development for a desired output rate. That’s a disaster. Here’s why, what to do instead, and (at the end) a…
🔥8
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
Является ли Post Code Review (Pre-Integration Review) эффективной практикой? Давайте посмотрим, какие исходы обычно возникают в результате Code Review: 1. Когда новый инкремент знаний получен, тогда возникает: 1.1. Конесенсус (обоюдное согласие на едином…
В продолжение темы невысокой эффективности Post Code Review:
"Эксперимент с красными бусинками - Dr. Deming's Red Bead Experiment"
- https://www.youtube.com/watch?v=Nf431Upix3M
Thanks to @sergey486
#SDLC #Management #Psychology
"Эксперимент с красными бусинками - Dr. Deming's Red Bead Experiment"
- https://www.youtube.com/watch?v=Nf431Upix3M
Thanks to @sergey486
#SDLC #Management #Psychology
👍4👎2🔥2🤯2
emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
"Validations and invariants" by Vladimir Khorikov - https://khorikov.org/posts/2022-06-06-validation-vs-invariants/ #DDD
"Crossing aggregate boundaries" by Vladimir Khorikov ( @vkhorikov )
- https://khorikov.org/posts/2022-06-13-crossing-aggregate-boundaries/
> I hear this guideline a lot as well.
Тоже слышал эту фразу много раз, как правило от тех, кто эту книгу сам не читал. Именно поэтому очень важно получать информацию из первоисточника, где V.Vernon сопровождает эту информацию еще целым рядом дополнительной информации, в которой он не только допускает, но и рекомендует в некоторых случаях фиксировать несколько агрегатов одной транзакцией.
#DDD
- https://khorikov.org/posts/2022-06-13-crossing-aggregate-boundaries/
> I hear this guideline a lot as well.
Тоже слышал эту фразу много раз, как правило от тех, кто эту книгу сам не читал. Именно поэтому очень важно получать информацию из первоисточника, где V.Vernon сопровождает эту информацию еще целым рядом дополнительной информации, в которой он не только допускает, но и рекомендует в некоторых случаях фиксировать несколько агрегатов одной транзакцией.
#DDD
🔥4👍3
Forwarded from SWE notes
Объемная статья о том как сделать EventSource систему на Go стеке (если б я сейчас делал систему с нуля технологии я бы взял те же что и в статье)
https://shijuvar.medium.com/building-event-driven-distributed-systems-in-go-with-grpc-nats-jetstream-and-cockroachdb-c4b899c8636d
https://shijuvar.medium.com/building-event-driven-distributed-systems-in-go-with-grpc-nats-jetstream-and-cockroachdb-c4b899c8636d
Medium
Building Event-Driven Distributed Systems in Go with gRPC, NATS JetStream and CockroachDB
In this post, I will give an overview about how to write event-driven distributed systems in Go, with gRPC, NATS JetStream and CockroachDB…
🔥4🤯2