PD
Каждый раз, когда принимается решение об абстракции - тратим ресурсы, которые могли не тратить.
Size: a a a
2020 March 05
PD
Т.е. simple design запрещает это делать.
PD
Ну, кроме эксперта в предметке, который сразу скажет 'абстракция шлюза должна быть такой, я знаю'. Но это он уже потратил кучу ресурсов на свою экспертность
AS
Ну, беда в том, что для принятия решения о выделении тебе нужно изучить эти API, т.е. потратить силы на то, что сейчас не нужно. При том, что на ЯД, например, робокасса не похожа не так, как не похожа на Киви. И это выделение абстракции превращается в RnD на пару спринтов )
С одной стороны так и есть. С другой стороны если у тебя MSA и адаптер выглядит как отдельный контекст, то совсем необязательно тратить время на РнД и сразу сделать отдельный, но специфичный сервис. При этом точка расширения уже появилась.
PD
Ну, MSA - это уже лишняя вещь, которую можно не делать?
PD
Почти всегда и нужно не делать в рамках конкретного сценария.
PD
Я собственно к чему. Simple design - это про функции, а не архитектуру
AS
Ну, MSA - это уже лишняя вещь, которую можно не делать?
Может и так. Поэтому monolith first. Но в какой-то момент все равно возникает MSA и тут уже проще иметь отдельный неуниверсальный сервис чисто из архитектурных соображений.
AS
Я собственно к чему. Simple design - это про функции, а не архитектуру
Речь шла вроде про XP :) Про архитектуру я вспомнил в контексте: "А давайте заложим что-то на будущее". В том смысле, что этого не требуется. Для будущего есть другие подходы
PD
Ну если сводить XP к задачам после архитектуры - то да. Но смысл тогда в этой практике, если она не описывает свои граничные условия.
AS
Ну если сводить XP к задачам после архитектуры - то да. Но смысл тогда в этой практике, если она не описывает свои граничные условия.
Смысл в том, что каждая дополнительная функция - это дополнительная сложность при последующем сопровождении. Например когда ты решил написать что-то "про запас", то должен понимать, что это "про запас" нужно покрыть тестами и поддерживать при любом изменении системы. При том, что предположение "о будущем" может оказаться некорректным.
PD
Да это все понятно. Но нужно не про категоричное 'не делаем никогда', а про 'решаем, где разместить данный запрос на линейке универсальности'.
PD
Плохи обе крайности.
AS
Да это все понятно. Но нужно не про категоричное 'не делаем никогда', а про 'решаем, где разместить данный запрос на линейке универсальности'.
А что понимается под линейкой универсальности? Вообще понятие Simple Design не совсем удачное. Более правильное все же simplicity. То есть design все-таки не обязан быть максимально простым, а вот функциональность можно минимизировать.
YB
Ну, тогда это про то, что бы откладывать важные решения, это ещё одно слово для архитектуры. Но обычно под simple design понимают другое.
У Herberto Graca так и написано, что большинство архитектурных решений о том, как отложить принятие архитектурных решений. Но оверхэд то растёт.
PD
Ну, при грамотном архитектурном решении оверхед при отложении - не растет.
YB
Если удастся сделать обобщенный интерфейс не меняя логики основного процесса, то хорошо. Если нет то, тоже ничего страшного появится еще один процесс.
Смотря насколько тот предыдущий процесс пророс в остальное приложение
YB
Ну если сводить XP к задачам после архитектуры - то да. Но смысл тогда в этой практике, если она не описывает свои граничные условия.
На самом деле кусок этой практики есть и в IT-процессах: «не содержать лишнее оборудование и лишние рабочие места», и в архитектурных процессах: «каждый функциональный блок должен трассироваться в требование или юзер стори»
YB
Только на архитектурном уровне это поправить подчас проще, чем в реализации.
SD
Оффтоп: А кто нить из ваших знакомых сдаёт на ботаническом саду двушку или трёхкомнатную?
.
Напишите в личку плз
.
Напишите в личку плз