Антипатерни проектування: Dead End

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

Найменування: Dead End (глухий кут)

Інше найменування: Kevorkian Component (мертвий компонент)

Суть проблеми

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

У разі комерційних компонентів антипатерн також відомий під ім'ям «кастомізація комерційного ПЗ» (Commercial off-the-shelf (COTS) Customization). Коли стануть доступні нові релізи, то для їх використання потрібно повторно внести спеціальні зміни, якщо вони взагалі будуть можливі. Іноді з низки причин стає просто неможливим оновити модифікований компонент, наприклад через вартість виконання повторних модифікацій або через плинність кадрів (коли з компанії пішов співробітник, який виконував модифікацію).

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

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

Вирішення проблеми

Слід уникати кастомізації комерційних компонентів та модифікації компонентів, що повторно використовуються. Мінімізуйте ризик потрапити в «глухий кут» шляхом використання сучасних платформ та інфраструктури а також за допомогою внесення відповідних оновлень у створюваний програмний продукт у міру виходу нових версій використовуваних компонентів (узгоджено).

Коли внесення змін неминуче, необхідно використовувати ізолюючий шар (див. антипатерн Vendor Lock-In з розділу «Антипатерни архітектури ПЗ»). Використовуйте ізольований шар та інші техніки для видалення залежності компонентів, що розробляються ПЗ, від змін, які використовуються, та від інтерфейсів.

Винятки

Антипатерн «глухий кут» може бути прийнятним у тестових проектах, допоміжних для основної розробки, наприклад у макетах, коли переваги (гнучкість або швидкість модифікації) досягаються за допомогою внесення змін до використовуваних компонентів.

Примітка від перекладача: зайти в «глухий кут» можна не тільки при використанні компонентів, але і при створенні плагінів, що розширюють функціонал використовуваної сторонньої системи. Наприклад, коли пишеться плагін для системи постійної інтеграції і workflow розробки тісно зав'язується на функціоналі цього плагіну. Якщо при оновленні системи інтеграції зміниться її API, то доведеться вносити зміни і в плагін.

Інші антипатерни

Антипатерни проектування

• Poltergeist
• Dead End