Size: a a a

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

2020 March 05

PD

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

PD

Phil Delgyado in Архитектура ИТ-решений
Не simple design вот совсем.
источник

AS

Andrei Soloschak in Архитектура ИТ-решений
Phil Delgyado
Так это уже оверхед и лишняя (непростая ) функциональность.
Никакого оверхеда нет. Это часть процесса разработки. Без введения абстракции не получится даже модульный тест написать
источник

AS

Andrei Soloschak in Архитектура ИТ-решений
Лишнего функционала тут не появилось
источник

AS

Andrei Soloschak in Архитектура ИТ-решений
Реализация единственная - например Робокасса
источник

YB

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

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

И тут компания-исполнитель начинает заказчику рассказывать про CI \ CD, процессы автоматической выкладки и тестирования и прочее. Были ли они поняты? Нет. Существует ли способ подружить два настолько разных процесса? Не знаю, правда не знаю.
Так вроде заглушки ж? Можно ли узнать у Заказчика конфигурацию, на которую он будет ставить релиз? Если да, то что мешает раскрутить такую же конфигурацию у себя, повтыкать вместо других систем заглушки и собрать CI-контур на этом, а с тестированием развёртывания и вовсе CD? На процедуру раскатки это не влияет: берётся крайний дистрибутив, заливается на болванку и отправляется заказным письмом. Суть CD в том, что вероятность, что «что-то пошло не так» в разы снижается.
источник

YB

Yury Batsyuro in Архитектура ИТ-решений
Andrei Soloschak
Реализация единственная - например Робокасса
Ну нет, как минимум реализаций две: Робокасса для продуктива и заглушка для юниттеста
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Andrei Soloschak
Никакого оверхеда нет. Это часть процесса разработки. Без введения абстракции не получится даже модульный тест написать
Э, зачем абстракцию, если реализация одна? Откуда абстрагировать? Линию по одной точке делать - бесполезно, а искать правильную абстракцию - сложно. Для платежного шлюза обычно ещё и все ошибаются.
источник

AS

Andrei Soloschak in Архитектура ИТ-решений
Последняя называется мок и не является полноценной. Simple Design про другое. Это когда мы не пишем универсальный модуль подключения к "любому" платежному провайдеру
источник

YB

Yury Batsyuro in Архитектура ИТ-решений
Andrei Soloschak
Последняя называется мок и не является полноценной. Simple Design про другое. Это когда мы не пишем универсальный модуль подключения к "любому" платежному провайдеру
Этот мок должно быть куда вставить.
источник

PD

Phil Delgyado in Архитектура ИТ-решений
А что такое 'абстракция шлюза'? Это про API подключения любого провайдера.
источник

AP

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

Вообще, ретроспективно, мне кажется что наибольшую проблему исполнитель огрёб именно на этапе залития болванки - такое ощущение, что они просто не понимали, как это, не выкачать код из репозитория, а предоставить инсталлябельную самодостаточную версию, включая документацию
источник

PD

Phil Delgyado in Архитектура ИТ-решений
И появляется все то, за что java ругают - фабрики фабрик декораторов.
источник

YB

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

AS

Andrei Soloschak in Архитектура ИТ-решений
Phil Delgyado
А что такое 'абстракция шлюза'? Это про API подключения любого провайдера.
Нет не любого. Абстракций может быть несколько. Каждая с минимально необходимым набором интерфейсов.
источник

PD

Phil Delgyado in Архитектура ИТ-решений
Так это уже не абстракция, это реализация.
источник

AP

Alexey Pryanishnikov in Архитектура ИТ-решений
это раньше называлось "коннектор"
источник

YB

Yury Batsyuro in Архитектура ИТ-решений
Alexey Pryanishnikov
это раньше называлось "коннектор"
«коннектор», «адаптер»... это всё только если есть точка встраивания.
источник

YB

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

AS

Andrei Soloschak in Архитектура ИТ-решений
Это в качестве примера. Задачи сделать универсальную абстракцию нет. Главное, чтобы когда появится необходимость расширения, это не стало бы форс-маждором.
источник