Тщательно выбирайте инструменты Джованни Аспрони

Современные приложения крайне редко создают «с чистого листа». Их собирают из уже существующих кубиков — компонентов, библиотек и фреймворков, и тому есть ряд веских причин:

• Объемы, сложность и изощренность приложений растут, а времени на их создание отводится все меньше. Выгоднее тратить время и интеллект разработчиков на код бизнес-логики, чем на код инфраструктуры приложения.

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

• Высококачественный инструментарий доступен бесплатно в сети Интернет, благодаря чему снижаются затраты на разработку и упрощается поиск заинтересованных разработчиков с нужным опытом.

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

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

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

• У каждого инструмента собственный график выхода новых версий, и обновление какого-либо из них может стать чрезвычайно сложной и затратной по времени задачей, поскольку новая функциональность, архитектурные изменения и даже исправления, связанные с ошибками, иногда приводят к несовместимости с другими инструментами. Чем больше в проекте инструментов, тем острее может становиться эта проблема.

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

• Может возникнуть жесткая привязка к определенному производителю (vendor lock-in), когда код, интенсивно использующий его продукты, вдруг оказывается ограничен такими параметрами, как простота сопровождения, производительность, возможность развития, цена и другими.

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

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

Моя личная стратегия смягчения этих проблем состоит в том, чтобы начинать с малого — лишь с тех инструментов, которые абсолютно необходимы. Как правило, на старте самое главное — устранить необходимость программирования инфраструктуры низкого уровня (и сопутствующих проблем). Скажем, в случае работы над распределенным приложением это достигается посредством использования связующего программного обеспечения (middleware) вместо работы с сокетами напрямую. Затем при необходимости можно добавить другие инструменты. Кроме того, я стараюсь отделить внешние инструменты от объектов моей предметной области с помощью интерфейсов и слоев. Это позволяет с минимальными потерями заменить какой-либо инструмент, если понадобится. Положительный побочный эффект такого подхода — как правило, на выходе я получаю приложение меньшего размера и с меньшим количеством внешних инструментов, чем изначально предполагалось.

Загрузка...