Принцип хорошего кода DRY (dont repeat yourself)

[@eugenem.2263]

Согласен, не стоит повторять самого себя. Согласен, не стоит повторять самого себя.

[@div3975]

Согласен с предыдущим оратором, поэтому просто сошлюсь на его слова.

[@Михаил-ъ4ч1о]

Интересно про монолит, очень! Запишите в формате типа Монолит VS Микросервисы Да и вообще, расскажите про оба подробно, а потом это сравнение или наоборот.

[@matvejyoutube4424]

+

[@LinderVortex]

Да госпаде) если ОЧЕНЬ интересно, то у Немчинского есть на этом канале несколько видео, в каждом одна и та же лекция прямо про это. Он в одном видео так и сказал: "мои зрители не знают, что я снимал раньше, поэтому имеет смысл повторять те же темы каждый год". И натурально повторяет) Прям можно прогресс видеть, что изменилось, а что излагает как прошлый раз.

[@AlexS-gn9tq]

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

[@sfoxer]

@Владислав Бахмацкий иди своей дорогой, сталкер)

[@ТатьянаФедорова-ц8щ]

Только на днях наткнулась в вакансии на требование "Понимание базовых принципов разработки SOLID, KISS, DRY;" и тут же решила пересмотреть существующие видосы на эту тему😄 Немчинскому респект за полезную и нужную информацию!!! 👍

[@alexandernifanin7366]

Предлагали целоваться насухую?

[@olegkovalenko2797]

"Принцип диареи" - звучит просто отпад)))))

[@lionlinux]

"нижний плечевой пояс" - супер!

[@Vlad-em1bx]

Очень интересное объяснение. Особенно интересно по примеры когда DRY не применим. О том где это не применимо еще ни от кого кроме уважаемого автора не слышал. Спасибо.

[@Daniilnew]

Интересно про монолит!) Вообще спасибо за то, что Вы есть.

[@pvhnexsys]

Класс! Какой порядок в голове после Ваших видео!

[@aerahtv0000]

Дякую, Сергiй! Якраз шукав iнфу про це, чудове пояснення!

[@alexandernifanin7366]

Ну как, чудодейственные пояснения помогли - код превратился в DRY?

[@sergejskozlovics9667]

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

[@Pchelinskii_Sergei]

Не заметил в видео информации и монолитных системах.

[@SpaSergo]

@@Pchelinskii_Sergei 11:05

[@yuriyuldashev9513]

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

[@JohnGrave]

Голосую за видео про преимущества монолитных систем!

[@leonl2794]

Немного удивила позиция Сергея насчет автогенерации кода. Впрочем, я думаю, его мнение справедливо в первую очередь для бэкенда. А вот на Андроиде как минимум тот же Dagger (DI-фреймворк) формирует зависимости модулей именно статическим путем - генерацией кода. И да, он вполне читабельный. Раньше, как мне известно, для этих целей использовалась рефлексия, но это было чревато снижением производительности и отсутствием возможности отладки до запуска и компиляции, т.е. если для какого-то модуля недостает какого-то другого, то в случае с автогенерацией это можно выяснить при компиляции. Для меня это огромный плюс. Я и так хорошо поломал голову над DI, когда его осваивал, если бы ошибки всплывали только в рантайме - понадобилось бы больше времени на набивание шишек и выяснения того, как нужно сделать так, чтобы заработало. А еще ORM (Room) формирует огромный сгенерированный говнокод для взаимодействия с SQLite, а разработчик лишь пишет Dao-интерфейс с SQL-командами в аннотации, а все остальное генерирует annotation processor. Насколько я знаю, на бэкенде (в Spring вроде бы) используется именно рефлексия для DI. Но там и масштабы другие и производительности хватает для всяких рант-тайм штук.

[@Sergiusnick]

Я бы выделили еще пару мест-исключений: 1. Написание юнит-тестов. Простой тест без наследований, импортов и вызовов функций легко читается, легко и быстро можно понять, что там сломалось 2. Сериализаторы. Их проще каждый раз создавать заново, чем наследовать, изменяя список полей. При большом дереве наследования легко запутаться

[@Sergey82428]

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

[@HannibalLecter-w3r]

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

[@t2elzeth]

обожаю ваши учебные видео. продолжайте!

[@maksp.5366]

Спасибо. Стараюсь вникать в "правильные" правила кодинга ))) И просто интересно

[@МаринаИванова-д4г7б]

