Осторожно выбирайте внешние модули

(В оригинале - Choose Your Tools with Care)

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

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

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

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

  • Разработка и сопровождение ПО – достаточно ресурсозатратное дело, поэтому может быть дешевле купить готовое решение.

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

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

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

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

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

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

Моя собственная стратегия избегания этих проблем – начинать с наименьшим возможным количеством используемых инструментов. Обычно вначале фокус на инструментах, реализующих низкоуровневое программирование, например, какой-нибудь прослойки над обычными сокетами операционной системы. А потом – добавлять по мере необходимости. Кроме этого, я стараюсь изолировать внешнее ПО от своей реализации, применяя для этого интерфейсы и слои. В результате я могу легко заменить внешний инструмент при необходимости. Положительный эффект такого подхода – завершенный продукт оказывается меньшим и с меньшим количеством используемых составляющих, чем ожидалось при проектировании.

Автор оригинала - Giovanni Asproni

results matching ""

    No results matching ""