Есть ли исключительные случаи, когда мы можем принять дубликат кода?

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

API агентства является наиболее полным, поскольку он имеет все функциональные возможности ... затем немного меньше Home API, а затем мобильный API.

Здесь архитекторы создали общий уровень (многоканальные EJB-сервисы, используемые всеми API). Но тогда API-интерфейсы разные.

Между API нет большой разницы. Большая команда начинала с канала агентства, и сейчас мы адаптируем ее для домашнего канала. Мы просто обогащаем объекты специально для нашего домашнего приложения. В противном случае код на 95% похож между API. API построен на основе Spring MVC и имеет (контроллеры, модели и некоторые утилиты).

В основном контроллеры выполняют сопоставление BO с ChannelObject (мне кажется, это не подходящее место), а также некоторые дополнительные утилиты и сериализаторы. На данный момент все дублировано. Они говорят, что причина дублирования в том, что они хотят, чтобы API были независимыми. «Если завтра мы хотим другого поведения для дома, чем агентство или мобильный, мы не будем бороться !!»

Есть ли случай, когда мы должны принять дублирующий код?

Дублирование может быть правильным, но не по этой причине.

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

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

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

У Сэнди Метц, известного разработчика программного обеспечения и автора экосистемы Ruby, есть отличное сообщение в блоге и доклад, в котором она также рассказывает о связи между дублированием и абстракцией. Она приходит к следующему выводу

дублирование намного дешевле, чем неправильная абстракция

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

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

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

Дублирование кода сокращает усилия только на короткий срок, но почти сразу же увеличивает усилия по сопровождению, пропорционально количеству дублированных строк кода. Также обратите внимание, что после дублирования кода будет трудно удалить дублирование, если окажется, что это было неправильное решение, хотя, если один не дублирует код сейчас, все равно легко ввести дублирование позже, если окажется, что он придерживается DRY. было неправильное решение.

Сказал, что в более крупных организациях иногда выгодно отдавать предпочтение независимости разных команд по принципу СУХОЙ. Если удаление дублирования путем извлечения 95% общих частей API двух новых компонентов приводит к объединению двух независимых групп, это может быть не самым мудрым решением. С другой стороны, если у вас ограниченные ресурсы, и будет только одна команда, поддерживающая оба API, я уверен, что в их собственных интересах не предпринимать никаких двойных усилий и избегать ненужного дублирования кода.

Кроме того, обратите внимание, что имеет значение, если API «Home» и «Agency» используются исключительно разными приложениями, или если кто-то может попытаться написать компонентную сборку поверх этих API, которые также могут использоваться в контексте «Home» как в контексте «агентства». В этой ситуации, если общие части API точно идентичны (что вы можете гарантировать только в том случае, если общие части не дублируются), разработка такого компонента, вероятно, будет намного проще.

Так что, если окажется, что будут действительно разные подгруппы, каждая из которых будет отвечать за каждый из API, у каждого будет свое расписание и ресурсы, тогда пришло время дублировать код, но не «на всякий случай».

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

Таким образом, вы платите цену дублированного кода, чтобы получить автономию и независимость.