Спасибо большое за видео!) Очень круто подаёте информацию!))

[@vova2966]

Спасибо за видео 🙂

[@yurim7756]

Что-то мне сегодня ютуб вас подкидывает ) Вам весьма повезло, если считаете, что программисты знают что надо этот DRY использовать. Для баз данных еще есть какое-то понимание, почему там нельзя дублировать данные. А вот, как только начинают класс писать, С ХОДУ, вот прямо как только подумал, что классу что-то надо, сразу скопировал данные в поля класса. Не из источника брать, а только дублировать )) Мало того, и код дублируют, причем настойчиво, думая что это хорошо, доказывая что это хорошо, и иногда думая, что это я старый и не шарю в мегакрутом подходе для сервисов и микросервисов )) Это вроде в сервисах не может быть общего кода. Т.е. настойчиво, в рамках одной системы, пишут компоненты, где вот тупо одно и то же несколько раз написано. А потому что сервис. А потому что в каком-то странном их воображении, так безопаснее, мол они независимые, у них только интерфейс. Зато, когда приходит требование изменять, надо во всех модулях менять. На счет генерации кода, я пользую, сам пишу генераторы или трансляторы. Но это когда никак иначе. Например, для какой-то своей ORM, надо классы для мапа в базу данных. Вообще, отношусь где-то так. Генерация лучше чем ничего, т.е. чем дублировать работу руками. То что там говнокод генерится, не страшно, главное что без ошибок. На то она и генерация, не для людей. Но, при этом, чаще всего, надо смотреть в сторону, а нет ли баги в архитектуре, раз нужна генерация. Потому что в первую очередь надо приводить саму архитектуру к такому виду, чтобы не нужно было дублировать что-либо, а генерация говорит о том, что автоматизировали рутину. Но наверное, ее вообще не должен код требовать.

[@malchikovma]

Про генерацию кода. Android Studio жестко на него завязан. Половина современных библиотек зависит от кода, генерируемого плагинами Gradle.

[@gustaugutter9477]

фон - огонь

[@kovtunshu]

Чашка на столе тоже

[@vasiliyfofanov2605]

Про генерацию кода - можно поспорить, а лучше послушать мнение от Сергея по поводу DSL(Domain Specific Language). Иногда проще разработать небольшой язык и описать систему на нем, а далее сгененрировать код на общем языке(Java, C# и тд) У JetBrains прям целая платформа есть MPS для этого Обычно DSL понятен не только программисту, но и аналитику, тестеру, клиенту. В идеале сами требования транслируются прямо в код на общем языке Ждем видео по DSL

[@romantsyupryk3009]

Большое вам спасибо за это видео.

[@valde_mar]

Сергей, ещё интересно было бы про Code Smell посмотреть. Википедия википедией, но ваши объяснения с примерами из жизни/опыта прекрасны.

[@azamatk4302]

Мне приходилось дублировать код в Angular. В нескольких компонентках код был схож на ~70%. Да, можно было схожий код запихнуть в отдельную компонетку и ее использовать во всех тех компонентках. Все это хорошо, но я понимал, что при первой же доработке любой их этих компоненток придется все переделывать. Там было логично оставить дублирующий код.

[@ovinnickoffandrej]

Убедили! Никогда не буду повторять себя в коде, чтобы потом там не искать свои копипасты. Спасибо!!!

[@gaitavr1992]

Что думаете по поводу дубликации кода в DTO модели и более тяжелой ее версии для юая?

[@grafougen4563]

11:15 Сергей: "Монолит - хорошая полезная штука" Где-то в далеке послышались злые звуки Соера

[@AlexSmile-y2x]

где-то в высоте..

[@mikhaillucky8130]

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

[@cyrilanisimov]

Вот мы тут DRY обсуждаем, а в винде 10 две панели управления - вот вам и драй)

[@alex_chugaev]

В точку. Сильно бесит

[@ДорофеевСергей-г8р]

Это несколько вьюшек для одного объекта настройки. Значения настроек-то в обоих панелях не отличаются = принцип не нарушен.

[@meduzka]

@@ДорофеевСергей-г8р паттерн посредник

[@andreikashin]

no

[@cyrilanisimov]

Дорофеев Сергей да-да, особенно список установленных программ один, да

[@iliys1994]

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

[@vadim0morozov]

Здравствуйте, Сергей. А что по поводу автогенерации кода в Entity Framework - Database First?

[@sergem2794]

