Я неправильно понял этот принцип
TL;DR;
«Каждая часть знания должна иметь единственное, недвусмысленное и авторитетное представление в системе»
Раньше я думал, что часть знания означает код, поэтому я всегда абстрагировал код, чтобы СУХОЙ его. И хотя я по-прежнему считаю, что мы должны это делать, когда это уместно, я также думаю, что эта фраза больше относится к бизнесу.
вступление
Если я обнаруживаю, что выполняю одну и ту же задачу снова и снова, я стараюсь хотя бы немного ее автоматизировать; Когда дело доходит до кода, эта автоматизация принимает форму так называемого принципа« не повторяй себя (СУХОЙ) » - девиза разработчиков, который я всегда относил к дублированию кода. Но я был неправ.
Дело против СУШКИ кодовой базы
Когда вы придерживаетесь принципов программирования, таких как SOLID, вы, естественно, сможете увидеть некоторые шаблоны кода, возникающие в ваших модулях (классы и / или методы, и их эквиваленты), и, таким образом, вам будет легче определить, какие из них тоже Подобно другим частям, до определенной степени вы можете абстрагироваться от некоторых из них и перемещать их в новый модуль.
Но я на собственном горьком опыте убедился, что предварительное копирование может принести больше вреда, чем пользы. Поэтому я стараюсь абстрагироваться только тогда, когда вижу один и тот же фрагмент кода в четвертый раз в проекте.
Когда вы делаете это слишком рано, проблема заключается в том, что у вас недостаточно информации, чтобы отличить, кто получает больше пользы от абстракции. Это бизнес или кодовая база?
Оба важны и поддерживают друг друга, но, как я объяснил, когда писал о том, что тесты должны быть ориентированы на продукт, бизнес важнее кода, если вы хотите иметь надежное программное обеспечение.
Легко обмануть себя, заставив думать, что код - самая важная часть программного обеспечения, когда мы живем в пределах кодовой базы. Нет.
В конце концов, важно то, насколько полезен код для вас (и для работодателей). Это могут быть деньги, знания, хороший клиент, более богатое портфолио и т. Д.
Итак, отложите решение о дублировании кода до тех пор, пока бизнес (косвенно) этого не потребует. Поначалу это заденет вашего разработчика, но окупится, когда вы поймете, что DRY хорош, но не связан с кодом.
Слишком раннее абстрагирование также может привести к чрезмерно сложной архитектуре, особенно когда вы заставляете себя сохранять ее в том виде, в котором она была изначально спроектирована.
Не говоря уже о том, что многие «предположения» оказываются неверными, поэтому вам нужно настроить код, чтобы сделать его достаточно универсальным для всех случаев, о которых вы заранее не задумывались.
Что такое DRY на самом деле
Принцип должен быть о знаниях, знании предметной области. Что разработчики выражают в виде кода, хотя код сам по себе не является знанием - они связаны, но не равны.
Один из способов собрать эти знания воедино - сохранить их на слое, доступном для других, чтобы вы не распространяли код, связанный с предметной областью, по своей кодовой базе.
В этом вам может помочь проектирование до кодирования, в противном случае вы будете писать код только для удовлетворения эго своего разработчика, даже если он бесполезен для бизнеса.
Обновления
* 2020 Октябрь 20: добавление ссылок на другие релевантные статьи и исправленные опечатки
