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

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

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

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

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

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

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

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

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

Пишите код на языке предметной области

Дэн Норт

Представьте себе текст двух программ. В одной вы встречаете такое:

if (portfolioIdsByTraderId.get(trader.getId())

   containsKey(portfolio.getId())) {…}

Вы чешете затылок, пытаясь осмыслить, что делает этот код. Похоже, он получает идентификатор объекта трейдера, и по этому идентификатору находится ассоциативный массив в, э-э-э… очевидно, ассоциативном массиве ассоциативных массивов; затем проверяется, есть ли в этом внутреннем массиве еще один идентификатор — из объекта портфеля. Вы снова чешете затылок. Ищете объявление переменной portfolioIdsByTraderId и обнаруживаете следующее:

Map<int, Map<int, int>> portfolioIdsByTraderId;

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

В тексте другой программы вы видите:

if (trader.canView(portfolio)) {…}

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

Внимание, вопрос. Над кодом какой из программ вы предпочли бы работать?

Давным-давно у нас были только самые элементарные структуры данных: биты, байты и символы (на самом деле, те же байты, но мы делали вид, что это буквы и специальные символы). С десятичными числами выходило посложнее, ведь счисление по основанию 10 плохо вписывается в двоичную систему, так что у нас было несколько размеров для чисел с плавающей запятой. Затем появились массивы и строки (по сути, разновидность массивов). Потом в нашем распоряжении оказались стеки и очереди, хеши, связные списки, списки с пропусками и масса других замечательных структур данных, которых нет в реальном мире. Термин «компьютерная наука» тогда означал в основном трудоемкое отображение реального мира на наши ограниченные структуры данных. Настоящие гуру могут даже вспомнить, как именно удавалось решать задачу.

Затем появились пользовательские типы! Ладно, это ни для кого не новость, но они несколько меняют правила игры. Если в вашей предметной области есть такие понятия, как «трейдер» и «портфель», вы можете моделировать их с помощью типов, назначив типам такие имена, как Trader и Portfolio. Но, что еще важнее, и отношения между типами можно моделировать через термины из той же предметной области.

Если вы не используете в коде термины предметной области, значит вы формируете подразумеваемое (читай: секретное) правило, что вот эта переменная типа int в этом месте обозначает трейдера, а вон то int в том месте обозначает портфель. (И лучше их не путать!) А если вы реализуете некоторое бизнес-правило («некоторым трейдерам нельзя просматривать некоторые портфели — это незаконно») с помощью нетривиального алгоритма в коде, — например поиска существования значения в ассоциативном массиве, — вы вряд ли облегчаете жизнь ребятам, которые будут проводить аудит и проверку на соответствие законодательству.

Следующему программисту, который будет работать с этим кодом, ваше тайное знание может быть недоступно, так почему не описать все явно? Применение одного ключа для поиска другого, используемого в проверке существования, не слишком очевидная штука. Можно ли рассчитывать, что кто-нибудь догадается, что таким образом реализуются бизнес-правила, препятствующие конфликту интересов?

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

Программист, который спустя несколько месяцев продолжит работу над вашим кодом, будет