логика та же?

на личности давайте на блоге переходить, там смешнее будет)

да не будет там смешнее. Знаешь почему? Потому что мне лень

да. и большие классы по 5000 строк это не проблема сама по себе. проблема, если внутри там нет четкой структуры. да?

классы по 5000 строк не являются сами по себе проблемой. проблемой является связанность между классами по 5000 строк

классы по 5000 строк не являются сами по себе проблемой. проблемой является связанность между классами по 5000 строк

ну вот здесь мы и разошлись во мнениях) о чем собственно и пост

я считаю что большие классы проблема сама по себе

И большие проекты

я считаю что большие классы проблема сама по себе

у этой проблемы есть решение - отказаться от классов (привет ФП)

ну в общем аргумент о том, что статья написана плохо -- разбит

ты просто не согласен с ее главным посылом

но это не значит, что он плохо изложен

помоему вы зря тратите времяна абсолютно неправильную аналогию: монореп = класс 5000 строк

ну в общем аргумент о том, что статья написана плохо -- разбит

1. не разбит. ты просто говоришь "бла бла ничего не слышу мое мнение бла бла"

я считаю что большие классы проблема сама по себе

А причем тут классы вообще

вот я тоже не понимаю

1. не разбит. ты просто говоришь "бла бла ничего не слышу мое мнение бла бла"

+)

1. не разбит. ты просто говоришь "бла бла ничего не слышу мое мнение бла бла"

на личности плиз на блоге переходить)

лол

на личности плиз на блоге переходить)

А если нет, то что?

у нас проект с 2002 года и у нас монореп

это пиздец

ты просто не согласен с ее главным посылом

да, я не согласен. Потому что в статье вообще не прослеживается мысль про границы. Ты как границу модуля преподносишь репозиторий. Хотя можно просто "сделать папочку" и сложить туда код относящийся к модулю. Как если бы у тебя было 100 репозиториев для проекта и ты просто сделал бы 100 директорий в одном репозитории.

хотя я не уверен что с микросервисами хуже бы не стало, учитывая как у нас взаимодейстие между отделами строится)

думаю некотоыре просто стали бы копироать нужные куски кода себе?

из сервиса в сервис

хотя я не уверен что с микросервисами хуже бы не стало, учитывая как у нас взаимодейстие между отделами строится)

вот об этом надо писать статьи. О том что люди путают понятие "монорепозиторий" и"монолит" а потом противопоставляюют этому "микросервисы"

хотя я не уверен что с микросервисами хуже бы не стало, учитывая как у нас взаимодейстие между отделами строится)

мне кажется дело то не в монорепе

вот об этом надо писать статьи. О том что люди путают понятие "монорепозиторий" и"монолит" а потом противопоставляюют этому "микросервисы"

но микросервисы это же автоматом, означает что будет не монорепозиторий

вот об этом надо писать статьи. О том что люди путают понятие "монорепозиторий" и"монолит" а потом противопоставляюют этому "микросервисы"

напишу

или можно из одной репы раскладываться на разные сервисы разные участки кода?

не я понимаю что переубедить Егора у меня не выйдет. Просто высказываю недовольства чтот Егор уже не торт. Раньше его набросы и аргументы заставляли задуматься. А сейчас чет как-то нет

но микросервисы это же автоматом, означает что будет не монорепозиторий

нет, микросервисы прекрасно вписыватюся в монорепозитории

звучит дико для меня

микросервисы это больше про шаринг знаний и управление инфраструктурой

ой

монорепозитории*

я как один из основный плюсов микросервиса выделял, административнео и техническое разделение работы

а микросервисы это просто про независимый деплой и декомпозицию системы на "большие объекты" (прям как алан кей хотел) которые владеют данными и обмениваюются сообщениями

звучит дико для меня

а че такого, считай у тебя экосистема в одной репе и разбита на части - микросервисы

т.е мы сидим в совей репе, предоставляем апи сервиса и никто к нам не залезет в наш уютный миро

монорепозиторий не означаетчто весь код там связан друг с другом

я как один из основный плюсов микросервиса выделял, административнео и техническое разделение работы

Из минусов кроме поддержки кода, какие можно выделить ?

я как один из основный плюсов микросервиса выделял, административнео и техническое разделение работы

вот смотри. Предположим что у меня есть проект. И фича А сделана за счет стороннего сервиса А, фича б - за счет стороннего сервиса Б (например чаты, видеозвонки, CRM, форма обратной связи какая, какой-нибудь бложик на какой-нибудь облочной CMS-ке)

а че такого, считай у тебя экосистема в одной репе и разбита на части - микросервисы

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

