Признаки монолита в коде

[@FerelUltra]

Во имя Монолита! Мы любим тебя, Монолит. Монолит, зачем ты нас покинул?

[@fallenangel1395]

Твоё время пришло! Иди ко мне!

[@80lk]

блть, я ожидал увидеть здесь эту клоунаду

[@РоманБодю]

Доктор, у меня монолит... Ну так загадывай желание! Я пробовал, загадал, чтобы мой код стал хорошим. Непомогло.

[@pymentor.]

@@fallenangel1395 ты получишь то, что заслуживаешь)

[@purplep3466]

Оооо боже!! Я над этим задумывался, но не думал, что до коментов это дойдет!

[@itcloudguy]

Добавил видео в избранное (что бывает крайне редко). Прослушав, уже вижу проблемы в своем коде. Добавил кучу рефакторинга в свой календарь. Спасибо большое.

[@maestro256]

Монолит это не плохо, это же одна из вариаций архитектуры (в противовес микросервисной, например, которая намного дороже по реализации и производительности). Монолит может быть с множеством мелких модулей, хорошим разделением ответственностей и грамотными интерфейсами везде. И на Spring, например, который способствует низкому зацеплению и принципам SOLID. То, о чем вы говорите, называется просто плохой код :) Ибо сильные зависимости между классами - проблема программиста, а не типа архитектуры.

[@maestro256]

В моём проекте монолит, при этом средний размер класса равен 73 строки, стандартное отклонение равно 80, и это из-за легаси кода с большими классами, а если их выпилить, то и отклонение и средний размер вообще будут равны 70. Так что при монолите ещё как возможен слабосвязанный код.

[@trebiax7960]

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

[@maestro256]

CNET автор говорит "монолит". Монолит это тип архитектуры. Конечно, он хорошо понимает о чем говорит, и всё хорошо кроме терминологии. В русском языке, увы, есть такое наложение. Тот монолит, о котором он говорит можно называть "слипшийся говнокод" 😆

[@trebiax7960]

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

[@Aleksanderis]

Тоже передёрнуло с самого начала, не понял почему прицепились к "монолиту", который сам по себе монолит как монолит.. Судя по-всему имелись ввиду, что-то типа "god object(s)" и "ball of mud". Да, это могут быть последствия монолита, но с таким же успехом можно наговнокодить и с другими архитектурами.

[@amxx8335]

тот самый момент, когда кодишь на языке, в котором даже ООП нету, и слышишь что-то про классы, паттерны, монолиты, и полиморфизм.

[@SaLaGaDH]

Асм?

[@faramozayw1654]

А как связан полиморфизм и ООП?) В ООП не весь полиморфизм, есть ещё параметрический и он прекрасен. Паттерны тоже не являются собственностью ООП Монолит,я думаю, можно сделать не только в ООП 🤔

[@amxx8335]

@@faramozayw1654 термины не совсем знакомые... А в видео они упоминаются.

[@itcloudguy]

Услышав слово "монолит", что можно делать здесь с языком без ООП? Это же про абстракцию.

[@Asiro-S]

@@itcloudguy чем тебе процедурка и фп не угодили?

[@thomwhite4565]

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

[@mr.plague8134]

Монолит есть? А если найду?

[@tsoer2976]

В большинстве писал Монолитом. И даже не подозревал. Записался в патроны

[@thomwhite4565]

Соер, остановись! Я не успеваю смотреть твои видосы. дай хоть время в сортир сходить!

[@АлексДжаванов]

Купи горшок! И ходи в него...

[@ZealousSanity]

А что мешает оттуда(отсюда😄) и смотреть?

[@танунахепта]

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

[@hardhant]

Прямо в точку))) испытал на своей шкуре уже это

[@Vicont4063]

Сильный программист, пади архитектор.

[@michaelcorleone3741]

Все четко... но.... от видосов хочется спать( чуток жизни, пожалуйста, эмоций.. и будешь топчик

[@ruslan_yefimov]

Как сделать игруху для курсача, или презентацию какой-то проги, то монолит - самое то

[@boycovclub]

зайди в гитхаб и скопируй код

[@anzarsh]

А разве копирование кода и передача еще одного параметра это не решение одной и той же задачи разными способами? Т.е. это как бы противоположности, нет?

[@monsterbesel]

Если сейчас подпишусь на патрон за 5 баксов, получу доступ к записи стрима по архитектуре?

[@Unerty]

Ох, спасибо

[@Danilljune]

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

[@olegpopov7860]

Кажется я не туда зашел. Слова слышу, речь не понимаю. Класс, интерфейс, это из Си?

[@itcloudguy]

Нет. Это для ООЯП.

[@ivanaytzhanov8846]

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

[@clickabelno]

лайк

[@alexpapilov2150]

1:42 сильная связанность

[@S0ERDEVS]

Я сказал все верно - сильное зацепление и слабая связность. Связанность и зацепление (coupling) это одно и то же.

[@alexpapilov2150]

​@@S0ERDEVS ладно, ладно, все ровно ООП sucks! шарлотанская хрень придуманная разработчиками чтоб защититься от потока желающих тоже зарабатывать денюшки. Так что называйте как хотите, хоть слабая связность хоть сильная.. все ровно это ничего не значит, и не решает никаких проблем. только их создает.

[@alexpapilov2150]

логика: "Связанность и зацепление это одно и тоже" - ваши слава. При этом в видео вы даете определение "монолиту", как чему то что имеет "сильное зацепление и слабую связность" (при этом из вашего комента, связность и зацепление это одно и тоже.. айяйяй ну и срам). Да признайте вы уже что 10 лет потратили на изучение бессмыслицы, не тащите эту ношу до конца жизни =))

