Re[13]: Язык Go - слабые стороны
От: Pzz Россия https://github.com/alexpevzner
Дата: 16.02.22 10:33
Оценка:
Здравствуйте, Sheridan, Вы писали:

Pzz>>В C++ к тебе придет мененджер и скажет, "твой private мешает выпустить завтра релиз, который мы должны были выпустить месяц назад", и ты поморщишься, и заменишь его на public. А поди попробуй сделай такое в микросервисе.

S>И что мне помешает сделать интерфейс? Законы физики? Ровно также вытащу наружу, раз пришол руководитель и просит меня сделать свою работу. Узнаю конечно причины и если они существенны/справедливы — вытащу.

Ну, когда тебя попросят сделать интерфейс, ты скажешь, что это сложно, хлопотно и надо тестировать, и займет это неделю. И у тебя есть некоторая надежда, что менеджер тебе поверит и пойдет искать другого крайнего. А вот убедить менеджера, что на замену слова private на слово public у тебя уйдет неделя, ты вряд ли сможешь.

Pzz>>Нет, уменьшилась. Если представить себе проект в виде графа зависемостей, сложность определяется не столько количеством вершин этого графа, сколько количеством связей между ними.

S>Связи не изменились. Изменяется принцип установки связей. Этот новый принцип требует бОльших телодвижений. Например при переходе от вызова метода объекта к вызову метода об http api сервиса нужно встроить вдобавок обработку ошибок (та-же 404), поддержать версионность API. Как минимум!

Программисты очень любят делать лишние связи и очень не любят думать головой. Если есть выбор, сделать 3 лишние связи или полчаса подумать головой, как без этих лишних связей обойтись, в программе появятся 3 лишние связи.

В то же время, программисты ленивы, как коты, страдающие ожирением. Если для того, чтобы сделать связь, надо сделать интерфейс и обложить его тестами, программист скорее обойдется без лишних связей.

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

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


С изоляцией процессов прекрасно справлялся chroot, придуманный еще в библейские времена. Докер решает проблему, как заполнить то место, куда chroot, тем, что процессу надо для жизни, и при этом не умереть от натуги.

Pzz>>Сколько раз я видел, как во вполне оттестированном дистрибутиве линуха обновление какой-нибудь библиотеки ломало чего-нибудь в какой-нибудь программе.

S>Вспомни хотя бы два раза и озвучь период воспоминаний.

Слушай, я в полном соответствии с теорией Фрейда эти травмирующие воспоминание немедленно вытесняю после того, как они перестают быть актуальными.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.