В рейтинге участвует:

групп:

каналов:

Виртуальный сервер на SSD - недорого!

Аренда выделенных и виртуальных серверов (VDS/VPS), хостинг, аренда IP-адресов, администрирование, круглосуточная поддержка

qwarta.ru подробнее

Резервное копирование с проверкой на вирусы!!!

Удобный сервис создания резервных копий на любой сервер сети интернет. Отслеживайте изменения, проверяйте на вирусы. Надежно защитите свой бизнес!

go.backupland.com

Выбираете сервер? Любая конфигурация на заказ!

Аренда физических серверов любых конфигураций под любые запросы - 1С бухгалтерия, игровые сервера, нагруженные проекты, интернет-магазины!

qwarta.ru подробнее

Size: a a a

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

2019 membersпожаловаться на группу
2020 March 05

YB

Yury Batsyuro in Архитектура ИТ-решений
Andrei Soloschak
Это в качестве примера. Задачи сделать универсальную абстракцию нет. Главное, чтобы когда появится необходимость расширения, это не стало бы форс-маждором.
Если бы код, который это делает форс-мажором, не отличался от кода, который не делает это форс-мажором, он бы сразу не делал это форс-мажором. Но практика показывает, что ты либо шпигуешь систему точками расширения, либо каждая доработка будет выходить всё дороже и дороже.
источник
17:49пожаловаться#1

PD

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

PD

Phil Delgyado in Архитектура ИТ-решений
Э, тут уже приводили картинеу про unknown unknowns. Подход simple design предполагает, что нет known unknowns.
источник
17:53пожаловаться#3

AS

Andrei Soloschak in Архитектура ИТ-решений
Yury Batsyuro
Если бы код, который это делает форс-мажором, не отличался от кода, который не делает это форс-мажором, он бы сразу не делал это форс-мажором. Но практика показывает, что ты либо шпигуешь систему точками расширения, либо каждая доработка будет выходить всё дороже и дороже.
Нет никаких точек расширения. Делаем всегда необходимый минимум. Иногда просто имеет смысл сделать неуниверсальную абстракцию сразу, например в виде отдельного сервиса, если понятно, что в будущем будут похожие реализации.
источник
17:54пожаловаться#4

AS

Andrei Soloschak in Архитектура ИТ-решений
Phil Delgyado
Э, тут уже приводили картинеу про unknown unknowns. Подход simple design предполагает, что нет known unknowns.
Ровно наоборот. Поскольку мы не знаем что будет, то и не делаем никакой лишней функциональности
источник
17:55пожаловаться#5

PD

Phil Delgyado in Архитектура ИТ-решений
Andrei Soloschak
Нет никаких точек расширения. Делаем всегда необходимый минимум. Иногда просто имеет смысл сделать неуниверсальную абстракцию сразу, например в виде отдельного сервиса, если понятно, что в будущем будут похожие реализации.
Будут похожие реализации - это и есть точка расширения )
источник
17:55пожаловаться#6

PD

Phil Delgyado in Архитектура ИТ-решений
Andrei Soloschak
Ровно наоборот. Поскольку мы не знаем что будет, то и не делаем никакой лишней функциональности
Э, перечитай, я именно это и написал. Для simple design - только unknown unknowns.
источник
17:56пожаловаться#7

AS

Andrei Soloschak in Архитектура ИТ-решений
Phil Delgyado
Будут похожие реализации - это и есть точка расширения )
Да, но не в форме универсального решения
источник
17:56пожаловаться#8

PD

Phil Delgyado in Архитектура ИТ-решений
Так эти точки расширения - уже про более универсальное решение, чем есть в задаче.
источник
17:57пожаловаться#9

PD

Phil Delgyado in Архитектура ИТ-решений
Можно говорить о шкале 'универсальности', но это уже не крайняя левая точка.
источник
17:57пожаловаться#10

PD

Phil Delgyado in Архитектура ИТ-решений
А как раз принятие решения о том, насколько универсальным должна быть точка расширения - это архитектура, а не simple design
источник
17:58пожаловаться#11

AS

Andrei Soloschak in Архитектура ИТ-решений
Phil Delgyado
Так эти точки расширения - уже про более универсальное решение, чем есть в задаче.
Тут нет универсализма. Если у меня робокасса, то в коде будет обращение абстракции робокассы, а не какой-то универсальной покрывающей будущие требования. При этом когда появится ЯД, то это будет изменено, но не катастрофично
источник
17:58пожаловаться#12

AS

Andrei Soloschak in Архитектура ИТ-решений
Phil Delgyado
А как раз принятие решения о том, насколько универсальным должна быть точка расширения - это архитектура, а не simple design
Simple Desing  = the art of maximizing work not done, а не отсутствие архитектуры
источник
17:59пожаловаться#13

PD

Phil Delgyado in Архитектура ИТ-решений
А почему не катастрофично? Как это обеспечить? У них сильно разные сценарии, насколько помню.
источник
17:59пожаловаться#14

PD

Phil Delgyado in Архитектура ИТ-решений
Ну, тогда это про то, что бы откладывать важные решения, это ещё одно слово для архитектуры. Но обычно под simple design понимают другое.
источник
18:00пожаловаться#15

AS

Andrei Soloschak in Архитектура ИТ-решений
Phil Delgyado
А почему не катастрофично? Как это обеспечить? У них сильно разные сценарии, насколько помню.
Если удастся сделать обобщенный интерфейс не меняя логики основного процесса, то хорошо. Если нет то, тоже ничего страшного появится еще один процесс.
источник
18:01пожаловаться#16

PD

Phil Delgyado in Архитектура ИТ-решений
Andrei Soloschak
Тут нет универсализма. Если у меня робокасса, то в коде будет обращение абстракции робокассы, а не какой-то универсальной покрывающей будущие требования. При этом когда появится ЯД, то это будет изменено, но не катастрофично
У тебя будет разная логика вокруг этих абстракций-адаптеров, там будет катастрофа )
источник
18:01пожаловаться#17

PD

Phil Delgyado in Архитектура ИТ-решений
Andrei Soloschak
Если удастся сделать обобщенный интерфейс не меняя логики основного процесса, то хорошо. Если нет то, тоже ничего страшного появится еще один процесс.
Тогда зачем адаптер, если скорее всего новый процесс делать?
источник
18:01пожаловаться#18

AS

Andrei Soloschak in Архитектура ИТ-решений
Phil Delgyado
Тогда зачем адаптер, если скорее всего новый процесс делать?
Может и не нужен. Поэтому часто начинают с монолита. Зависит от степени изученности предметной области. Я не очень знаком с API робокассы и ЯД, но если их можно использовать не меняя принципиально логику основного процесса, то выделить адаптер можно уже на раннем этапе. На уровне кода это происходит автоматически просто если используется TDD и SOLID
источник
18:05пожаловаться#19

PD

Phil Delgyado in Архитектура ИТ-решений
Ну, беда в том, что для принятия решения о выделении тебе нужно изучить эти API, т.е. потратить силы на то, что сейчас не нужно. При том, что на ЯД, например, робокасса не похожа не так, как не похожа на Киви. И это выделение абстракции превращается в RnD на пару спринтов )
источник
18:07пожаловаться#20