SK
Вообще обсуждение последних двух дней напоминает спор о том, как правильно держать ручку в руке. Какая разница как, если тебе удобно писать?
Со спорами всегда так.
Size: a a a
2018 November 09
RK
Вопрос. Можем ли мы как правило рассчитывать на стабильность REST API?
Зависит от твоего SLA?
RK
Да и нормальное изменение API по-хорошему проводится не сразу, а, скажем, версия 1 имела одно, версия 2 имеет новые и старые вещи, версия 3 выпиливает старые вещи (если частота релизов невысока, в противном случае чиселок версий будет больше)
SK
Зависит от твоего SLA?
Моя позиция такая: польза контракта - в стабильности. Если контракт меняется на каждый несущественный чих - это плохая абстракция. Обеспечить стабильность для REST API видится мне как задача гораздо тяжелее, чем обеспечить стабильность маленького сегрегированного бизнес-ориентированного интерфейса.
RK
При этом ты не отрицаешь, что жёстко зафиксированный SLA является подобием гаранта неизменности REST API
SK
Не отрицаю, но на практике как жестко и как часто его фиксируют?
SK
Заказчика не всегда переспоришь.
RK
Поэтому существуют отдельные команды, допиливающие для заказчика необходимые штуки.
SK
Что значит "допиливающие". Как недостающие штуки они допилят в неизменный API?
RK
Да и попросту может не уметь правильно готовить твой API
RK
> не создает глобальных проблем при разработке приложений
Да как не создает, когда создает. Сервис, зашитый на сервис - это прямое нарушение DIP - конкретика завязанная на конкретику. Со всеми вытекающими - муторно менять, муторно рефакторить, муторно держать сложность в узде, муторно тестить, муторно читать. Сплошь и рядом такое вижу, никогда не видел чтоб проложение с инжекциями на аннотациях были норм
Да как не создает, когда создает. Сервис, зашитый на сервис - это прямое нарушение DIP - конкретика завязанная на конкретику. Со всеми вытекающими - муторно менять, муторно рефакторить, муторно держать сложность в узде, муторно тестить, муторно читать. Сплошь и рядом такое вижу, никогда не видел чтоб проложение с инжекциями на аннотациях были норм
Кстати, я бы вот не сказал что тот веб-сервис Бугаенко из композиций внезапно офигенно лёгок для чтения/рефакторинга/изменения
SK
Кстати, я бы вот не сказал что тот веб-сервис Бугаенко из композиций внезапно офигенно лёгок для чтения/рефакторинга/изменения
Мне тоже не нравится код Бугаенко, что не мешает мне практиковать его концепцию.
SK
И кстати я не 100% согласен с его тезисами. Скорее процентов на 60-70.
SK
Как я уже говорил, проблема огромных композиций впринципе решаема. У меня в puzzlerbot'е по ссылке выше больших пирамид нет
RK
И касательно DI - немного магии всегда не помешает. Я уверен что никто досконально не изучает устройство современного ДВС, чтобы ездить на авто, оставляя для себя этот небольшой кусочек "магии", который просто работает.
RK
SK
И касательно DI - немного магии всегда не помешает. Я уверен что никто досконально не изучает устройство современного ДВС, чтобы ездить на авто, оставляя для себя этот небольшой кусочек "магии", который просто работает.
Про магию впринципе спорить не буду, просто не каждая магия - белая. Я например не стесняюсь пользоваться код- и байткод-генерацией. Про Авто и ДВС не хочу рассуждать. Это нас никуда не заведет.
SK
Да, я помню, выше уже поминалось. В таких случаях я задаю себе вопрос "и ради чего это все было?".
RK
А я в своё время охреневал от implicits и макросов в Scala
RK
Но оказалось вполне удобненько