PD
Конечно нет. Достаточно ввести абстракцию платежного шлюза, которая будет иметь единственную реализацию.
Так это уже оверхед и лишняя (непростая ) функциональность.
Size: a a a
2020 March 05
PD
Не simple design вот совсем.
AS
Так это уже оверхед и лишняя (непростая ) функциональность.
Никакого оверхеда нет. Это часть процесса разработки. Без введения абстракции не получится даже модульный тест написать
AS
Лишнего функционала тут не появилось
AS
Реализация единственная - например Робокасса
YB
Одна крупная ИТ контора заказывает у другой крупной софтверной конторы разработку не очень сложной системы, которая должна собирать разного рода события с нескольких проприетарных интерфейсов, чего-то с ними делать и выплёвывать в некоторое количество (других) проприетарных интерфейсов. Без этой системы события идут напрямую, то есть она должна встать в разрыв продуктивного трафика.
У вендора типа какая-то форма скрама, у заказчика внутренней разработки нет. Интерфейсы жёстко специфицированы, тестовую среду построить нельзя физически (но можно написать по спекам заглушки). Пустить исполнителя на продуктивные среды нельзя, потому что таковы политики заказчика.
Формируют две команды - одна на стороне заказчика генерит, описывает и приоритезирует требования, вторая на стороне исполнителя пишет, собственно, систему.
В какой-то момент исполнитель начинает выкатывать релизы каждые N недель. Утыкаются в стандартную процедуру заказчика "окей, вы только что отдемили нечто, давайте его ставить в продуктив. Для этого нам потребуется согласовать работы за месяц, имея на руках подробную инструкцию по установке. Установка будет выполняться силами специалистов третьей компании. Все необходимые артефакты положите вот на этот вот компакт-диск и передайте заказным письмом. Время установки строго ограничено. Если хоть что-то пойдёт не так, производится откат релиза, следующая возможность попробовать - через месяц после повторного согласования, если конечно в следующем месяце не будет заморозки. Если в продуктиве обнаруживается бага, производится откат релиза итд".
И тут компания-исполнитель начинает заказчику рассказывать про CI \ CD, процессы автоматической выкладки и тестирования и прочее. Были ли они поняты? Нет. Существует ли способ подружить два настолько разных процесса? Не знаю, правда не знаю.
У вендора типа какая-то форма скрама, у заказчика внутренней разработки нет. Интерфейсы жёстко специфицированы, тестовую среду построить нельзя физически (но можно написать по спекам заглушки). Пустить исполнителя на продуктивные среды нельзя, потому что таковы политики заказчика.
Формируют две команды - одна на стороне заказчика генерит, описывает и приоритезирует требования, вторая на стороне исполнителя пишет, собственно, систему.
В какой-то момент исполнитель начинает выкатывать релизы каждые N недель. Утыкаются в стандартную процедуру заказчика "окей, вы только что отдемили нечто, давайте его ставить в продуктив. Для этого нам потребуется согласовать работы за месяц, имея на руках подробную инструкцию по установке. Установка будет выполняться силами специалистов третьей компании. Все необходимые артефакты положите вот на этот вот компакт-диск и передайте заказным письмом. Время установки строго ограничено. Если хоть что-то пойдёт не так, производится откат релиза, следующая возможность попробовать - через месяц после повторного согласования, если конечно в следующем месяце не будет заморозки. Если в продуктиве обнаруживается бага, производится откат релиза итд".
И тут компания-исполнитель начинает заказчику рассказывать про CI \ CD, процессы автоматической выкладки и тестирования и прочее. Были ли они поняты? Нет. Существует ли способ подружить два настолько разных процесса? Не знаю, правда не знаю.
Так вроде заглушки ж? Можно ли узнать у Заказчика конфигурацию, на которую он будет ставить релиз? Если да, то что мешает раскрутить такую же конфигурацию у себя, повтыкать вместо других систем заглушки и собрать CI-контур на этом, а с тестированием развёртывания и вовсе CD? На процедуру раскатки это не влияет: берётся крайний дистрибутив, заливается на болванку и отправляется заказным письмом. Суть CD в том, что вероятность, что «что-то пошло не так» в разы снижается.
YB
Реализация единственная - например Робокасса
Ну нет, как минимум реализаций две: Робокасса для продуктива и заглушка для юниттеста
PD
Никакого оверхеда нет. Это часть процесса разработки. Без введения абстракции не получится даже модульный тест написать
Э, зачем абстракцию, если реализация одна? Откуда абстрагировать? Линию по одной точке делать - бесполезно, а искать правильную абстракцию - сложно. Для платежного шлюза обычно ещё и все ошибаются.
AS
Последняя называется мок и не является полноценной. Simple Design про другое. Это когда мы не пишем универсальный модуль подключения к "любому" платежному провайдеру
YB
Последняя называется мок и не является полноценной. Simple Design про другое. Это когда мы не пишем универсальный модуль подключения к "любому" платежному провайдеру
Этот мок должно быть куда вставить.
PD
А что такое 'абстракция шлюза'? Это про API подключения любого провайдера.
AP
Так вроде заглушки ж? Можно ли узнать у Заказчика конфигурацию, на которую он будет ставить релиз? Если да, то что мешает раскрутить такую же конфигурацию у себя, повтыкать вместо других систем заглушки и собрать CI-контур на этом, а с тестированием развёртывания и вовсе CD? На процедуру раскатки это не влияет: берётся крайний дистрибутив, заливается на болванку и отправляется заказным письмом. Суть CD в том, что вероятность, что «что-то пошло не так» в разы снижается.
собственно, подобие эмуляции тестовой среды сделано было (насколько мне известно). Но во-первых, помогало слабо (ни один релиз в продуктив так и не встал), а во-вторых заказчику-то в целом наплевать, что там внутри у исполнителя - хоть модные технологии автоматизации, хоть гуру тестирует методом пристального вглядывания в код, лишь бы работало.
Вообще, ретроспективно, мне кажется что наибольшую проблему исполнитель огрёб именно на этапе залития болванки - такое ощущение, что они просто не понимали, как это, не выкачать код из репозитория, а предоставить инсталлябельную самодостаточную версию, включая документацию
Вообще, ретроспективно, мне кажется что наибольшую проблему исполнитель огрёб именно на этапе залития болванки - такое ощущение, что они просто не понимали, как это, не выкачать код из репозитория, а предоставить инсталлябельную самодостаточную версию, включая документацию
PD
И появляется все то, за что java ругают - фабрики фабрик декораторов.
YB
А что такое 'абстракция шлюза'? Это про API подключения любого провайдера.
Но у каждого провайдера API немного разный, и чтобы написать это жёстко, никакого исследования не требуется, а чтобы написать так, чтобы малой кровью добавлять другие провайдеры, надо сделать исследования, которые скорее всего на выходе выдадут, что что-то, что хотели делать на целых числах, на самом деле надо делать на строках со всеми сопутствующими тормозами...
AS
А что такое 'абстракция шлюза'? Это про API подключения любого провайдера.
Нет не любого. Абстракций может быть несколько. Каждая с минимально необходимым набором интерфейсов.
PD
Так это уже не абстракция, это реализация.
AP
это раньше называлось "коннектор"
YB
это раньше называлось "коннектор"
«коннектор», «адаптер»... это всё только если есть точка встраивания.
YB
А может «роутер»
AS
Это в качестве примера. Задачи сделать универсальную абстракцию нет. Главное, чтобы когда появится необходимость расширения, это не стало бы форс-маждором.