В статье описываются возможные проблемы, которые могут возникнуть при модификации повторно используемых компонентов. Также приводятся рекомендации, как эти проблемы избежать. Перевод является вторым в серии (один антипаттерн — одна статья), ссылка на первый перевод находится в конце статьи.
Наименование: Dead End (тупик)
Другое наименование: Kevorkian Component (мертвый компонент)
Суть проблемы
Антипаттерн «тупик» получается в результате модификации повторно используемых компонентов, если компонент больше не поддерживается и не сопровождается его поставщиком. После внесения изменений в компонент, бремя его сопровождения перекладывается на разработчиков прикладной системы. Улучшения в повторно используемом компоненте не могут быть легко интегрированы а сделанные изменения могут стать причиной проблем при его поддержке.
В случае коммерческих компонентов антипаттерн также известен под именем «кастомизация коммерческого ПО» (Commercial off-the-shelf (COTS) Customization). Когда станут доступны новые релизы, то для их использования потребуется повторно внести специальные изменения, если они вообще будут возможны. Иногда по ряду причин становится просто невозможным обновить модифицированный компонент, например по причине стоимости выполнения повторных модификаций или по причине текучести кадров (кода из компании ушел сотрудник, который выполнял модификацию).
Решение интегратора о внесении изменений в повторно используемый компонент часто рассматривается в качестве обходного пути для устранения недостатков продукции поставщика. В краткосрочной перспективе это благотворно сказывается на развитии программного продукта.
Долгосрочная поддержка таких изменений становится нерациональной, когда начинают бороться с противоречиями между выпусками новых версий ПО и повторно используемых компонентов. Единственный способ внести изменения в компонент так, чтобы эти изменения оправдали себя полностью — это договориться с его разработчиком о том, чтобы ваши изменения вошли в следующую версию. Но это возможно только в том случае, если цели ваших изменений совпадают с взглядом разработчика на то, как должен развиваться его компонент.
Решение проблемы
Следует избегать кастомизацию коммерческих компонентов и модификацию повторно используемых компонентов. Минимизируйте риск попасть в «тупик» путем использования современных платформ и инфраструктуры а также с помощью внесения соответствующих обновлений в создаваемый программный продукт по мере выхода новых версий используемых компонентов (согласованно).
Когда внесение изменений неизбежно, необходимо использовать изолирующий слой (см. антипаттерн Vendor Lock-In из раздела «Антипаттерны архитектуры ПО»). Используйте изолирующий слой и другие техники для удаления зависимости разрабатываемого ПО от изменений используемых компонентов и от проприетарных интерфейсов.
Исключения
Антипаттерн «тупик» может быть приемлемым в тестовых проектах, вспомогательных для основной разработки, например в макетах, когда преимущества (гибкость или быстрота модификации) достигаются посредством внесения изменений в используемые компоненты.
Примечание от переводчика: зайти в «тупик» можно не только при использовании компонентов, но и при создании плагинов, расширяющих функционал используемой сторонней системы. Например, когда пишется плагин для системы постоянной интеграции и workflow разработки тесно завязывается на функционале этого плагина. Если при обновлении системы интеграции изменится её API, то придется вносить изменения и в плагин.
Другие антипаттерны
Антипаттерны проектирования
- Poltergeist
- Dead End
Автор: snasoft