все эти штуки живут в своих репозиториях, деплоятся независимо - но это же НЕ микросервисы

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

ну так у них все отдельно)

просто лежат они рядом.

scheduling payments chats calls auth

типа так

каждый "модуль" можно независимо собрать, независимо задеплоить

вот смотри. Предположим что у меня есть проект. И фича А сделана за счет стороннего сервиса А, фича б - за счет стороннего сервиса Б (например чаты, видеозвонки, CRM, форма обратной связи какая, какой-нибудь бложик на какой-нибудь облочной CMS-ке)

хм...а вот у меня на прошлом проекте был сервис/словарь, который возвращаял по одному из строковых представлений страны: Россия, РФ, рф, рашка и т.д ее код в нужном формате...и он отдельно деплоился как бы и к нему обращались по http...это микросервис или нет?

можно вместе, можно независимо, можно общие модули как-то по хитрому реюзать, можно внедрять штуки которые по измеенниям проверяюют контракты между сервисами, можно много чего

хм...а вот у меня на прошлом проекте был сервис/словарь, который возвращаял по одному из строковых представлений страны: Россия, РФ, рф, рашка и т.д ее код в нужном формате...и он отдельно деплоился как бы и к нему обращались по http...это микросервис или нет?

микросервисная архитектура это как ООП - нет смысла о ней говорить если у тебя один объект или один микросервис и "все остальное") ты ж понимаешь))

микросервисы это про децентрализацию и низкую связанность

Уди Дахан часто говорит фразу "микросервис != deployment target".

при этом это не конфликтует с утверждением что каждый микросервис можно независимо деплоить

scheduling payments chats calls auth

Тогда в такой структуре должно быть чётко описанное взаимодействие, которое бы не повлияло бы при очередном обноввлении одного из микросервисов

просто ятак поинмаю микросервис - сервис с четко определеннйо ответственностью, разрабатываемый и депломый отдельно от основного продукта. Ну и ключ в тмо что нельзя обратиться к его объектам напрямую в коде программмы, а только через внешнее апи

Тогда в такой структуре должно быть чётко описанное взаимодействие, которое бы не повлияло бы при очередном обноввлении одного из микросервисов

а если бы структура была другой тебе не нужно было бы четкого описания?

просто ятак поинмаю микросервис - сервис с четко определеннйо ответственностью, разрабатываемый и депломый отдельно от основного продукта. Ну и ключ в тмо что нельзя обратиться к его объектам напрямую в коде программмы, а только через внешнее апи

а основной продукт - это тоже микросервис? или просто "другие микросервисы"? или микросервисы для тебя это инфраструктурные шляпы типа "pdf генератор" или там "mail сервер"?

т.е если у меня супер салбосвязанные модули, которые общаются только черзе определенные для этого методы(порты) но в рамках одного репозитория и написанные как части одного проекта я это микросервисом не назову

просто ятак поинмаю микросервис - сервис с четко определеннйо ответственностью, разрабатываемый и депломый отдельно от основного продукта. Ну и ключ в тмо что нельзя обратиться к его объектам напрямую в коде программмы, а только через внешнее апи

вроде можно такую систему построить, что бы прям к объектам в другом МС обращаться

т.е если у меня супер салбосвязанные модули, которые общаются только черзе определенные для этого методы(порты) но в рамках одного репозитория и написанные как части одного проекта я это микросервисом не назову

ты не можешь их независимо разрабатывать и независимо деплоить? почему?

а если бы структура была другой тебе не нужно было бы четкого описания?

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

а основной продукт - это тоже микросервис? или просто "другие микросервисы"? или микросервисы для тебя это инфраструктурные шляпы типа "pdf генератор" или там "mail сервер"?

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

т.е если у меня супер салбосвязанные модули, которые общаются только черзе определенные для этого методы(порты) но в рамках одного репозитория и написанные как части одного проекта я это микросервисом не назову

И будешь не прав

ты не можешь их независимо разрабатывать и независимо деплоить? почему?

а можно пример хорошей практики по разработке микросервисов. Я один видел на хабре, но в него полетело много обоснованной критики, в стиле того что каждый микросервис должен жить в своём докере

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

и монорепозитории тут как раз помогают потому что у тебя все всегда синхронизировано между собой. Всегда можно сгенерить/прокинуть общие контракты и проверить их на уровне CI. Ну и опять же - то о чем ты говоришь - это проблема которая возникает в любом случае даже если мы просто говорим о нескольких модулях между которыми есть зависимости. Зависимости полагаются на контракты, нужно проверять соблюдаюют ли модули свои конттракты

ты не можешь их независимо разрабатывать и независимо деплоить? почему?

