Post AM0VhdnOhxFmm87KC0 by NaiJi@udongein.xyz
 (DIR) More posts by NaiJi@udongein.xyz
 (DIR) Post #ALzZFpUVpvbFb9JluS by GagyyaRinqq@soc.phreedom.club
       2022-07-29T18:29:05.688739Z
       
       1 likes, 1 repeats
       
       @rf хэй, народ, кто читал, читает "чистый код " за авторством Роберта Мартина, насколько аргументированно разбивать функции до одной операции? Меня смущает, что это генерирует тонну ненужных переходов, да, компилятор все заинлайнит, но тем не менее, там, где мы можем обойтись 10-20 строками средней функции предлагается писать 5-10 простых функций. Это раздует код, не будет ли это излишнем?
       
 (DIR) Post #ALza7uiyaySnSysAT2 by inexcode@social.inex.rocks
       2022-07-29T18:39:03Z
       
       0 likes, 0 repeats
       
       @GagyyaRinqq аргументы-то он сам в книге и приводит.По своему опыту скажу, что разбиение функций ни к чему плохому не приводило. Зато значительно повышало читаемость кода.
       
 (DIR) Post #AM0LbsxCRFb0VZJpb6 by NaiJi@udongein.xyz
       2022-07-30T03:31:06.454444Z
       
       0 likes, 0 repeats
       
       @GagyyaRinqq @rf Мне гораздо больше нравится подход из немного другой книги. Чтобы не было потребрости возводить дробление в абсолют:"Long methods aren’t always bad. For example, suppose a method contains five 20-line blocks of code that are executed in order. If the blocks are relatively independent, then the method can be read and understood one block at a time; there’s not much benefit in moving each of the blocks into a separate method. If the blocks have complex interactions, it’s even more important to keep them together so readers can see all of the code at once; if each block is in a separate method, readers will have to flip back and forth between these spread-out methods in order to understand how they work together. Methods containing hundreds of lines of code are fine if they have a simple signature and are easy to read. These methods are deep (lots of functionality, simple interface), which is good.The method should be deep: its interface should be much simpler than its implementation. If a method has all of these properties, then it probably doesn’t matter whether it is long or not.The decision to split or join modules should be based on complexity. Pick the structure that results in the best information hiding, the fewest dependencies, and the deepest interfaces."– A Philosophy of Software Design. John Ousterhout
       
 (DIR) Post #AM0MO0hmvEJCRt3erI by inari@udongein.xyz
       2022-07-30T03:17:10.369697Z
       
       0 likes, 0 repeats
       
       @GagyyaRinqq @rf мне кажется ты (и возможно ниже по треду люди) совершенно не поняли о чем шла речь. Если правильно помню, речь шла о том, что функции подчиняются тому же SOLID принципу, а именно первому - SINGLE RESPONSIBILITY. Т.е. один "юнит" должен обладать одной ответственность. Если у функции ответственностей много то это скорее всего какая-то простыня-процедура. Если это add то только add x y может быть add x x1 x2 x3 xn (args), но не add x y cats которое и складывает и тосты жарит. И нет это не лишнее, в подавляющем большинстве случаев оно оправдано, иначе ф-ей и пользоваться будет неудобно - назначение непонятно и тестами фиг покроешь и как потом расширять (если потребуется) тоже непонятно если оно и так уже и швец и жнец и на дуде игрец.
       
 (DIR) Post #AM0MO1EkwegE68TzFI by NaiJi@udongein.xyz
       2022-07-30T03:39:47.255545Z
       
       0 likes, 0 repeats
       
       @inari @GagyyaRinqq @rf насколько я помню, Мартин разделяет SRP и идею, что функция должна делать что-то одно. То есть это не одно и то же. SRP – это про доменное владение, да, мол, компонент системы должен быть отвественнен только за один домен этой системы. Не делать что-то одно, а именно что агрегировать в себе функционал работы по одной сущности. Например, менеджер, который считает зп, резервирует отпуска и занимает кадровыми задачами – это нарушение SRP по Мартину. Нужно разбить на менеджеры по каждому из доменов: отпуск, зарплата и кадровые операции. Но это не то же самое, что "делать одно и только одно", потому что тогда мы должны вводить полиморфные объекты действий для каждой операции каждого домена. То есть по классу для каждой функции вообще, а это очевидно избыточная абстракция, если только у нас не Event Driven какой-нибудь
       
 (DIR) Post #AM0RqB6sKa0Sb62jlw by inari@udongein.xyz
       2022-07-30T04:31:22.445699Z
       
       0 likes, 0 repeats
       
       @NaiJi @GagyyaRinqq @rf и да и нет - в clean architecture с его же слов все принципы солид применимы к любому уровню абстракций, сущностей и синтаксиса.
       
 (DIR) Post #AM0RqBYWfm7lyqyos4 by NaiJi@udongein.xyz
       2022-07-30T04:40:54.250595Z
       
       0 likes, 0 repeats
       
       @inari @GagyyaRinqq"Из всех принципов SOLID наиболее трудно понимаемым является принцип единственной ответственности (Single Responsibility Principle, SRP). Это, вероятно, обусловлено выбором названия, недостаточно точно соответствующего сути. Услышав это название, многие программисты решают: оно означает, что каждый модуль должен отвечать за что-то одно.Самое интересное, что такой принцип действительно существует. Он гласит: функция должна делать что-то одно и только одно. Этот принцип мы используем, когда делим большие функции на меньшие, то есть на более низком уровне. Но он не является одним из принципов SOLID — это не принцип единственной ответственности.Соответственно, окончательная версия принципа единственной ответственности выглядит так: Модуль должен отвечать за одного и только за одного актора."– Чистая Архитектура.То же самое, вроде как. Разница лишь в том, что я в примере выше назвал это доменом. Дробление функций или понижение связности компонентов посредством распределения отвественности за домены/акторы – это всё же чуть-чуть разные концепции
       
 (DIR) Post #AM0T30PNWwDh7rNWAS by inari@udongein.xyz
       2022-07-30T04:54:10.874011Z
       
       1 likes, 0 repeats
       
       @NaiJi @GagyyaRinqq пусть будет так, щас не готов копаться и опровергать, мотивы у принципов могут быть разные, но результат в итоге тот же.
       
 (DIR) Post #AM0U4oxt9CPWATwwBk by NaiJi@udongein.xyz
       2022-07-30T05:05:56.843821Z
       
       0 likes, 0 repeats
       
       @inari @GagyyaRinqq Это правда. Я согласен. Но в деталях Мартин почему-то конкретно разделяет SRP как часть SOLID, а дробление функций -- как не его часть. Здесь дело не в том, что я его защищаю, я просто в рамках треда стараюсь оперировать теми конкретными понятиями, которые он вводит. Я подозреваю, что это из-за того, что они немного про разное в своей идее, если мы не будем думать про эти два принципа слишком абстрактно. SRP -- это про то, о чём мы говорим, о каких сущностях системы. Мы вычленяем какие-то концепции и представляем их в виде самостоятельных компонентов, то есть обобщаем в акторы или домены, я не знаю, как он их точно называет. Это именно про ЧТО. ЧТО есть в нашей системе. А дробление функций на много "делающих одно и только одно" внутри этих самых ЧТО -- это скорее уже про уже организацию программного кода с процедурной точки зрения, если угодно.
       
 (DIR) Post #AM0VJ0Ge1OjnEM36dk by NaiJi@udongein.xyz
       2022-07-30T05:19:45.487263Z
       
       0 likes, 0 repeats
       
       @inari @GagyyaRinqq Ладно. Перечитал. Я душнила, короче. Забей. И вообще, читайте "A Philosophy of Software Design" :aqua_thumbs_up: могу .epub кинуть
       
 (DIR) Post #AM0VcE9QcvENn9qAsq by inari@udongein.xyz
       2022-07-30T05:21:49.435698Z
       
       1 likes, 0 repeats
       
       @NaiJi @GagyyaRinqq да читал я вроде все что только можно и нужно прочитать на эту тему, я старый и с большой лычкой, но все равно спасибо. Цепляй линку в тред кому-то в любом случае пригодится же.
       
 (DIR) Post #AM0VhdnOhxFmm87KC0 by NaiJi@udongein.xyz
       2022-07-30T05:24:12.042237Z
       
       0 likes, 0 repeats
       
       @inari @GagyyaRinqq хдыщ 💥
       
 (DIR) Post #AM0XWvRGyF5sDXmpsm by alexey_stalker@mastodon.ml
       2022-07-30T05:33:40Z
       
       1 likes, 0 repeats
       
       @inari @rf @GagyyaRinqq SRP формулируется несколько по другому, а именно: "У сущности должна быть только одна причина для изменения". Всё размышления об авторах, доменной ответственности и т.п. вытекают из этого.
       
 (DIR) Post #AM0ZD0QKvXbXnJyhpA by kurator88@mastodon.social
       2022-07-30T05:47:32Z
       
       1 likes, 0 repeats
       
       @GagyyaRinqq @rf Я могу сделать функцию boolean которая будет вызвана в if если там много сложных проверок.  Но таких любителей совсем не много, чего уж там.
       
 (DIR) Post #AM0ZD0yMt0pJUrtsrw by NaiJi@udongein.xyz
       2022-07-30T06:03:27.599688Z
       
       0 likes, 0 repeats
       
       @kurator88 @GagyyaRinqq @rf везде где можно инвертируем зависимость на всё конкретное вплоть до примитивов :komi_thumbup: а потом дружно выходим в окно
       
 (DIR) Post #AM0caG3DIA22mewR1c by inari@udongein.xyz
       2022-07-30T06:40:30.070521Z
       
       1 likes, 0 repeats
       
       @alexey_stalker масло масляное вода мокрая. Дословно это само по себе ничего не значит, а раскрывается в разных книжках и выступлениях.из wiki напримерRobert C. Martin, the originator of the term, expresses the principle as, "A class should have only one reason to change,"[1] although, because of confusion around the word "reason" he also stated "This principle is ___ABOUT PEOPLE____."[2] (читай один юнит обслуживает интерес одного бизнес-требования которые в свою очередь одно требование исходит от одного бизнес-заказчика/человека). В целом @NaiJi то как бы прав, кроме того что это же самое применимо и к роли функций, и различается от указанного в треде изначально принципа только мотивом разбиения. Проще говоря, это более частный случай того что в начальном треде про чисто синтаксическое и структурное разбиение функций на более простые - делай хорошо будет хорошо, не делай сложно, делай просто (привет зен оф пайтон). Мораль в том что изначально в треде упомянута идея масло масляное (делай хорошо, потому что плохо это плохо, много кода это плохо), а срп это уже что-то более конкретное и осмысленное, хотя без деталей трактовки тоже выглядит как масло масляное.In some of his talks, he also argues that the principle is, in particular, about roles or actors. For example, while they might be the same person, the role of an accountant is different from a database administrator. Hence, each module should be responsible for each role.Отдельно подчеркну что в CA эти же принципы обобщаются до применения на любых уровнях - речь не идет только о классе, о модуле (хоть module хоть unit), - к любой структурной единице это применимо, да и в реальной жизни тоже - вилкой можно построить дом, но зачем, у нормальных людей она только для манипуляций едой путем прокалывания.В итоге SOLID описывался с благими намерениями чтобы было просто и хорошо, а в результате все равно получилось сложно настолько что пришлось несколько книг писать и прояснять каждый раз, и до сих пор 9 из 10 на собесах внятно не могут даже отдаленно объяснить что оно и зачем.@rf @GagyyaRinqq
       
 (DIR) Post #AM0dX80ErEQ0uPcb8S by NaiJi@udongein.xyz
       2022-07-30T06:51:56.881297Z
       
       0 likes, 0 repeats
       
       @inari @alexey_stalker @GagyyaRinqq На самом деле тут уже согласен, да. Я бы мог попробовать ещё подушнить в рамках мысленного эксперимента, но зачем. Добавлю только, что важно ещё это не переоценивать. Порассуждать об этом в треде может быть и забавно, но возводить это в религию не стоит. В конце концов, даже сам Мартин там пишет, что процесс первичнее структуры