К тому времени, когда многие важные решения уже приняты, цель уменьшится настолько, что, если она двинется с места или ветер изменит направление, или же бабочка в Токио взмахнет своими крылышками, вы промахнетесь [9]. И здорово промахнетесь.
Проблема состоит в том, что непросто дать задний ход важным решениям.
Как только вы решите использовать базу данных этой фирмы или архитектурный шаблон, или определенную модель развертывания (например, «клиент-сервер» вместо автономной модели), то вы становитесь на путь, с которого невозможно свернуть – лишь ценой огромных затрат.
Обратимость
Многие из тем, затронутых в данной книге, нацелены на создание гибкого, легко адаптируемого программного обеспечения. Следуя их рекомендациям – в особенности принципу DRY, принципу несвязанности и использованию метаданных (см. ниже), нет нужды в принятии многих важных необратимых решений. Это и хорошо, поскольку вначале мы не всегда принимаем наилучшие решения. Мы придерживаемся некоторой технологии лишь для того, чтобы в один прекрасный день обнаружить, что не в состоянии нанять достаточное количество людей, обладающих необходимыми навыками. Стоит нам остановить свой выбор на некоторой фирме-субподрядчике, как ее сразу перекупают конкуренты. Требования, пользователи и аппаратные средства изменяются быстрее, чем мы разрабатываем программное обеспечение.
Предположим, что в начале проекта вы решили использовать реляционную базу данных, производимую фирмой А. Позже, во время нагрузочного тестирования, вы обнаруживаете, что база данных слишком медленная, а объектная база данных фирмы В работает быстрее. В большинстве случаев, вам не везет. Большую часть времени обращения к программам фирм-субподрядчиков запутываются в тексте программ. Но если вы действительно вычленили идею базы, поместив ее снаружи – в точку, где она просто обеспечивает сохранение состояния объектов (как служба), тогда вы обладаете достаточной гибкостью, чтобы менять коней на переправе.
Предположим, что проект начинается по модели «клиент-сервер», но затем, когда карты уже сданы, отдел маркетинга решает, что для некоторых заказчиков серверы слишком дороги и они хотят сделать автономную версию. Насколько сложным будет для вас этот переход? Поскольку речь идет о развертывании, для этого потребуется минимум несколько дней. Если бы времени требовалось больше, вы бы и не думали об обратимости. Обратная задача еще интереснее. Что будет, если возникнет необходимость в развертывании автономной версии разрабатываемого вами проекта по схеме «клиент-сервер» или по n-звенной модели? Это также не должно представлять затруднений.
