Чи є виняткові випадки, коли ми можемо прийняти повторюваний код?

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

API агентства є найповнішим, оскільки він має всі функціональні можливості. Потім трохи менший Home API, а потім мобільний API.

Тут архітектори створили загальний рівень (міжканальні послуги EJB, якими користуються всі API). Але тоді API відрізняються.

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

В основному контролери роблять відображення BO на ChannelObject (мені здається, це не правильне місце для цього) та деякі додаткові утиліти та серіалізатори. Наразі все дублюється. Вони кажуть, що причиною дублювання є те, що вони хочуть, щоб API не залежали. "Якщо завтра ми хочемо іншої поведінки вдома, ніж агентство чи мобільний, ми не будемо боротися !!"

Чи є випадок, коли нам слід прийняти повторюваний код?

Дублювання може бути правильним, але не з цієї причини.

Говорячи, що "ми можемо хотіти, щоб ці три місця в кодовій базі поводилися по-різному, хоча зараз вони однакові" - це не є вагомою причиною для масштабного дублювання. Це поняття може застосовуватися до кожної системи, і його можна було б використовувати для виправдання будь-якого дублювання, що, очевидно, не є розумним.

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

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

У Санді Мец, відомого інженера-програмного забезпечення та автора екосистеми Ruby, є чудова публікація в блозі та розмова, де вона також розповідає про взаємозв'язок дублювання та абстракції. Вона приходить до наступного висновку

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

І я повністю з нею згоден. Дозвольте дати вам більше контексту для цієї цитати. Іноді знайти правильну абстракцію дуже складно. У таких випадках заманливо просто піти на будь-яку абстракцію, щоб зменшити дублювання. Але пізніше ви зможете дізнатися, що ваша абстракція стосується не всіх випадків. Однак дорого все змінити знову і піти іншим маршрутом (для куди кращого пояснення слідкуйте за її розмовою!).

Так, так, для мене є виняткові випадки, коли прийняття дублювання є правильним рішенням, особливо коли ви не впевнені в тому, що має бути, і вимоги, ймовірно, зміниться. З вашої посади я вважаю, що дублювання зараз багато, але ваші колеги припускають, що це може змінитися і не з'єднувати обидва додатки один з одним. На мою думку, це справедливий аргумент, і його взагалі не можна нехтувати.

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

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

Сказав, що у більших організаціях іноді вигідно віддати перевагу незалежності різних команд за принципом DRY. Якщо видалення дублювання шляхом вилучення 95% загальних частин API двох нових компонентів призводить до з'єднання двох інакше незалежних команд, це може бути не наймудрішим рішенням. З іншого боку, якщо у вас обмежені ресурси і буде лише одна команда, яка підтримує обидва API, я впевнений, що це буде в їхніх власних інтересах не створювати подвійних зусиль і уникати зайвого дублювання коду.

Далі зауважте, що це має значення, якщо API "Домашній" та "Агентство" використовуються виключно повністю різними програмами або якщо ви можете спробувати написати складову компонента поверх тих API, які також можуть бути використані в контексті "Головна" як у контексті "Агенції". У цій ситуації наявність загальних частин API точно однакових (що ви можете гарантувати, лише якщо загальні частини не дублюються), зробить розробку такого компонента набагато простішим.

Отже, якщо виявиться, що дійсно будуть різні підгрупи, кожна з яких відповідає за кожен API, кожна з іншим графіком та ресурсами, тоді настав час дублювати код, але не «про всяк випадок».

Дублювання для запобігання зчеплення . Скажімо, у вас дві великі системи, і ви змушуєте їх використовувати одну і ту ж бібліотеку. Можливо, ви з'єднуєте цикл випуску обох систем. Це може бути не надто погано, але скажімо, що в одній системі потрібно внести зміни. Інші повинні проаналізувати зміни і на них можуть вплинути. Іноді це може зламати речі. Навіть якщо обидві сторони вміють координувати зміни, це може бути безліч зустрічей, проходження керівників, тестування, залежностей і закінчення невеликої автономної команди.

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