потому что нет технического ограничения, кто то может зайти из команды, и написать своей хуйни в мой сервис + если спуститься до конкретных реализаций, то в пыхе пока не подвезли возможность приватных классов и у меня нет гарантии, что никто не нарушит инкапсуляцию и не будет юзать мой сервис дергая методы, которые я делал для себя

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

"не связан ни с каким кодом" - обычно это невозможно и простто связь перетекает в сообщения на уровне RPC. Идеальный вариант - если если твои микросервисы друг с другом общаются по pub/sub

а можно пример хорошей практики по разработке микросервисов. Я один видел на хабре, но в него полетело много обоснованной критики, в стиле того что каждый микросервис должен жить в своём докере

Есть кнжика Mathias Noback про микросервисы...я ее пока не читал, но он мне как автор нравится, читаю его блог так что могу ее порекомендовать

"не связан ни с каким кодом" - обычно это невозможно и простто связь перетекает в сообщения на уровне RPC. Идеальный вариант - если если твои микросервисы друг с другом общаются по pub/sub

так это две большие разницы

я так Сэма Ньюмана хочу почитатть

уже год хочу но лень

потому что нет технического ограничения, кто то может зайти из команды, и написать своей хуйни в мой сервис + если спуститься до конкретных реализаций, то в пыхе пока не подвезли возможность приватных классов и у меня нет гарантии, что никто не нарушит инкапсуляцию и не будет юзать мой сервис дергая методы, которые я делал для себя

И причем тут монорепы, если у тебя проект может быть так построен, что у тебя все в VCS - админы

есил связь через RPC то у меня есть четкий интерфейс, и я буду уверен что иначе инкто не сможет обратиться ко мне

потому что нет технического ограничения, кто то может зайти из команды, и написать своей хуйни в мой сервис + если спуститься до конкретных реализаций, то в пыхе пока не подвезли возможность приватных классов и у меня нет гарантии, что никто не нарушит инкапсуляцию и не будет юзать мой сервис дергая методы, которые я делал для себя

нет ограничений - придумай) у тебя есть CI сервер)

Есть кнжика Mathias Noback про микросервисы...я ее пока не читал, но он мне как автор нравится, читаю его блог так что могу ее порекомендовать

ссылку моэно

и все могут твою репу отредактировать все равно

ссылку моэно

можешь вечером мне написать, у меня дома есть эта книжка

и все могут твою репу отредактировать все равно

можно запретить людям пушить в мастер)

можешь вечером мне написать, у меня дома есть эта книжка

хорошо

ну и опять же - в чем проблема? это ж GIT - главное что бы форс пуш в мастер был отключен

а может быть даже не гит а меркуриал - тогда еще проще

вы сейчас решаете проблему, которой не существует в случае, если разработка ведется как два разных проекта) и согласовывается лишь API

+ не забывайте про административную часть

если у вас в команде меньше 100 человек, проект не 20 летний, и нет менеджеров которым надо еще вчреа, то тогда да конечно, можно много как извращаться по поводу ограничений прав, ревью и т.д

а в реальном мире разграничение сервисов по командам и репозиториям, со стандартизацией протокола общения между ними - БЕЗ возможности "о бля что то этот метод не принимает числа тока строки, расширю как я тип параметра" - это самый надежный вариант

если у вас в команде меньше 100 человек, проект не 20 летний, и нет менеджеров которым надо еще вчреа, то тогда да конечно, можно много как извращаться по поводу ограничений прав, ревью и т.д

менеджерам всегда нужно вчера, проектов больше чем на 100 человек до жопы, 20 лет или 5 лет уже роли не играет в таких масштабах обычно

а в реальном мире разграничение сервисов по командам и репозиториям, со стандартизацией протокола общения между ними - БЕЗ возможности "о бля что то этот метод не принимает числа тока строки, расширю как я тип параметра" - это самый надежный вариант

прям самый самый. ты просто никогда не ресерчил другие)

короч громкие заявления

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

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

1. не сложно, вопрос инструментов 2. продержутся пока ограничения не будут мешать, тогда просто пересмотреть оные. 3. помимо гита есть и другие распределенные VCS которые умеют разграничивать доступ 4. GIT идеален если ты пилишь linux kernel и принимаешь патчи через email-ы (и зовут тебя Линус, или Лайнас. не уверен как правильно)

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

ну и да - я не говорю что тебе НУЖНО переходить на монореп. Монорепы решаютт определенные проблемы и датю определенные возможности, но не бесплатно. Дальше вопрос cost/benifit анализа для конкретно твоей ситуации

это... настораживает

Согласен)

ждем белпошту