Size: a a a

Архитектура ИТ-решений

2020 March 05

PD

Phil Delgyado in Архитектура ИТ-решений
"Спонтанная парная разработка"  - штука стандартная, да.
источник

AS

Andrei Soloschak in Архитектура ИТ-решений
Phil Delgyado
Ну, я тоже так считаю. Но поэтому и вместо XP использую конструктор из разных практик, а чистый XP - штука редкая.
А в чем проблема с остальными практиками? Small Releases, Simple Design, TDD, Refactoring, Collective Ownership, Continuous Integration, Coding Standard
источник

YB

Yury Batsyuro in Архитектура ИТ-решений
Andrei Soloschak
А в чем проблема с остальными практиками? Small Releases, Simple Design, TDD, Refactoring, Collective Ownership, Continuous Integration, Coding Standard
Simple Design не позволяет предусматривать вещи, которые с вероятностью 95% по Roadmap вылезут.
источник

YB

Yury Batsyuro in Архитектура ИТ-решений
То есть иногда дешевле перезаложиться, чтобы какое-то время не возвращаться к куску.
источник

YB

Yury Batsyuro in Архитектура ИТ-решений
Collective Ownership ограничивает размер системы. Всё-таки мы выше обсуждали разные способы нарезки, DDD всякие, чтобы как раз от этого коллективного уйти.
источник

YB

Yury Batsyuro in Архитектура ИТ-решений
TDD для UI необоснованно дорог, ручной труд дешевле и качественнее.
источник

YB

Yury Batsyuro in Архитектура ИТ-решений
Refactoring как раз микросервисами заменён на Replacement
источник

YB

Yury Batsyuro in Архитектура ИТ-решений
Т.е. проблем нет только с CI (и его продолжением в виде CD) и, пожалуй, Coding Standard, пока он не противоречит GitHub.
источник

RT

Roman Tsirulnikov in Архитектура ИТ-решений
Аджайл с точки зрения Enterprise Architecture это:
- как правильно нарезать систему на команды (DDD на уровне системы)
- как организовать коммуникацию/синхронизацию/распределение ответственности между командами (внутри команды пусть делают что хотят)
- как распространять знания, чтобы команды понимали что они делают
- как избежать взаимозависимостей команд там где это не надо
источник

AP

Alexey Pryanishnikov in Архитектура ИТ-решений
Yury Batsyuro
Т.е. проблем нет только с CI (и его продолжением в виде CD) и, пожалуй, Coding Standard, пока он не противоречит GitHub.
Есть и с CI проблемы применимости, попробуйте его встроить в процессы и политики крупного заказчика, у которого таких вендоров пара сотен и легаси на человеко-века разработки
источник

AP

Alexey Pryanishnikov in Архитектура ИТ-решений
Короче, нигде нет серебряных пуль снова, удивительно )
источник

YB

Yury Batsyuro in Архитектура ИТ-решений
Alexey Pryanishnikov
Есть и с CI проблемы применимости, попробуйте его встроить в процессы и политики крупного заказчика, у которого таких вендоров пара сотен и легаси на человеко-века разработки
Как раз CI/CD эти проблемы решат лучше их отсутствия, тем более при наличии легаси. Сами так живём. Просто нужно понимать, что легаси обычно люто сопротивляется любому покрытию тестами, поэтому Заказчик должен быть морально готов к тому, что «прошло тесты» ≠ «заработало».
источник

AP

Alexey Pryanishnikov in Архитектура ИТ-решений
Yury Batsyuro
Как раз CI/CD эти проблемы решат лучше их отсутствия, тем более при наличии легаси. Сами так живём. Просто нужно понимать, что легаси обычно люто сопротивляется любому покрытию тестами, поэтому Заказчик должен быть морально готов к тому, что «прошло тесты» ≠ «заработало».
Это если вас пустить.
А в реальности "вот дверь машзала, дальше только наши специалисты по предварительному согласованию с подробным повременным планом работ, не позднее чем за месяц до начала работ" ;)
источник

YB

Yury Batsyuro in Архитектура ИТ-решений
Alexey Pryanishnikov
Это если вас пустить.
А в реальности "вот дверь машзала, дальше только наши специалисты по предварительному согласованию с подробным повременным планом работ, не позднее чем за месяц до начала работ" ;)
Если машзал — это продуктив, то всё логично, у вас должна быть своя песочница со своим машзалом, в котором весь ваш CI живёт и умирает.
источник

YB

Yury Batsyuro in Архитектура ИТ-решений
Причём вам CD подавно нужнее, т.к. фактически вы снижаете риск того, что у вас всё работало, а в машзале Заказчика всё разломается.
источник

AP

Alexey Pryanishnikov in Архитектура ИТ-решений
Да не, я со стороны заказчика сейчас моделирую. У него свой процесс, свои регламенты и тестовую среду сделать невозможно в принципе.

Этот процессный стык с вендорами на моей памяти так и не смогли сгладить
источник

YB

Yury Batsyuro in Архитектура ИТ-решений
Alexey Pryanishnikov
Да не, я со стороны заказчика сейчас моделирую. У него свой процесс, свои регламенты и тестовую среду сделать невозможно в принципе.

Этот процессный стык с вендорами на моей памяти так и не смогли сгладить
А можно поподробнее кейс, в целях повышения образованности?
источник

AS

Andrei Soloschak in Архитектура ИТ-решений
Yury Batsyuro
То есть иногда дешевле перезаложиться, чтобы какое-то время не возвращаться к куску.
Как правило бывает по-другому. Вы перезаложились, а значит потратили дополнительные ресурсы на разработку, тестирование и поддержку неиспользуемой функциональности. Позже выясняется, что требования изменились и вы либо делаете значительное изменение, так как не угадали, либо впиливаете костыль. И того дорого, долго и криво.
источник

AS

Andrei Soloschak in Архитектура ИТ-решений
Современная архитектура действует иначе. Она оставляет возможности для изменений, но при этом при разработке всегда simplicity (the art of maximizing work (functionality) not done)
источник

YB

Yury Batsyuro in Архитектура ИТ-решений
Andrei Soloschak
Как правило бывает по-другому. Вы перезаложились, а значит потратили дополнительные ресурсы на разработку, тестирование и поддержку неиспользуемой функциональности. Позже выясняется, что требования изменились и вы либо делаете значительное изменение, так как не угадали, либо впиливаете костыль. И того дорого, долго и криво.
Я говорю о, например, логировании и счётчиках производительности ПО. Если логирование ни у кого вопросов не вызывает, то пресловутые счётчики производительности пока ещё способны удивить.
источник