Size: a a a

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

2020 March 05

YB

Yury Batsyuro in Архитектура ИТ-решений
Или трассировку истории операций.
источник

AS

Andrei Soloschak in Архитектура ИТ-решений
Yury Batsyuro
Я говорю о, например, логировании и счётчиках производительности ПО. Если логирование ни у кого вопросов не вызывает, то пресловутые счётчики производительности пока ещё способны удивить.
Логирование? Как можно вообще разрабатывать без логирования и трассировки, особенно при MSA?  Мониторинг это тоже необходимая часть production grade productа. Simple design это про отсутствие неиспользуемого функционала "на будущее". Логирование это вообще гигиена
источник

AS

Andrei Soloschak in Архитектура ИТ-решений
Yury Batsyuro
Или трассировку истории операций.
Смотря что под этим понимается. Если это бизнес-операции, то может быть и не нужно делать сразу. А если у вас скажем Event Sourcing, то история получается  "из коробки".
источник

YB

Yury Batsyuro in Архитектура ИТ-решений
Andrei Soloschak
Логирование? Как можно вообще разрабатывать без логирования и трассировки, особенно при MSA?  Мониторинг это тоже необходимая часть production grade productа. Simple design это про отсутствие неиспользуемого функционала "на будущее". Логирование это вообще гигиена
Если речь идёт о том, что «ваши метрики производительности не должны усложнять работу пользователя», то да, это и без XP вроде очевидно, это любой Lean имеет в базе. А вот «не собирать данные, если потребность в этом не обоснована», не всегда стратегически верный ход, особенно в эпоху big data.
источник

PD

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

YB

Yury Batsyuro in Архитектура ИТ-решений
Phil Delgyado
Оставить возможность для изменений без понимания возможных изменений - не работает. Все равно есть предположения о возможных направлениях и изменениях как ФТ, так и НФТ.
Собственно, архитектору платят за их выявление. Иначе архитектор не нужен, живи себе сегодняшним днём и удивляйся сюрпризам завтрашнего.
источник

AS

Andrei Soloschak in Архитектура ИТ-решений
Phil Delgyado
Оставить возможность для изменений без понимания возможных изменений - не работает. Все равно есть предположения о возможных направлениях и изменениях как ФТ, так и НФТ.
Для этого например вводятся абстракции, которые в последствии могут быть реализованы иначе.
Минимизация upfront решений - основная задача архитектора.
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Andrei Soloschak
Для этого например вводятся абстракции, которые в последствии могут быть реализованы иначе.
Минимизация upfront решений - основная задача архитектора.
Абстракции - это тоже лишний код и лишние траты ресурсов, никакой разницы.
источник

YB

Yury Batsyuro in Архитектура ИТ-решений
Andrei Soloschak
Для этого например вводятся абстракции, которые в последствии могут быть реализованы иначе.
Минимизация upfront решений - основная задача архитектора.
Абстракция говорит «нужно», ЧТЗ говорит «не нужно». Кому верить?
источник

AS

Andrei Soloschak in Архитектура ИТ-решений
Yury Batsyuro
Абстракция говорит «нужно», ЧТЗ говорит «не нужно». Кому верить?
А может само ЧТЗ не нужно?
источник

YB

Yury Batsyuro in Архитектура ИТ-решений
«Всё по паттернам» — это антипаттерн
источник

YB

Yury Batsyuro in Архитектура ИТ-решений
Andrei Soloschak
А может само ЧТЗ не нужно?
Потребность в той самой минимальной сложности откуда берём тогда?
источник

AS

Andrei Soloschak in Архитектура ИТ-решений
Пользовательские истории :)
источник

YB

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

YB

Yury Batsyuro in Архитектура ИТ-решений
Andrei Soloschak
Пользовательские истории :)
Пользователи в своих историях напишут, что надо вкручивать точку расширяемости в сценарий оплаты через шлюз, чтобы можно было есличо переехать с Робокассы на ЯД или обратно?
источник

AP

Alexey Pryanishnikov in Архитектура ИТ-решений
Yury Batsyuro
А можно поподробнее кейс, в целях повышения образованности?
Одна крупная ИТ контора заказывает у другой крупной софтверной конторы разработку не очень сложной системы, которая должна собирать разного рода события с нескольких проприетарных интерфейсов, чего-то с ними делать и выплёвывать в некоторое количество (других) проприетарных интерфейсов. Без этой системы события идут напрямую, то есть она должна встать в разрыв продуктивного трафика.
У вендора типа какая-то форма скрама, у заказчика внутренней разработки нет. Интерфейсы жёстко специфицированы, тестовую среду построить нельзя физически (но можно написать по спекам заглушки). Пустить исполнителя на продуктивные среды нельзя, потому что таковы политики заказчика.
Формируют две команды - одна на стороне заказчика генерит, описывает и приоритезирует требования, вторая на стороне исполнителя пишет, собственно, систему.

В какой-то момент исполнитель начинает выкатывать релизы каждые N недель. Утыкаются в стандартную процедуру заказчика "окей, вы только что отдемили нечто, давайте его ставить в продуктив. Для этого нам потребуется согласовать работы за месяц, имея на руках подробную инструкцию по установке. Установка будет выполняться силами специалистов третьей компании. Все необходимые артефакты положите вот на этот вот компакт-диск и передайте заказным письмом. Время установки строго ограничено. Если хоть что-то пойдёт не так, производится откат релиза, следующая возможность попробовать - через месяц после повторного согласования, если конечно в следующем месяце не будет заморозки. Если в продуктиве обнаруживается бага, производится откат релиза итд".

И тут компания-исполнитель начинает заказчику рассказывать про CI \ CD, процессы автоматической выкладки и тестирования и прочее. Были ли они поняты? Нет. Существует ли способ подружить два настолько разных процесса? Не знаю, правда не знаю.
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Yury Batsyuro
Собственно, архитектору платят за их выявление. Иначе архитектор не нужен, живи себе сегодняшним днём и удивляйся сюрпризам завтрашнего.
Ну, это да. Но в конкретных фреймворках agile нет архитектуров
источник

RT

Roman Tsirulnikov in Архитектура ИТ-решений
Phil Delgyado
Ну, это да. Но в конкретных фреймворках agile нет архитектуров
agile в крупном проекте это конь в парижской палате мер и весов, ростом 1 метр и весом 1 кг.
Архитекторы есть и выполняют роль координатора команд
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Угу. Но это про agile в смысле манифеста, а не XP практик, которые уже не очень работают.
источник

AS

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