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

Принцип DRY (dont repeat yourself) или "не повторяйся" был сформулирован Энди Хантом и Дэйвом Томасом в их книге The Pragmatic Programmer. Он помогает писать хороший код.
В этом видео о том, в чем заключается принцип DRY, где он используется, в каких случаях использование принципа "dont repeat yourself" вредно.

Другие курсы для новичков:

Продвинутые курсы для состоявшихся девелоперов:

0:00 вступление Сергея Немчинского
0:22 в чем заключается принцип DRY (don’t repeat yourself)
5:45 про использование генераторов кода, автоматических систем компиляции
7:25 единственный источник истины (single source of truth (SSOT)
7:58 рекламная пауза
8:55 применение принципа DRY
11:38 WET — «Write Everything Twice» или «We enjoy typing»
11:58 когда DRY не работает

[eugenem.]

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

[bjikqzz]

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

[olegkovalenko]

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

[lionlinux]

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

[sergejskozlovics]

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

[cwhfnzf]

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

[cyrilanisimov]

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

[Sergey]

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

[pvhnexsys]

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

[Daniilnew]

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

[jcnephf]

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

[telzeth]

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

[Vlad-embx]

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

[maksp.]

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

[JohnGrave]

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

[malchikovma]

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

[leonl]

Немного удивила позиция Сергея насчет автогенерации кода. Впрочем, я думаю, его мнение справедливо в первую очередь для бэкенда.

А вот на Андроиде как минимум тот же Dagger (DI-фреймворк) формирует зависимости модулей именно статическим путем - генерацией кода. И да, он вполне читабельный. Раньше, как мне известно, для этих целей использовалась рефлексия, но это было чревато снижением производительности и отсутствием возможности отладки до запуска и компиляции, т.е. если для какого-то модуля недостает какого-то другого, то в случае с автогенерацией это можно выяснить при компиляции. Для меня это огромный плюс. Я и так хорошо поломал голову над DI, когда его осваивал, если бы ошибки всплывали только в рантайме - понадобилось бы больше времени на набивание шишек и выяснения того, как нужно сделать так, чтобы заработало.

А еще ORM (Room) формирует огромный сгенерированный говнокод для взаимодействия с SQLite, а разработчик лишь пишет Dao-интерфейс с SQL-командами в аннотации, а все остальное генерирует annotation processor.

Насколько я знаю, на бэкенде (в Spring вроде бы) используется именно рефлексия для DI. Но там и масштабы другие и производительности хватает для всяких рант-тайм штук.

[aerahtv]

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

[valde_mar]

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

[Sergiusnick]

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