Качество кода: нестабильность и абстрактность
Вставка
- Опубліковано 15 вер 2024
- #soer #itubeteam
Основной канал для общения и публикации новых видео - Телегарм - t.me/softwaree...
Спонсорство - donate.s0er.ru
Сайт платным контентом - soer.pro
Зеркало для видео Дзен Видео - zen.yandex.ru/...
GitHub - github.com/soe...
Чат для программистов - / discord
Группа ВК - codeart...
> В предыдущих публикациях я использовал для связей имена Efferent (центробежный) и Afferent (центростремительный), Ce и Ca, вместо Fan-out и Fan-in соответственно. Это был всего лишь каприз с моей стороны: мне нравилось сравнение с центральной нервной системой.
Дядь-Боб, 132 страница, Чистая архитектура. Искусство разработки программного обеспечения. - СПб.: Питер, 2018.
Кстати, принципы REP, CCP, CRP, Диаграмма противоречий принципов связности тож мне кажется было бы не плохо осветить на канале. А то в ютубе ощущение, что главное выучить расшифровку абривиатуры SOLID - и все ты понял клиен архитктуру.
Уникальный контент, вот что нам нужно!
Жаль просмотров не будет
не правда. я вот смотрю :)
чем меньше просмотров, тем больше зарплата у посмотревших)
(шутка, пишите все хорошо, пожалуйста)
Просто наслаждение получил! С удовольствием бы купил контента с патреона - если бы хоть какое-то описание было и структура в каком видео о чем говорите.
Хорошо, что у меня нет таких больших проектов, чтобы это пригодилось. но на заметку взял. спасибо :)
Как и всегда интересный ролик)
Спасибо большое за труд)
Полезно смотреть ваши видосики)
Всегда стараюсь определять минимально необходимые интерфейсы под конкретные юз-кейсы и использовать архитектуру с однонаправленной зависимостью слоев, например, чистую архитектуру. Теперь могу логически обосновать зачем, спасибо)
проблема в том, что в реальных бизнес рулах, почти нет однонаправленных зависимостей...
@@albrehtdurer557 бизнес логика это отдельный слой, который ссылается на слой i/o.
@@rishatsharafiev если не затруднит, можно конкретный маленький пример?
Спасибо, просто и интересно.
Очень полезное видео, большое спасибо!
Спасибо за полезный контент)!
Большое спасибо)
Спасибо!
Под конец ролика понял, что читал про это у самого Мартина в чистой архитектуре. Но Соер конечно намного понятнее объясняет, спасибо!
Самое удобное здесь - что получаешь порциями информацию и не зацикливаешься на всех моментах (пытаясь это всё внедрить)
У меня обратное мнение. В книге гораздо понятнее это описано.
дякую, дуже круто
что-то твердо был уверен, что coupling - это связность, зацепление - cohesion
я тоже подметил это, словил диссонанс
"Пожалуй в любой литературе по объектно-ориентированному проектированию встречаются эти два понятия. Считается, что любая спроектированная система, должна удовлетворять принципам низкой связности и высокого зацепления модулей. Соответствие данным шаблонам позволяет легко модифицировать и сопровождать программный код а также повышает степень его повторного использования." - абзац текста, взятый из перво-попавшейся ссылки на хабр с гугла
По мне так наоборот было бы как раз более понятно. То есть, зацепление - то, как модули "цепляются" друг за друга, а связность - то, насколько компоненты модуля связаны между собой в вопросе решения конкретной задачи, составляют ли они единую логическую единицу.
У тебя что-то не то с предложением.
@@Tuhtarov так да, ты так и учился наверное по первым попавшимся ссылкам с гугля?))
Шикарное объяснение
Спасибо
Очень интересно, спасибо
Жду ещё подобных видео.
Спасибо, оч круто!
Благодарю за видео! Существуют средства для автоматического расчета нестабильности и абстрактности?
Есть одна правка для лучшего понимания темы. Нестабильность нужно считать от 0 до -1, и график вести налево. А ещё лучше считать Стабильность (без не) от 0 до 1, тогда график направо. А иначе мозги после математики долго кипят (лишние минуты) и не могут сварить в чём проблема правой/левой стороны.
Ничего не понял, но очень интересно
спасибо!
Что есть красная зона для коэффициента связанности? Неважно афферентный, или эфферентный. 5 - это много?
Каждый раз смотрю и понимаю, на сколько ты поход на Линуса XD
Попиваю чаёк и учу программирование вот это коасс
Но вы приподносите нестабильность как что то плохое. Возможно для тех кто услышит эту тему в первый раз тут это так и запомнится. Но согласно тому же мартину, не стабильность это не что то плохое. Нестабильный компонент - компонент который принимает хорошо изменения и от которого почти ничто не зависит. В него легко вносить изменения. Стабильный компонент от того и стабильный, что внести в него изменения сложно. При этом нестабильные компоненты при низком уровне абстракции не являются проблемой, поэтому нижний правый угол и не является зоной боли в оригинальном графике. Как и стабильные компоненты, в которые сложно вносить изменения при высоком уровне абстракций
Хорошо бы какие-то численные оценки. "Слишком большое" значение Се - это сколько? 1? 1000? 0.4?
Я отталкиваюсь обычно на класс Ce - от 3 до 7, на компонент умножаем пропорционально классам, Ca - играет от назначения класса, скажем для доменных задач, более 10 уже плохо, для утилитарных задач (типа библиотекчный код) я вообще Ca не ограничиваю, так как бессмысленно.
@@S0ERDEVS спасибо
Пример как можно "обнаучить" (скорее "обпсевдонаучить") любую область
Странно каким образом увеличение связей в сторону нашего компонента вдруг увеличивают его стабильность. Отсюда похоже и костыль про любые 2 из 3х параметров
5:20 - но ведь компонент А может менять компонент B через его методы
Здесь имеется ввиду не изменение состояния объекта во время работы приложения, а изменение логики во время разработки. Ну то есть если кто-то решил переписать класс A, то это никак не сломает класс В, потому что он не зависит от класса A, а вот наоборот такая ситуация вполне возможна
Спасибо за видео. Можете посоветовать литературу по архитектуре приложений? За ранее благодарен.
Мартин фаулер Фореве
Очень крутой контент, жалко что ничего не понятно.
Универспльность кода (абстрагированое от реализации) увпличивает время разработки. Руководитель не деволен. Конкретный код привязанный к к конкретной реализации затягивает время на модификацию, даже для не больших изменений, так же вводит в ступор руководителя. Как проектировать в стиле золотого сечения???
Тут явно руководитель лишний.
9:18 "Если 2 из 3-ёх параметров находятся в красной зоне, не важно в каком порядке" - есть три комбинации, с одной из них я согласен - Ce и I. Т.к чем меньше Ca по отношению к Ce, тем и больше I. Но вот с остальными комбинациями получается ерунда: Если у нас Ca по отношению к Ce будет велико, то уже никак не получится, что I будет у красный зоны, т.е одна комбинация у нас уже вообще выкинулась. ХОтя даже больше, т.к у нас две комбинации, в которой задействовано Ca, которая в красной зоне - Ca и I, Ca и Ce. Хотя единственная спорная комбинация - Ca и Ce, может ли тут вообще произойти такое, что они обе будут в красной зоне? Предположим что может, и они равны друг другу, но тогда выходит ,что I = 0.5, что судя по твоему утверждению тоже плохо
X - красная зона, О - ок
Ce Ca I
X X O - проблема
O X X - маловероятно, так как Ca уменьшает I, но на границах может вылезти что-то подобное
X O X - проблема
0.5 может быть и хорошо если
O O O - возможно если слабое Ca и Ce, и примерно равны, тогда I может быть 0.5 и это норм.
@@S0ERDEVS Ca и Ce каким образом могут быть большими одновременно? Нужен конкретный пример, т.к если ты утверждаешь что когда они равны - это норм, то тогда выходит что может быть две оставшиеся ситуации Ca > Ce и Ca < Ce. Но оба этих варианта не подходят под утверждение «Ca и Ce находятся в красной зоне одновременно», т.к если Ca = Ce не подходит, то Ca > Ce не подходит тем более, остаётся вариант Ca < Ce. Но тогда возникает вопрос «на сколько он может быть меньше(а вернее во сколько) чтобы он ещё оставался также в красной зоне, как и Ce”. Предвосхищая ответ «точной границы быть не может» - тогда из этого следует, что не обязательно Ca = Ce является тем, что они «оба не в красной зоне», мб начиная уже с данного соотношения идёт «красная зона», так же мб быть что она начинается и с соотношение 4:7(Ca:Ce)
@@danjilov3965 элементарно
16 компонент используют компонент A - Ca = 16 при этом компонент А зависим на 15 компонентов, которые использует в своей работе Ce = 15. Индекс будет в районе 0.5.
Наверное это будет глупый, но вопрос таков. На каких специальностях подобному учат? Если вообще учат
На работе научишься. В России в целом программа обучения отстаёт от требований в отрасли. Ближе всего ВШЭ.
@@gaijin_nnsu мне академические знания бы получить хотелось бы. На работе я уже учусь. Да и я не говорил, что только российский вуз/специальность в ответ жду
@@gaijin_nnsu так этому учат вообще-то. Этим принципам сто лет в обед
@@illiamaksymenko804 не соглашусь. С красным дипломом вмк вы все равно будете джуном. И сильно охотиться за вами будут только на что то низкоуровневое на плюсах или вообще си. При этом платить как за джуна на каком нибудь руби вам не будут)
@@gaijin_nnsu так я и не говорил что будут охотиться. Одной зубрежки теории недостаточно в этом случае. Нужно на реальных проектах смотреть как это работает и набивать шишки
Так и будешь считать нестабильность и абстрактность, а фичи когда пилить? ПМ не похвалит)
Душный дед опять забыл принять таблетки(шучу)
Спасибо за видео)
Душнильный комментатор забыл принять таблетки(шучу)
Спасибо за коммент)
@@artemv3160 ща приму, забыл совсем
Очень ценные метрики
Теория хороша, но есть ли какие-то автоматизированные тулзы для анализа классов/модулей?
Для Java куча всего, сходу нагуглил jArchitect
Чет я не понял, если код будет находится в рекомендуемом овале, то он может быть абстрактен на 100% судя по графику. Он же не будет нести никакой пользы?
Я правильно понимаю, что по мере абстрактности нужно больше стремится к 0.5?
Оценка применяется к рабочему коду. Код не пишется чтобы "технически" куда-то попасть в графике. Написали код, видите где он на графике. если ушел куда-то не туда смотрите почему, если можете поправить - поправляете, если нет, то работаете дальше.
Заказчик: Вскопайте 1 кв метр грядки и посадите цветы
Кодер теоретик: проектирует тракторы и комбайны, месяцы на реализацию и года на сервисное обслуживание техники.
Кодер практик: уже вскопал лопатой и пилит другой проект.
А теперь на момент представь, что тебе нужно вскопать пару тысяч гектар. Лопату в руки возьмёшь?
Именно для подобных задач, люди и придумали все эти глупые тракторы и комбайнеры, вместе с их сложной инфраструктурой.
Я прям чувствую что автор читает и сам не до конца понимает ) может поэтому и учит нас чтоб самому научиться ))
Все проще, здесь сложная цепочка переводов и правильного произношения, приходится постоянно думать как перевести и как правильно произнести слова, да еще и линию повествования не упустить. )
Забавно как люди, которые никогда не делали подобных видео, выстраивают теорию заговоров и ищут скрытый смысл, а ответ лежит на поверхности.
@@S0ERDEVS В любом случае спасибо за видео, просто я считаю можно куда проще объяснить, но т.к. я видосики не снимал возможно я не прав )
Видео ниочём. Эта инфа есть на первой странице любой книги по архитектуре