Отличное видео.

[@nooftube2541]

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

[@ИринаСвечникова-ф1д]

Спасибо, очень понятно

[@helpletmego4216]

сергей: DRY субтитры: ✨ Dior ✨

[@SergeyNemchinskiy]

ахаха

[@khusamalfas2121]

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

[@Dmitrii-Zhinzhilov]

Сергей, благодарю!

[@torrvic1156]

Прекрасный принцип и другое название SSO (single source of truth) ему очень подходит. Недавно столкнулся, когда в двух местах в программе у меня генерился GUID и я не понимал, а почему на определённом этапе у меня в базе в Redis данные начали задваиваться и вот после долгого дебага я выяснил, что генерация нового ГУИДА происходила в двух местах. Очень важный принцип, с которым столкнулся при довольно сложных обстоятельствах.

[@fritt_wastaken]

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

[@andrewzaitsev6668]

Еще пример возможно нарушающий DRY, это CQRS + ES и построение представлений в отдельной бд, то есть данные в итоге имеют разную структуру но по факту повторяются.

[@eugene3685]

В одном из проектов был бизнес леер. На основе его паблик метов, генерировался прокси, который вклчючал в себя логирование, откат трансакций, выполнение на другом потоке и многое другое. Перегенерирование случалось когда изменялись сигнатуры публичных методов. Вот для чего это нужно. И работало все как часы. Вот вам еще пример автогенерации, который мне кажеться очень крут. При добавлении обектов, генерируются их билдеры, спомощью которых, можно легко создать нужный объект и написать тест.

[@frontistes]

Про генерацию 👍👍👍👍👍 Наболело

[@alexdec2109]

Можно пожалуйста в таком же формате про Закон Деметры.

[@ЕкатеринаЗданевич-ы2х]

Очень нравятся видео этого автора, но вот не соглашусь с тем, что если код повторяется, то его нужно обязательно натянуть на DRY. Очень частый случай, в моей практике, когда начинаешь писать код (проект или компонент еще молодой и не оброс деталями). Коды очень похожи, повторяются некоторые шаги, но есть и различия. Прежде чем начинать делить, дробить чтобы соблюсти DRY нужно проаналазировать причины для изменения (как раз SRP) если код будет меняться с разной скоростью, если он будет меняться по разным причинам и в будущем еще и планируется, что его будут поддерживать разные команды со своими ТЗ, то беспрекословное следование принципу DRY очень усложняет развитие. В какой то книге я даже читала что этот случай называется: случайное дублирование. И ни раз я сталкивалась с ситуацией когда на начальном этапе коды очень схожи, их выносят в переиспользуемый блок, а потом начинается прирастание всякими if else. И проблемами со слиянием.И еще неприятнее: если нарушается вариантность при поддержке разными командами. Может, конечно я лишь подтвердила мысль обозначенную в последнем разделе видео. Если так, то извиняюсь

[@SergeyNemchinskiy]

полиморфизм. паттерны и т.д. - вас спасут

[@АлександрАфонин-я8щ]

Писал бакалаврскую по микросервисам, было бы интересно посмотреть как в монолите можно решить те проблемы, которые привели к микросервисам

[@DimaVort]

Стало интересно: а распределенные базы данных - это нарушение принципа dry? Ведь одни и те же данные лежат в разных местах, плюс еще изза ошибок обмена или репликации могут не сходиться.

[@mrfreelancerpaul6679]

Супер, фисташковые обои!

[@МихаилБратухин]

Дублирование в легаси может появиться не с пустого места и решать какие-то проблемы. В частности при переходе/миграции между разными платформами часто делают поэтапный переход с поддержкой двух параллельно развивающихся систем. Авто-генерация тоже не грех. Особенно, если генерация API идёт через JSON-схему. Это позволяет отвязать API от реализации на конкретном языке и платформе. Ещё дублирование может быть вызвано оптимизациями запросов в БД, либо потребностью хранить в истории операций дополнительную информацию, не относящимися к самой операции (например, баланс счёта до и после операции, а не только сумму списания/зачисления), тоже самое и про дублирующиеся проверки на фронте и бэке.

[@iluhakhurtin]

Михаил Братухин примерно то же самое хотел написать. Как правило все эти дубляжи не просто так берутся.

[@Oleksii_Leshchenko]

Про монолиты тоже прослушал бы

[@andrewzaitsev6668]

