Использование разных шаблонов для похожих функций

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

Допустим, я использовал шаблон X для реализации функции A. После разработки и доработки функции я понимаю, что могу реализовать ту же функцию, используя шаблон Y, о котором я только что узнал. Но функция A работает хорошо, а рефакторинг с X на Y отнимает много времени и дает мало пользы.

Затем пришло время реализовать функцию B. Она похожа на A, но на этот раз я хочу воспользоваться этой возможностью, чтобы поиграть с шаблоном Y. Я рад конечному результату лучше, чем при выполнении функции A, но теперь мой код использует два различные модели, X и Y, для аналогичных функций.

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

Обратите внимание, что этот вопрос не о выборе правильного шаблона для данной проблемы ; Речь идет о двух шаблонах, сосуществующих в кодовой базе для решения аналогичных проблем, которые могут быть сокращены до одного при наличии достаточного времени для рефакторинга.

• Это запах кода?
• Каковы недостатки сохранения исходного кода, как это?
• Должен ли я придерживаться только одного шаблона? то есть рефакторинг А использовать Y или продолжать использовать X при написании B?
• Как, в источнике, я могу сообщить, что причина, по которой существует два разных шаблона для схожих функций, по сути, не является причиной?
• Я слишком беспокоюсь о том, что следующий разработчик думает о моем коде?

Если шаблоны X и Y решают одну и ту же проблему, и ни одна из них не является объективно лучшей, тогда вам следует выбрать одну и придерживаться ее. Если это вообще возможно, вы должны стремиться последовательно решать одну и ту же проблему.

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

Недостатки разных решений одной и той же проблемы в базе кода:

• это займет вдвое больше времени, чтобы понять код
• это займет вдвое больше времени для изменения кода, когда вы измените некоторые из поведения, которое включает в себя шаблон
• у вас будет в два раза больше ошибок
• нынешние и будущие коллеги будут тебя ненавидеть

Я согласен с JacquesB в ответ . Я бы добавил, отвечая на другие ваши вопросы, что если сейчас у вас есть две модели, сосуществующие, и у вас нет времени (пока) реорганизовать ваше приложение, чтобы использовать тот, который вы считаете лучшим, вы должны поставить что в ваших комментариях в «оскорбительном» классе (который будет подвергнут рефакторингу). Таким образом, будущему разработчику (вам или кому-то еще) станет очевидно, что еще есть долг, который нужно заплатить.

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

Не играйте в кодовой базе. Создание прототипов позволяет вам найти преимущества и недостатки одного шаблона / дизайна по сравнению с другими.

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

Ожидайте, чтобы пролить много кода, разработанного для прототипа.

Является ли это запахом кода на самом деле, зависит от того, насколько похожи проблема A и проблема B. Ответ JacquesB, кажется, предполагает, что они очень похожи, и что если вы измените проблему A (например, чтобы исправить ошибку), вам также придется изменить проблему B одновременно. JaqueB может быть прав, но это также может быть случай, когда A и B изменяются независимо, потому что они не так уж похожи. В этой ситуации вам вряд ли будут описаны недостатки.

На основании вашего описания это звучит как запах кода (дублирование), но трудно сказать, насколько вонючий запах. Например, если A использует шаблонный метод, а B использует Strategy, две проблемы могут сильно отличаться, несмотря на используемые шаблоны зеркального отображения. Я бы подождал и увидел подход. Если возникает проблема C, и она похожа на A и B, то я бы реорганизовал A, чтобы соответствовать B, и тогда создание C должно быть очень простым. Если в A есть ошибка, я бы также хотел изменить ее на соответствие B, а затем исправить ошибку. Если ничего не изменится тогда ... это не имеет значения, не так ли?

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

Нет, вы можете использовать несколько шаблонов в одной базе кода.

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