Здравствуйте, Pzz, Вы писали:

Pzz>Здравствуйте, Sheridan, Вы писали:

Pzz>>>В C++ к тебе придет мененджер и скажет, "твой private мешает выпустить завтра релиз, который мы должны были выпустить месяц назад", и ты поморщишься, и заменишь его на public. А поди попробуй сделай такое в микросервисе.
S>>И что мне помешает сделать интерфейс? Законы физики? Ровно также вытащу наружу, раз пришол руководитель и просит меня сделать свою работу. Узнаю конечно причины и если они существенны/справедливы — вытащу.
Pzz>Ну, когда тебя попросят сделать интерфейс, ты скажешь, что это сложно, хлопотно и надо тестировать, и займет это неделю. И у тебя есть некоторая надежда, что менеджер тебе поверит и пойдет искать другого крайнего. А вот убедить менеджера, что на замену слова private на слово public у тебя уйдет неделя, ты вряд ли сможешь.
Твои слова подтверждают твою мысль что и там и там сменить доступ к интерфейсу можно, если есть доступ к исходникам. А делать ли это прямо сейчас зависит от подвешенности языка а не от ограничений языка/мотодологии.


Pzz>>>Нет, уменьшилась. Если представить себе проект в виде графа зависемостей, сложность определяется не столько количеством вершин этого графа, сколько количеством связей между ними.
S>>Связи не изменились. Изменяется принцип установки связей. Этот новый принцип требует бОльших телодвижений. Например при переходе от вызова метода объекта к вызову метода об http api сервиса нужно встроить вдобавок обработку ошибок (та-же 404), поддержать версионность API. Как минимум!
Pzz>Программисты очень любят делать лишние связи и очень не любят думать головой. Если есть выбор, сделать 3 лишние связи или полчаса подумать головой, как без этих лишних связей обойтись, в программе появятся 3 лишние связи.
Это справедливо и при работе с библиотекой и при работе с http api. Зачем это тут? Меня заболтать?


Pzz>В то же время, программисты ленивы, как коты, страдающие ожирением.
Я так и сказал сразу. Ты опять подтвердил мои слова.


Pzz>Поэтому одной только инкапсуляции недостаточно, чтобы сложность проекта не разрасталась. Надо еще, чтобы превращение приватного в публичное было действительно муторным и трудоемким мероприятием.
Это тоже не спасёт от дурака. Правильно делать так: не пускать туда дурака.


S>>Ты прав, докер решает много "проблем". Но родился он именно для необходимости изоляции процессов. А изоляция понадобилась потому что каждый пляшет как хочет. Потому что два соседних отдела могут в каждый в своём микросервисе пользовать разные версии одной и той же либы. И чем больше контора тем больше именно эта причина выходит на первое место.
Pzz>С изоляцией процессов прекрасно справлялся chroot, придуманный еще в библейские времена. Докер решает проблему, как заполнить то место, куда chroot, тем, что процессу надо для жизни, и при этом не умереть от натуги.
Это както противоречит тому что докер появился после микросервисов и туда начали запихивать микросервисы для изоляции?


Pzz>>>Сколько раз я видел, как во вполне оттестированном дистрибутиве линуха обновление какой-нибудь библиотеки ломало чего-нибудь в какой-нибудь программе.
S>>Вспомни хотя бы два раза и озвучь период воспоминаний.
Pzz>Слушай, я в полном соответствии с теорией Фрейда эти травмирующие воспоминание немедленно вытесняю после того, как они перестают быть актуальными.
Скажу тогда тебе я: подобное случается достаточно редко при правильном управлении жизнью ОС. Настолько редко что считается форсмажором.