На клиенте и на сервере можно сделать единые валидационные правила. Fluent Validation в помощь, достаточно лишь вызывать метод validate(model);

[@ТатьянаКотикова-я3ю]

А если клиент и сервер пилят разные организации? Это довольно часто случается. У нас, к примеру, фронт пилят партнеры (у каждого свои команды и инструменты). А мы пилим серверную часть. Валидацию пишем так, будто клиент на своей стороне ничего не проверяет. Но надеемся, что какие-то данные они все же проверяют, прежде чем отправить запрос нам =)

[@SpaSergo]

Хочу видео Монолит vs Микросервисы.

[@badbear6179]

Студия шикарная

[@kirill2974]

Запишите, пожалуйста, почему обычно монолит лучше микросервисов.

[@Kadabra1981]

Сергей, а как быть если генерирование кода используется для проектов на нескольких языках? Скажем есть firmware на CPP и GUI на JAVA- и там и там одинаковые сущности с одинаковым поведением, генерация позволяет синхронизировать изменения в описании сущности сразу в 2 языках.

[@vadmall85]

Про монолит интересно!

[@haterealm]

Здравствуйте, я Сергей Немчинский и я расскажу вам как не повторять каждый раз "Здравствуйте, я Сергей Немчинский" :-)

[@crackinglad7644]

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

[@vv_a13nchik_vv24]

Давай делай про монолит, ждем

[@vitalyromas6752]

Багато корисного. Дякую.

[@makskaraban6142]

Расскажите про монолит!!!

[@aleksandrsavvopulo4510]

Считаю что DRY не применим к случаю дублирования кода/данных если это нарушает SRP.

[@Fiard2]

Автогенерация частенько нужна в сетевых протоколах между разными языками, и должна производится на этапе сборки проекта, а кодеген не должен отдаваться под СКВ, это просто промежуточный артефакт сборки (ну, если мы рассматриваем систему нормальных людей). Иногда кодеген нужен и для всякого сетевого транспорта низкого уровня в рамках одного языка, когда нужны сложные взаимодействия и нужно быстродействие, поэтому никакого доступа к рефлекшну и подобных вещей допускать нельзя, а хочется всякие данные прямо таки упаковывать поБИТно в поток, при этом описывая свои данные по-человечески, удобными декораторами и т.п. Естественно, сгенеренный код НЕ меняется вручную НИКОГДА. Если нужно расширить его функционал, нужно расширять саму кодо-генерацию. Однако кейсы, когда это действительно нужно - есть.

[@valeriisloboda6150]

Щодо генерації коду, я б не був таким категоричним. Ми на проєктах використовуємо typescript generator, який генерує з java DTO їх аналоги в typescript. Нічого поганого в тому нема, хоч і наш фронт-енд ПОВНІСТЮ залежить від згенерованих класів. Ніяких проблем з тим нема, навіть більше того, то нас береже від помилок з літерувками. Другий приклад. Ми мали проєкт, де була купа табличок, в яких була купа фільтрів. Але була вимога до нашого API, що практично кожен метод який повертав дані для таблички, мав піти продубльований, щоб він ще й повертав ті самі дані в CVS файлі. Ми написали модуль, який генерував контроллери, в яких були ті самі методи, але з суфіксом '.../csv'. Код там був так собі, але зате ми скоротили кодову базу на 30%.

[@typahastler8547]

Хочу видео про монолит

[@MrStealthWarrior]

Следуя принципу DRY нужно не уходить совсем в фанатизм. Переиспользоваться должна логика, а не просто код. Если код похож, но является частью выполнения различных задач - это не кандидат на попытку куда-то его вынести.

[@УнанСтепанян]

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

[@borisnedovis3296]

Познавательное видео. Не задумывались снять видео об построение инфрастуктуры проекта в целом ? Спасибо!

[@stepanstulov9871]

Real time играм, которые интерполируют на клиенте пока сервер не ответил, не обязательно нарушать принцип dry. Принцип dry про непереписывание кода дважды. Но один и тот же код два раза в двух местах исполнять вполне нормальо ничего не нарушая. Просто его нужно вынести в переиспользунмый модуль. Некоторые высокоуровневые сетевые фреймворки в некоторых игровых движках типа Unet в Unity вообще позволяют не думать сервер ты или клиент, ты просто пишешь что происходит в общем, а дальше все само разделяется (ок, это слегка упрощение конечно). Если бэк и фронт на совсем разных технологиях, то тут дублирование логики нужно или действительно переписывать или брать/изобретать некие декларативки с генераторами кода. Типа как какой нибудь ProtoBuf. Если они есть конечно.

