Я уверен, что где-то есть название для этого анти-паттерна; однако я не достаточно знаком с литературой по анти-шаблонам, чтобы знать это.
Рассмотрим следующий сценарий:
or0
является функцией-членом в классе Что бы там ни было, это сильно зависит от переменных членов класса. Программист А приходит и нуждается в функциональности, такой как, or0
но не вызов or0
, Программист А копирует и переименовывает весь класс. Я предполагаю, что она не звонит, or0
потому что, как я говорю, она сильно зависит от переменных-членов для ее функциональности. Или, может быть, она младший программист и не знает, как это вызвать из другого кода. Так что теперь у нас есть or0
и c0
(с для копирования). Я не могу полностью обвинить Программиста А в этом подходе - мы все попали в сжатые сроки и взломали код, чтобы выполнить работу.
Несколько программистов поддерживают, or0
так что теперь это версия orN
. c0
сейчас версия cN
. К сожалению, большинство программистов, которые поддерживали содержание класса, or0
казалось, совершенно не знают c0
- что является одним из самых сильных аргументов, которые я могу придумать для мудрости принципа СУХОЙ. И, возможно, также было независимое ведение кода в c
. В любом случае кажется, что or0
и c0
были поддержаны независимо друг от друга. И, радость и счастье, ошибка происходит в cN
том, что не происходит в orN
.
Итак, у меня есть несколько вопросов:
1.) Есть ли название для этого анти-паттерна? Я видел, как это происходит так часто, что мне трудно поверить, что это не названный анти-паттерн.
2.) Я вижу несколько альтернатив:
a.) Исправлена ошибка, orN
при которой принимался параметр, определяющий значения всех необходимых ему переменных-членов. Затем измените cN
вызов так, чтобы orN
все необходимые параметры были переданы.
б.) Попробуйте вручную перенести исправления из orN
в cN
. (Имейте в виду, я не хочу этого делать, но это реалистичная возможность.)
c.) Переписать, orN
чтобы - cN
снова, чёрт, но я перечислю это для полноты картины.
г.) Попытайтесь выяснить, где cN
сломан, а затем отремонтировать его независимо от orN
.
Альтернатива кажется лучшим исправлением в долгосрочной перспективе , но я сомневаюсь , что клиент позволит мне реализовать. Никогда не время и деньги, чтобы исправить все правильно, но всегда время и деньги, чтобы решить ту же проблему 40 или 50 раз, верно?
Кто-нибудь может предложить другие подходы, которые я, возможно, не рассмотрел?
источник
Ответы:
это просто называется дубликат кода - я не знаю более причудливых имен для этого. Долгосрочные последствия, как вы описали, и хуже.
Конечно, устранение дублирования является идеальным вариантом, если это возможно. Это может занять много времени (в недавнем случае в нашем унаследованном проекте у меня было несколько методов, дублированных на более чем 20 подклассов в иерархии классов, многие из которых эволюционно увеличили свои незначительные различия / расширения за эти годы. мне около 1,5 лет, благодаря написанию последовательных юнит-тестов и рефакторингу, чтобы избавиться от всех дубликатов. Упорство стоило того, хотя).
В таком случае вам все еще могут понадобиться один или несколько других вариантов в качестве временных исправлений, даже если вы решите начать движение к устранению дублирования. Однако, какой из них лучше, зависит от множества факторов, и без большего контекста мы просто догадываемся.
Множество небольших улучшений может иметь большое значение в долгосрочной перспективе. Вам не обязательно нужно явное одобрение клиента на это - небольшой рефакторинг каждый раз, когда вы касаетесь указанного класса, чтобы исправить ошибку или реализовать функцию, может пройти долгий путь со временем. Просто включите дополнительное время для рефакторинга в ваши оценки задач. Это как стандартное обслуживание для поддержания работоспособности программного обеспечения в долгосрочной перспективе.
источник
Существует ссылка на шаблон « WET» («Нам нравится печатать»), но я не знаю, является ли это стандартным именем.
источник
Если я вас правильно понимаю, в классе слишком много всего происходит. Это создает методы, которые не следуют принципу единой ответственности . Приводит к коду, который должен быть перемещен, куски взяты, в то время как другие не учтены. Это также может создать много участников.
Вам также следует ознакомиться с модификаторами доступности. Убедитесь, что те вещи, которые являются публичными, на самом деле должны быть публичными. Потребителю не нужно знать о каждом маленьком члене ... использовать инкапсуляцию.
Это требует рефакторинга. Также кажется, что код пишется без предварительного дизайна. Посмотрите на разработку через тестирование. Напишите код так, как он должен называться, а не вызывайте код, каким бы он ни был реализован. Посмотрите в TDD несколько советов о том, как выполнить задачу.
источник
Если вы копируете код, вы вводите технический долг двойного обслуживания или, более конкретно, дублирование кода .
Обычно это исправляется с помощью рефакторинга. Более конкретно, вы перенаправляете все вызовы на новую функцию (или новый метод в новом классе), которая имеет общий код. Самый простой способ начать - это удалить весь скопированный код и посмотреть, что ломается, в котором вы исправляете, перенаправляя вызовы к общему коду.
Заставить вашего клиента согласиться с рефакторингом кода может быть сложно, поскольку трудно убедить не технического специалиста исправить технический долг. Поэтому в следующий раз, когда вы дадите оценку времени, просто включите время, необходимое для рефакторинга, к вашим оценкам . В большинстве случаев клиенты предполагают, что вы выполняете очистку кода во время исправления.
источник
Звучит как код спагетти для меня. Лучшее решение - это рефакторинг / перезапись.
источник
Вы говорите, что не можете полностью обвинить А - но копирование класса таким способом на самом деле непростительно. Это серьезный сбой в процессе проверки кода. Это, пожалуй, самый массовый сбой, когда вообще нет проверки кода.
Если вы когда-нибудь думали, что вам нужно создать ужасный код, чтобы уложиться в сроки, то запросом абсолютного наивысшего приоритета для релиза после этого должно быть исправление ужасного кода СЕЙЧАС. Так что ваша проблема ушла.
СУХОЙ принцип - для ситуаций, которые не совсем совершенны и могут быть улучшены. Дублирование класса - это совершенно новый калибр. Сначала я бы назвал это «дублированный код», и со временем он изменится на худшую из всех «трата времени», «расходящийся дублированный код»: несколько копий одного и того же кода, которые почти, но не совсем идентичны, и никто не знает, Различия предназначены, совпадения или ошибки.
источник
Почти на десять лет опоздал на эту вечеринку, но название этого анти-паттерна называется Divergent Change , где несколько классов содержат копии одного и того же поведения, но с течением времени и технического обслуживания, а некоторые классы забываются, эти поведения расходятся.
В зависимости от того, что такое общее поведение и как его разделяют, его можно было бы назвать « Хирургия с дробовиком» , с той лишь разницей, что здесь одна логическая функция предоставляется многими классами, а не одним.
источник