PD
"Спонтанная парная разработка" - штука стандартная, да.
Size: a a a
2020 March 05
AS
Ну, я тоже так считаю. Но поэтому и вместо XP использую конструктор из разных практик, а чистый XP - штука редкая.
А в чем проблема с остальными практиками? Small Releases, Simple Design, TDD, Refactoring, Collective Ownership, Continuous Integration, Coding Standard
YB
А в чем проблема с остальными практиками? Small Releases, Simple Design, TDD, Refactoring, Collective Ownership, Continuous Integration, Coding Standard
Simple Design не позволяет предусматривать вещи, которые с вероятностью 95% по Roadmap вылезут.
YB
То есть иногда дешевле перезаложиться, чтобы какое-то время не возвращаться к куску.
YB
Collective Ownership ограничивает размер системы. Всё-таки мы выше обсуждали разные способы нарезки, DDD всякие, чтобы как раз от этого коллективного уйти.
YB
TDD для UI необоснованно дорог, ручной труд дешевле и качественнее.
YB
Refactoring как раз микросервисами заменён на Replacement
YB
Т.е. проблем нет только с CI (и его продолжением в виде CD) и, пожалуй, Coding Standard, пока он не противоречит GitHub.
RT
Аджайл с точки зрения Enterprise Architecture это:
- как правильно нарезать систему на команды (DDD на уровне системы)
- как организовать коммуникацию/синхронизацию/распределение ответственности между командами (внутри команды пусть делают что хотят)
- как распространять знания, чтобы команды понимали что они делают
- как избежать взаимозависимостей команд там где это не надо
- как правильно нарезать систему на команды (DDD на уровне системы)
- как организовать коммуникацию/синхронизацию/распределение ответственности между командами (внутри команды пусть делают что хотят)
- как распространять знания, чтобы команды понимали что они делают
- как избежать взаимозависимостей команд там где это не надо
AP
Т.е. проблем нет только с CI (и его продолжением в виде CD) и, пожалуй, Coding Standard, пока он не противоречит GitHub.
Есть и с CI проблемы применимости, попробуйте его встроить в процессы и политики крупного заказчика, у которого таких вендоров пара сотен и легаси на человеко-века разработки
AP
Короче, нигде нет серебряных пуль снова, удивительно )
YB
Есть и с CI проблемы применимости, попробуйте его встроить в процессы и политики крупного заказчика, у которого таких вендоров пара сотен и легаси на человеко-века разработки
Как раз CI/CD эти проблемы решат лучше их отсутствия, тем более при наличии легаси. Сами так живём. Просто нужно понимать, что легаси обычно люто сопротивляется любому покрытию тестами, поэтому Заказчик должен быть морально готов к тому, что «прошло тесты» ≠ «заработало».
AP
Как раз CI/CD эти проблемы решат лучше их отсутствия, тем более при наличии легаси. Сами так живём. Просто нужно понимать, что легаси обычно люто сопротивляется любому покрытию тестами, поэтому Заказчик должен быть морально готов к тому, что «прошло тесты» ≠ «заработало».
Это если вас пустить.
А в реальности "вот дверь машзала, дальше только наши специалисты по предварительному согласованию с подробным повременным планом работ, не позднее чем за месяц до начала работ" ;)
А в реальности "вот дверь машзала, дальше только наши специалисты по предварительному согласованию с подробным повременным планом работ, не позднее чем за месяц до начала работ" ;)
YB
Это если вас пустить.
А в реальности "вот дверь машзала, дальше только наши специалисты по предварительному согласованию с подробным повременным планом работ, не позднее чем за месяц до начала работ" ;)
А в реальности "вот дверь машзала, дальше только наши специалисты по предварительному согласованию с подробным повременным планом работ, не позднее чем за месяц до начала работ" ;)
Если машзал — это продуктив, то всё логично, у вас должна быть своя песочница со своим машзалом, в котором весь ваш CI живёт и умирает.
YB
Причём вам CD подавно нужнее, т.к. фактически вы снижаете риск того, что у вас всё работало, а в машзале Заказчика всё разломается.
AP
Да не, я со стороны заказчика сейчас моделирую. У него свой процесс, свои регламенты и тестовую среду сделать невозможно в принципе.
Этот процессный стык с вендорами на моей памяти так и не смогли сгладить
Этот процессный стык с вендорами на моей памяти так и не смогли сгладить
YB
Да не, я со стороны заказчика сейчас моделирую. У него свой процесс, свои регламенты и тестовую среду сделать невозможно в принципе.
Этот процессный стык с вендорами на моей памяти так и не смогли сгладить
Этот процессный стык с вендорами на моей памяти так и не смогли сгладить
А можно поподробнее кейс, в целях повышения образованности?
AS
То есть иногда дешевле перезаложиться, чтобы какое-то время не возвращаться к куску.
Как правило бывает по-другому. Вы перезаложились, а значит потратили дополнительные ресурсы на разработку, тестирование и поддержку неиспользуемой функциональности. Позже выясняется, что требования изменились и вы либо делаете значительное изменение, так как не угадали, либо впиливаете костыль. И того дорого, долго и криво.
AS
Современная архитектура действует иначе. Она оставляет возможности для изменений, но при этом при разработке всегда simplicity (the art of maximizing work (functionality) not done)
YB
Как правило бывает по-другому. Вы перезаложились, а значит потратили дополнительные ресурсы на разработку, тестирование и поддержку неиспользуемой функциональности. Позже выясняется, что требования изменились и вы либо делаете значительное изменение, так как не угадали, либо впиливаете костыль. И того дорого, долго и криво.
Я говорю о, например, логировании и счётчиках производительности ПО. Если логирование ни у кого вопросов не вызывает, то пресловутые счётчики производительности пока ещё способны удивить.