[@sorrynomorenickname]

Можно для той же проверки использовать одни и те же регексы.

[@Merk462]

Постоянно вижу дублирование кода, в некоторых CMS большие куски кода дублируются десятки раз. Это очень плохо, т.к. они с этим живут десятки лет. Да и у меня это иногда само собой получается. А бывают случаи, когда более правильно скопировать метод и переписать часть функционала, и при этом не выносить общий кусок в третий метод. При этом получится 2 метода с частично дублированнм кодом. Но дублированние данных - это скорее нонсенс.

[@borisoffdenis]

В этой самой книге, которую вы упоминаете (The Pragmatic Programmer), есть глава о том, что надо использовать автогенерацию кода). Вроде в разделе The Basic Tools. Книга в целом хорошая, но местами устарела. А ваш видос - это лайк!

[@NikolayForostiy]

я за монолит!

[@smarthedgehog3185]

Крассава :) Осталось ещё YAGNI

[@ShadeAlina]

"Автогерерация ... срань господня" - плюсую =)

[@EnterAName-l3y]

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

[@rezyadlf]

Вы про DRY в ДБ говорите. Про денормализацию слышали? Дублирование данных допустимо, если есть причины. Более того, нарушение Драй допустимо и в коде. Эти принципы не высечены в фундаменте разработки. Есть случаи когда дублировать код вполне допустимо. Так как переиспользуемый функционал может расширяться и спустя время вырастать в монстра. Updated...

[@jewgenijmoldawski3306]

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

[@rezyadlf]

@@jewgenijmoldawski3306 так и я об этом. Но ведь в видео говорят, что нельзя дублировать данные по таблицам. Можно забыть об апдейте и тп...

[@MrMitror]

Andrew Reznik, мне, как новичку, это видео полезно. Лучше ведь начать обучение с тем подходом, который пригодится в 80% случаях. Сергей говорит о том, что есть исключения.

[@MrMitror]

Andrew Reznik, уверен в том, что он знает про денормализацию. Но зачем это подавляющему большинству новичков?

[@idea_man]

Лайк за "нижний плечевой пояс". Орнул.

[@EugenKondratiev]

если база хранится в одной базе "долгого хранения", а для быстрого поиска в виде дерева в другой БД, реалтайм. нарушение? если сделано осознанно из-за ограничения по времени выполнения запроса. запись в обе БД из одного скрипта.

[@alexanderlex-s933]

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

[@sorrynomorenickname]

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

[@ВиталийЮрьевич-х2л]

Услышал ваше мнение о кодогенерации, однако, небезизвестный Алан Кей сотоварищи продвигает STEPS, система с иерархической кодогенерацией. Каково ваше мнение об этой системе?

[@UserArtem]

Здравствуйте. Есть у меня такой вопрос. Нарушает ли (или имеет ли отношение к) принципы DRY такой кусок кода. this.variableA.variableAA = someValue this.variableA.variableAB = someValue2 this.variableA.variableAC = someValue3 this.variableA.variableAD = someValue4 Вопрос в том должна ли бить вынесена this.variableA в отдельную переменную во избежание дубликаций val myVariable = this.variableA myVariable..variableAA = someValue ...

[@alexsokol1086]

