Девять вариантов: что делать с древними программами

Однако мне приходилось встречать организации, где есть только самое лучшее и совершенное, ситуативное и ориентированное на Web 2.0, поддерживающее социальные сети и имеющее глубокую семантическую основу, рассчитанное на работу в «облаке» и использующее системные скрипты программное обеспечение, приобретенное всего несколько недель назад. Но его уже называют «старым», поскольку перешли на следующее, еще более лучшее и самое-самое совершенное решение.

Заметьте, я не пытаюсь критиковать ничей подход. Организации, использующие действительно древнее программное обеспечение, как правило, делают это только по экономическим причинам — то, что у них имеется, их вполне устраивает. Те же, кто работает с недавно появившимися программами, как правило, прибегают к таким ритуальным пляскам по одной из двух причин. Возможно, их рынок требует экстремальных инноваций. Либо, поскольку они вовлечены в эту захватывающую круговерть требований рынка и технологии, вероятно, они еще не пришли к стабильной архитектуре, необходимой для развития их бизнеса. Поэтому им действительно приходится крутиться (если у них вообще есть другой выход).

Однако, я считаю, что организации, которые поддерживают созданное десятки лет назад программное обеспечение, часто занимаются надуманной экономией на фоне реальных затрат на работу старых программ. Точно так же я уверен, что новые организации зачастую недооценивают эффект «массы» и, как следствие, сопутствующую инерцию и затраты на, как им кажется, «не имеющие веса» строки кода. Организации с «винтажным» программным обеспечением часто прекрасно осведомлены об этих проблемах, поскольку годами ощущают их давящий груз, в то время как в более молодых компания нередко об этом не знают просто потому, что «масса» не является для них ограничивающим фактором. Деа Обоссаньо, руководитель программы корпорации Microsoft, высказался об этом так (web2journal.com/read/603827.htm): «В недавно созданной компании нет унаследованного кода. Когда ваша кодовая база существует недолго, нет ничего сложного в том, чтобы разработчики одобрили новые функции, за ночь проверив код, подкрепляясь кофе и пиццей. По большей части, кодовая база не должна быть столь массивной или внутренне зависимой, чтобы одно изменение породило какие-то проблемы. Однако в разработке программного обеспечения можно считать практически законом тот факт, что, чем старше становится ваш код, тем больше строк он содержит, и ваши модули связываются друг с другом все сильнее. Это значит, что изменение в одной части кода может неблагоприятно отразиться на другой».

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

Отказаться

Другими словами, просто выбросить старые программы. Если вы извлекли из фрагмента программного обеспечения всю мыслимую экономическую пользу, иногда самое лучшее, что вы можете сделать, — просто от него избавиться. Если речь идет о скриптах, которые действуют на границах Web-системы, или о коде, который связывает системы вместе, выбросить эту кодовую базу и начать создавать новую, безусловно, имеет смысл, поскольку затраты на изменения достаточно невелики. На самом деле, в определенной степени, такого рода деятельность — «выбросить и переделать» — предполагается в каждой предметной области, особенно там, где постоянно требуются инновации. Однако крайне неприятно, если вы никак не приходите к стабильности.

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

Подарить

Предложить полезное программное обеспечение сообществу Open Source — вполне разумный выбор. Разумный в том смысле, что это единственный для организации способ внести свой вклад в развитие отрасли и соответствующей предметной области. Я сделал это со своей библиотекой компонентов для языка Ада (и был удивлен, что кто-то ею еще пользуется). Мне не хотелось больше ими заниматься и достаточно было знать, что кому-то они еще могут оказаться полезны.

Оставить как есть

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

Поддерживать

