Программист-прагматик. Путь от подмастерья к мастеру

ОглавлениеДобавить в закладки К обложке

9Обратимость

Нет ничего опаснее идеи, если это единственное, что у вас есть.

Эмиль-Огюст Шартье, Разговор о религии, 1938

Технические специалисты предпочитают простые и однозначные решения задач. Математические тесты, позволяющие с большой уверенностью сказать, что х = 2, намного лучше, чем нечеткие, но страстные очерки о миллионах причин Французской революции. К техническим специалистам присоединяются и менеджеры: однозначные и несложные ответы хорошо вписываются в электронные таблицы и проектные планы.

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

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

"Но вы же сказали, чтобы мы использовали базу данных XYZI. Мы написали 85 % текста проекта – мы не можем изменить его в данный момент", – протестует программист. "Очень жаль, но наша фирма решила вместо нее взять за основу базу PDQ – для всех проектов. Это немое решение. Мы все должны переписывать тексты программ… Всем вам придется работать и по выходным – до особого распоряжения".

Конечно, принимаемые меры не должны быть столь драконовскими, сколь и неотложными. Но поскольку время идет, а ваш проект продвигается, вы можете оказаться в шатком положении. С принятием каждого важного решения проектная команда ставит перед собой все более узкую цель – ограниченную версию действительности, в которой имеется меньшее число вариантов.

К тому времени, когда многие важные решения уже приняты, цель уменьшится настолько, что, если она двинется с места или ветер изменит направление, или же бабочка в Токио взмахнет своими крылышками, вы промахнетесь [9]. И здорово промахнетесь.

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

Как только вы решите использовать базу данных этой фирмы или архитектурный шаблон, или определенную модель развертывания (например, «клиент-сервер» вместо автономной модели), то вы становитесь на путь, с которого невозможно свернуть – лишь ценой огромных затрат.

Обратимость

Многие из тем, затронутых в данной книге, нацелены на создание гибкого, легко адаптируемого программного обеспечения. Следуя их рекомендациям – в особенности принципу DRY, принципу несвязанности и использованию метаданных (см. ниже), нет нужды в принятии многих важных необратимых решений. Это и хорошо, поскольку вначале мы не всегда принимаем наилучшие решения. Мы придерживаемся некоторой технологии лишь для того, чтобы в один прекрасный день обнаружить, что не в состоянии нанять достаточное количество людей, обладающих необходимыми навыками. Стоит нам остановить свой выбор на некоторой фирме-субподрядчике, как ее сразу перекупают конкуренты. Требования, пользователи и аппаратные средства изменяются быстрее, чем мы разрабатываем программное обеспечение.

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

Предположим, что проект начинается по модели «клиент-сервер», но затем, когда карты уже сданы, отдел маркетинга решает, что для некоторых заказчиков серверы слишком дороги и они хотят сделать автономную версию. Насколько сложным будет для вас этот переход? Поскольку речь идет о развертывании, для этого потребуется минимум несколько дней. Если бы времени требовалось больше, вы бы и не думали об обратимости. Обратная задача еще интереснее. Что будет, если возникнет необходимость в развертывании автономной версии разрабатываемого вами проекта по схеме «клиент-сервер» или по n-звенной модели? Это также не должно представлять затруднений.


-= 50 =-
Регистрация.
Забыли пароль?
Логин
Пароль
Запомнить меня