Вы стоимость поддержки такого "продукта" оцениваете?) Что будет через год-два с таким продуктом, сколько затрат будет на его поддержку, который не использует чистую архитектуру

все есть яд и все есть лекарство)

Вы стоимость поддержки такого "продукта" оцениваете?) Что будет через год-два с таким продуктом, сколько затрат будет на его поддержку, который не использует чистую архитектуру

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

прикольно

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

А для чего потом рефакториь?)

А для чего потом рефакториь?)

Ну тут чаще просто переписывать надо полностью)

Ахахха) А у тебя монолит

Условно самое тяжелое для меня было отделить понятия Inversion Of Control и Dependency Inversion. И после этого стало понятно, что у тебя слои должны идти изнутри наружу. То есть на самом низком уровне у тебя есть domain, где ты описываешь сущности и их поведение, нужно понять, что уровень domain с сущностями не зависит ни от чего так как он в самом низу. То есть от него зависят, но он не зависит. У тебя так же есть слой работы с базой данных, который регистрирует все, что возможно и отдает тебе только интерфейсы для работы с репозиториями. То есть условно контракт репозитория у тебя меняться не должен, а реализация внутренняя может меняться спокойно. То же самое с уровнем бизнес логики. Ты зависишь от слоя репозиториев исключительно контрактами. То есть ты в бизнес логике используешь просто методы интерфейса, тебе плевать на реализацию этого. Выше уже уровень каких-нибудь контроллеров будь то grpc или http не важно, ты выкенешь один фреймворк напишешь на другом тебе не придется всю остальную программу переписывать. Короче говоря суть ровно в том, чтобы каждый слой выше использовал только интефейсы слоя ниже, чтобы не зависеть от реализации. сущности - > слой доступа к базе -> слой бизнес логики -> транспортный/представительский слой. И все это регистрируется в какой-то входной точке условно для го это cmd/app/main.go

и я думаю в глубине проектов мэйла все еще есть какие-нибудь куски кода на перле

Если этот код до сих пор работает, значит он проработал свои 15 лет. Видели проекты на голанге, которым хотя бы по 8 лет?

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

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

Я не спрашиваю про "плохо" или "невозможно". Я спрашиваю, что мешало писать микросервисы на перле раньше. Почему вы пытаетесь микросервисную архитектуру выставить неким ноу-хау? Если раньше писать было как-то проблемно, то охота услышать почему. Как бы мозгов в том, чтобы разбить большой проект на несколько мелких, немного. Об этом могли в 80х спокойно размышлять.

Как бы у нас crudо-яп, в котором у сервиса срок жизни как у летнего насекомого. А разговоров про ЧИ как будто у нас жаба и мы тут щас на заводы и АЭС софт интегрируем

Как бы у нас crudо-яп, в котором у сервиса срок жизни как у летнего насекомого. А разговоров про ЧИ как будто у нас жаба и мы тут щас на заводы и АЭС софт интегрируем

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

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

Поэтому я и спрашиваю про софт и время его жизни. Как бы что такое большая программа, которой десять лет и она написана на пехепе/петоне/крестах, как бы многие видели. Примерно можно понять, какие у нее бывают проблемы. А с голангом что? Кто-то вживую видел такой софт? А вот по докладам уже можно заметить, что народ наебенил мамкиного хайлоада на свои 5к рпс, а внезапно оказывается, что микросервисы из этих 5к рпс генерируют еще 50к рпс внутри - и весь ресурс компании начинает выжираться попытками обслужить такого микросервисного монстра.

Я видел софт в опенсорс, где количество микросервисов уже мешает понять потоки данных🤣🤣🤣 Развернуть непосвященному невозможно

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

Не нужно крайностей просто, везде нужен правильный баланс. 20 микросервисов хорошо, 200 плохо

Я как-то смотрел доклад Сысоева про nginx. Меня очень впечатлил его ответ про htaccess. Ему задали поднадоевший вопрос, почему в nginx нет такой прекрасной и удобной штуки как htaccess. На что он ответил, что nginx разрабатывался в крупной компании под нагрузку, деньги и процесс разработки крупной компании. Он про определенные бизнес-процессы характерные для таких компаний. И когда маленькая фирма с трема программистами и одним админом пытается переехать на nginx, она не понимает, почему нет htaccess. А ответ как раз в этом

но в целом да, я с вами согласен, что бывает зачастую запарно

Не нужно крайностей просто, везде нужен правильный баланс. 20 микросервисов хорошо, 200 плохо

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

Но это можно (как разработчику) это понять - микросервис в Go единственный понятный способ инкапсуляции при отсутствии полноценного ООП

Да, где-то так

Всем привет. Сережа тут ?

Всем привет. Сережа тут ?

да, он выгорел, сидит в углу бормочет что в Го есть ООП

Может такое быть из-за того, что сам я сижу в Грузии, и они не хотят на удаленку. Или могут быть другие причины и какие?

Я к тому, что у джунов слабо поставлены софт-скиллы, и вести что-то они едва ли будут способны.

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

Но не в сфере программирования.