srp не задевает dry никак. srp это когда fun doStuff() { // generating stuff ... ... // processing stuff ... ... } никаких дупликаций нет, но один метод выполняет несколько шагов (и хорошо, когда они никак не пересекаются, а то они могут смешаться, могут одни переменные из прошлого шага уходить в следующий, и столько всего ещё может быть). хороший вариант будет таким fun doStuff() { val stuff = generateStuff() processStuff(stuff) } такой код становится понятным и читаемым без комментариев (которые к слову зачастую тоже ошибки, комментарии стоит делать только у методов, но не у строчек кода, если функция pure, то комментарий к функции должен всё объяснять) часто srp всякие геймдевы нарушают, которые не особо заботятся о кодстиле и сначала генерят локацию, а потом расставляют на ней каких-нибудь человечков, в лучшем случае, добавляя комментарии

[@Satmek]

Расскажите про монолит

[@Сергей-н7ъ1д]

Монолит интересно, ждем видео.

[@andreikashin]

"на моем компе работает" (С)

[@romannikulin6145]

@@acd2377 студентов? неееет. Это любой, кто делает некую деятельность в коллективе, где в итоге должны объединить всю вашу работу ещё с кем-то

[@Wave_ch]

А ведь у меня в универе реально были такие случаи, но только с файлами Microsoft Office (к примеру, на моём компе документ отображается правильно, а на компах в универе нет)

[@M0ToR]

Сергей, у вас отличные видео, и подача, и материал - на высоте, более того - вы в теме преподавания, а значит вы знаете цену самосовершенствованию, к тому же у вас учатся люди. Ваши ошибки, даже мелкие - осядут в головах тех, кто вас слушает, даже такая мелочь, как произношение DRY. Вы выкладываете видео на платформе, на которой есть носители практически любого языка. Написав “don’t repeat yourself” в поиске, можно получить однозначный ответ - как правильно произносить термин, принесенный из другого языка, если термин не авторский - вряд ли есть место авторскому произношению.

[@aleksa3969]

привет. 0:48 "я люблю говорить ди-ар-ай" - а разве спеллинг не должен быть ди-ар-вай ? DRY, звучит уже не так круто, как DRI, правда?

[@АлександрКовалев-о7я]

Вы привели пример какого-то такого себе программиста и его проект с базой данных, - - - -> где информация дублируется, - - - - - - - -> но в коде надо вручную вписывать два раза. Может лучше просто написать подпрограмму, которая вставляет в два места? [face palm]

[@sakharuk]

Лайк за келих )

[@xm4dn355x]

Сергей, Вы забыли апостроф в названии видео в слове "don't"

[@Владимир-в1в5ш]

@sergey, если есть свичеры в андроид с другого языка, есть вариант найма в СПб, опыт на андроид не обезателен, надо только желание учить его)

[@albrehtdurer557]

Хотим про Монолит!!!

[@MrLobash]

Вопрос, а что про модульность? Тоесть если в моем проекте есть сущность "Новости", и есть ... "Статьи", они очень похожи архитектурно, но предметно разные. Если я выведу всё в переиспользование то изменение Новостей изменит Статьи, но если не переиспользовать то местами будет 1в1 одинаковый код.

[@sterlo-x8z]

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

[@ЕвгенийЛобанов-ф4ъ]

​@@sterlo-x8z я к тому веду, что абстрактно - это разные сущности, и если две (и более) сущности будут зависеть от реализации (так совпало что логика в них одинаковая) то мы нарушаем DIP, и если придет программист Петя и поправит "новость" думая что поступает правильно, цепляет ещё и "статьи" и ему от тестирования приходит ошибка с левого модуля. и т.о. модульность тоже нарушается (правим один модуль, не так работает другой)

[@Andrew-7324]

Давай про копролит, ой, про монолит

[@naivais]

@Sergey Nemchinskiy DRY - по-английски - ди-аа(эр)-вай (читайте по буквам), а лучше всё-таки "драй "

[@maxzeman8219]

В реляционных базах данных ж 1НФ 2НФ ... бойса-кодда итд, интересно много л ли программистов про это знает

[@jgkdmdevienjjgg8866]

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

[@Merk462]

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

[@homo-ergaster]

@@Merk462 одноразовые дешевые поделки вообще писать смысла нет. Берется какой-нибудь Salesforce или Bitrix или вообще Wordpress и тупо натягивается на клиентский дизайн-макет. Или даже тупо покупается готовый шаблон. Для этого даже прогер не нужен.

[@Merk462]

@@homo-ergaster Менеджер, угадал?

[@homo-ergaster]

@@Merk462 хреновый из тебя экстрасенс

[@vufer3d]

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

[@thelensky]

Данные прежде всего

[@dmitryponyatov2158]

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

[@dmitryponyatov2158]

Потом добавьте пару заказчиков с перламутновыми пуговицами, миграните на соседний фреймворк или найдите ошибку в дизайне... Именно про это и была фраза про автогенерацию - без выхода на метауровень, на уровень абстракции моделей и дизайна ПО, DRY нереализуем

[@sergeymatpoc]

про дублирование данных - да очень банально. Взял данные из одного источника - раздал их по API - вот тебе и дублирование =). Какой-то второй консьюмер оперся на копию данных, решил срастить их с третьими данными, и может оказаться что копия еще не в синке, и консьюмер не может срастить 1 с 2. По большому счету "пофиг", со временем все равно синканется, но как в той песне - "а что если нет?" =) Что если синк сломался по какой-то причине? =)