Отличная есть статья на хабре. Сделаю небольшую выжимку для памятки.
Когда вы разрабатываете крупный проект, часто приходится сталкиваться с избыточной общей сложностью реализации. Люди плохо справляются с управлением сложных систем, им лучше удается находить необычные решения определенных задач. Самое простое решение по уменьшению сложности – разделить систему на мелкие, независимые модули, которыми проще управлять.
Самый простой подход по уменьшению сложности — разделить систему на управляемые части
Разделяя систему на компоненты глубже и глубже, вы достигнете момента, когда каждая часть системы будет отвечать за четко определенные действия. Такие действия можно организовать в классы.
Принцип DRY требует, чтобы такие части информации встречались в вашем коде один, и только один раз.
Эти части должны иметь одно представление. Обратите внимание на различие между информацией (данными), и ее представлением. Информация, это "что". Представление, это "какие".
Каждая часть данных должна иметь четкое, надежное представление в системе.
В идеальной системе каждая часть бизнес логики инкапсулирует свои данные в представление – переменную или свойство класса. Эта переменная инкапсулирована в класс, отвечающий за часть архитектуры. Класс является частью компонента, который является реализацией части функционала системы. И дальше вверх по цепочке.
DRY — это философия, разбивающая логику на представления.
DRY, и модульная архитектура требуют хорошего планирования. Для правильной организации иерархии представлений разделите вашу систему на небольшие части, которые смогут работать вместе. Если вам предстоит управление большим проектом, стоит рассмотреть идею его организации компонентами, с применением DRY.
Если вдруг вы ловите себя на том, что этот код вы уже писали/встречали раньше, остановитесь, подумайте, и не повторяйте себя.
В реальных проектах достичь 100% DRY практически нереально. Но, в свою очередь, проектов, которые не-DRY на неприемлемом уровне, и которыми сложно управлять, довольно много. И, возможно это для вас будет сюрпризом – 50% всех наших проектов провальны, если взглянуть на их код.
Редко плохой код пишут плохие программисты.
Многие склонны думать, что плохой код пишут плохие программисты. Это не так. Чуть чаще чем всегда это неправильно поставленное управление процессами в компаниях. Повторяемость ликвидируется хорошим планированием. Срочные изменения в системе влекут срочные, неоптимальные решения в коде. Как только код подвергается плохим решениям, весь принцип DRY для данного решения перестает работать, до будущих изменений.
DRY достигается совместным планированием.
Если к планированию относится прохладно, пишется плохой, очень плохой код. Код перестает быть DRY. DRY является концептом, зависящим от многих людей.
_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.
Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.
Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.