[@S0ERDEVS]

@Alex Papilov, поздравляю, вы теперь поняли почему я использую термин "зацепление",а не "связАННость" (по английски Coupling), а есть еще термин свяЗНость (cohesion). И да "связАННость" и "свяЗНость" - это разные термины, такая вот тонкость, которая взрывает мозг новичкам в вопросах архитектуры.

[@dmitry.gashko]

​@@alexpapilov2150 Какая разница ООП или нет? В той или иной степени это актуально хоть для ООП, хоть для чего угодно.

[@fpv_am]

блииииииииииин вот бы минуточек 20 бы такой синъёр бы погонял меня по моим кодам, хотя бы чему-то новому бы научится у опытного человека

[@АлексДжаванов]

А что такое монолит?

[@SHTORM19ful]

Ааа, так это монолит не из сталкера

[@purplep3466]

прокрастинатор детектед

[@Andrey_142]

Сем?

[@blinddeveloper6488]

@S0ER но веть второй пункт может быть и полезен на пример когда программа должна работать при Болие слабым желези

[@maestro256]

😆

[@maxon861]

плАчу

[@adeusexmachina]

Я своим джуниорам обьяснял это на примере бесполого класса. Изначально классы, которые используют поведенческие параметры имеют право на жизнь, если они не искажают исконную суть класса. Рассмотрим плохой пример о котором говорится в видео: _ Создали Класс - "Бог", который 100% времени использовался, как божество мужского рода. Но вот кейсы продукта расширились и теперь в 10% случаев нужна "Богиня". Денег и времени на пересоздание всего "Бога" нет. Или нет компетентного специалиста, который создал Бога. Но решено, что в целом на данный момент "Богиня" вполне может вести себя как Бог, и лишь в экзотических случаях у Бога будет дизайн женщины. _ Плохим решением будет добавление параметра - размер груди (если 0 - то Бог, если больше 1 то Богиня). Добавляем в интерфейс инициализации этот параметр, а в поведенческие методы добавляем две развилки, которые в зависимости от параметра груди учит вести Бога как Богиня в тех 10% случаев, когда это надо клиенту продукта. _ Казалось бы почему бы и нет? Ведь дешево и быстро. Но как правило аппетит приходит во время еды. И после появления вариативности и гибкости на уровне кейсов применения продукта, новый кейс Богини начинает масштабироваться и обрастать новыми поведениями, свойственными только для божества женского пола. _ И вот теперь уже нужен ещё и ещё параметр, который например определяет такой аспект Божества, как "скала" или "пещера". И продолжением плохой практики будет добавление ещё и ещё параметров в интерфейс инициализации, который укажет 1 (скала), 0 (пещера) и т.д и т.п. А в поведенческие методы добавятся новые вариативности и развилки, которые будут учить Бога делать несвойственные для него вещи, например рожать новых божеств. При этом на уровне кода - к классу по прежнему обращаются как "Бог", ведь изначально н им был. _ Таким образом формируется трансексуальный бесполный класс, который постепенно отходит от своего естества и превращается в многоликое существо, имеющее разные признаки в том числе и единорога при желании заказчика. _ И всё это издержки стартапного подхода с расширением кейсов применения продукта при уменьшающемся бюджете и сроках на разработку. От такого не уйти в экономных стартапах. Главное по мере получения бюджета найти волю и собрать команду для ликвидации технических долгов или пере-проектирования продукта с учетом кейсов, которые изначально даже не планировались. _ Не все проекты изначально имеют штат архитекторов или программистов, способных реализовать микросервисность на уровне кода и поддерживать всё это и масштабировать быстро и самим, пока ещё не создан штат программистов. Клеймить себя за это не нужно, если вы пишете что-то для себя или кому-то бесплатно. Это путь ошибок который вы должны пройти и осознать. Лучший опыт это опыт своих ошибок. Главное не бегать по граблям всю карьеру. _ И на последок доброкачественный пример использования класса Бога, где параметрическое определение его сущности не является плохим примером. Например имеем класс Бог, который заранее известно, что в разное время может обладать тремя сверх способностями на усмотрение пользователя: метать огонь, молнию или молот. Нет смысла плодить для каждой способности отдельного Бога, если эта вариативность не является супер-массивной по отношению ко всему телу класса и не меняет сущность класса до неузнаваемости, превращая его в многоглавое чудовище как в первом примере.

[@adeusexmachina]

@@dmitrypronichev4752 хаха, нет патента ещё нет, пользуйтесь наздоровье) а если усовершенствуете способ, делитесь, потому как есть джуны которые прям схватывают это на лету, а есть те, кто только когда создадут своего франкенштейна вспомнят и поймут о чем я им говорил.

[@Qusbaz-zg2nv]

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

[@arseniikaurov1686]

Пиши на bytecode.

[@S0ERDEVS]

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

[@pavelkostetskiy7561]

@Юрий только если ты пишешь код, который не нужно будет поддерживать))

[@johndavids6297]

@@S0ERDEVS Не уместное сравнение, было бы правильнее сказать: - Не важно что ты ешь, главное это стабильная работа организма.

[@РоманФетисов-и8у]

@@johndavids6297 "стройная фигура" один из признаков стабильной работы организма )