Иногда ваше программное обеспечение вполне приемлемо, но платформа, на которой оно работает, никуда не годится. Я видел, как это происходило по всему миру с системами управления воздушным сообщением и системами управления маневрированием поездов: у организации есть программное обеспечение, которое неплохо работает, но аппаратное обеспечение, на котором оно функционирует, разваливается (и ему нет никакой замены). Ситуация может осложняться тем фактом, что у вас нет оригинального исходного кода, поэтому вы даже не можете перекомпилировать его для новой платформы. В таких случаях я видел, как организации идут на крайние меры, либо покупая остатки старых машин для того, чтобы переставить с них нужные детали (что только оттягивает неизбежное), либо создают эмуляторы платформы так, чтобы оригинальный код работал в них без изменений.

Переписать

Может настать момент, когда вы решите, что больше не в состоянии содержать существующую кодовую базу — ее поддержка или работа слишком дорого обходятся компании, и при этом она слишком хрупкая, чтобы ее можно было менять. В этой ситуации вполне разумно отрядить группу, чтобы переписать систему с нуля. В лучшем случае это внесет долгожданную свежую струю в кодовую базу, которая, в противном случае, так и осталась бы «затхлой». Однако этот путь чреват опасностями, несмотря на свою соблазнительность — полностью дублировать операционное поведение старого фрагмента программного обеспечения практически невозможно. Вы можете испытывать непреодолимое желание исправить некоторые очевидные ошибки в кодовой базе, но, скорее всего, обнаружите, что отдельные пользователи (люди или другие системы) опираются именно на эту семантику, считая ее функциональной особенностью. Так что, если вы двинетесь по этому пути, то должны быть готовы к следующему — либо нужно будет потратить массу времени на то, чтобы утвердить полную формальную операционную семантику системы, либо вам придется потихоньку менять отношение своих пользователей.

Воспользоваться плодами

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

Инкапсулировать

Самая распространенная проблема вполне работающего программного обеспечения — это его интеграция с более новыми решениями. Часто между старым, ориентированным на мэйнфреймы программным обеспечением и новыми системами существует технологическая несовместимость. И именно в подобных случаях на помощь приходят такие технологии, как сервис-оиентированная архитектура (Service-Oriented Architecture, SOA). Создайте вокруг вполне приемлемого, с вашей точки зрения, программного обеспечения оболочку и двигайтесь дальше. Изнутри это то же самое старое решение; снаружи — современное решение, прекрасно работающее с программами нового поколения. Главное, конечно, поместить оболочку в нужное место и сделать «отверстия» для нее правильного размера и формы.

Преобразовать

Это сделать сложнее всего, поскольку тут необходима твердая рука, понимание будущих перспектив и целеустремленность, чего часто не хватает в организациях, занимающихся разработкой. Как минимум, это простой рефакторинг — прочно закрепившаяся практика. Как максимум, это преобразование архитектуры. Если у вас есть фрагмент ценного программного обеспечения, настолько важного для вашего бизнеса, что вы не в состоянии от него отказаться, тогда ничего другого вам не остается. Как я уже говорил, ваша единственная надежда сохранить его актуальным — постоянно его преобразовывать. Такой подход требует твердой руки, поскольку желание решить краткосрочные задачи всегда будет противостоять непрерывному преобразованию. Это требует понимания дальнейших перспектив, поскольку необходимы инвестиции, которые окупятся лишь в долгосрочной перспективе, и, как следствие, во многом это зависит от капризов рынка и недальновидных менеджеров. На практике мне известны три организации, которые сделали выбор (и подкрепили его экономически) в пользу осознанного непрерывного преобразования — и каждая из этих компаний представляет собой весьма успешный бизнес.

Сохранить

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

***

Экономически перспективное программное обеспечение — это всегда серьезные инвестиции (имеются затраты на создание, развертывание, работу и даже владение таким программным обеспечением), но и также сопутствующая польза. Таким образом, я различаю сохранение и эволюцию:

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

Гради Буч (architecture@booch.com) — IBM Fellow и один из создателей языка моделирования UML. Разработал метод разработки программного обеспечения, называемый теперь его именем (Object-Oriented Analysis and Design, Addison-Wesley, 1993).