Эволюция

• “Agile-эволюция: направление совершенствования унаследованных программ”
  

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


• пользователи заказчика в лице его менеджеров или операционистов;
• клиенты;
• конкуренты;
• сторонние программные продукты, связанные с данным ПО;
• изменения внутренних регламентов заказчика;
• изменение операционной платформы;
• изменение архитектуры;
• рост объемов информации;
• наращивание спектра услуг.


Заложенная изначально универсальность и адаптивность любого проекта имеет свои границы. Как правило, за пределами использования встроенных языков запросов, интерфейсов API (application programming interface) и/или стандартных протоколов (ODBC, XML, …), эволюция ПО подразумевает высокую степень индивидуализации. Перед потребителем в лице руководителя IT-подразделения возникает проблема выбора, аналогичная известной ситуации с былинным богатырем на распутье у трех дорог:


• переход действующего проекта от стереотипного к именному;
• заказ новой разработки;
• покупка более адекватного нового продукта.
  
  Обычно консультанты расписывают преимущества, которые сулит смена технологии, однако опытные IT-директора и директора по технологиям стремятся использовать новую технологию только в тех областях, где она дает преимущество в бизнесе и позволяет, где возможно, развивать унаследованный код. Многие старые системы по-прежнему остаются самыми лучшими, надежными, специфическими решениями с более низкой общей стоимостью владения, чего нельзя добиться с помощью более новых технологий. Кроме того, зачастую “новое поколение” специалистов, рассматривая прежнее решение лишь как историческую ценность, игнорирует тот драгоценный опыт, который породил тот, а не иной выбор и одновременно переоценивает зрелость новых технологий. В результате, предпринимаемые попытки переписать крупные системы или купить нечто похожее и суперсовременное, оказываются неудачными.
  
  Имея 15-летний опыт эволюции такого крупного проекта, как МтБАНК, компания "ЭСКЕЙП-М" создала и запатентовала специальную технологию escM® для управления процессом эволюции и его информационной поддержки. Основные принципы этой технологии закономерно совпали с общепринятыми принципами теперь уже знаменитой технологии Agile. Ниже приводятся отрывки из статьи Дейва Томаса:

    

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

К сожалению, возникает ощущение, что современные студенты изучают только технологии и практические методы создания программного обеспечения, которые существуют всего несколько лет. В силу этого предприятия сталкиваются с невероятными проблемами в тех ситуациях, когда необходимо связать изолированные технокультуры, например COBOL/PLI с Cи; 4GL/VB/Smalltalk/C++ с Java/C#; Java/C# с LAMP и т.д. Каждая технокультура использует свои собственные методы, языки и инструменты.

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

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



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

В своем выступлении на Dahl-Nygaard Prize ECOOP 2006 (www.emn.fr/xinfo/ecoop2006/keynote3.html) Ральф Джонсон заявил о необходимости менять приоритеты в образовании, исследовании и профессиональной практике и переносить упор с создания нового программного обеспечения на работу с уже существующим. Навыки, требуемые для успешного совершенствования унаследованных систем, кардинально отличаются от тех, что необходимы при разработке новых. Особое внимание следует уделять преобразованию [1], а не классическому проектированию и разработке. При грамотном программировании особое внимание следует уделять чтению кода, а не его написанию, вопреки сложившейся практике, которую долгое время считали наилучшим способом обучения разработчиков.

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

Программист, работающий с крупными унаследованными программными системами, всегда рискует столкнуться с неизвестным. В силу этого крайне важно, чтобы разработка начиналась с глубинного поиска, позволяющего лучше разобраться в кодовой базе. Такой поиск дает возможность объединить информацию, полученную от опытных разработчиков и пользователей, со знаниями, приобретенными в результате анализа кода, а также с соответствующей документацией и тестами. При обратном инжиниринге используют языковые технологии, такие как статический (www.klocwork.com/products/klocworkk7.asp) и динамический контроль и анализ потоков данных для поиска в коде информации, необходимой для выявления скрытых зависимостей, определяющих возможность совершенствования кода.

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

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

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



Каким образом методы agile-разработки может помочь в решении задач, возникающих в процессе анализа сложного программного обеспечения? Практически для любой системы подготовлено множество случаев применения, масса требований и объемная проектная документация. К сожалению, эти документы часто не в состоянии передать суть работы системы специалисту, отвечающему за ее эволюцию. Вторая проблема заключается в том, что существующая документация неактуальна и зачастую имеет пробелы в важных областях. Один из лучших способов добиться понимания сути работы системы — сделать это с помощью людей, которые готовы поделиться знаниями, накопленными во время работы с ней. С недавнего времени этот подход снова начал широко применяться как средство сохранения корпоративных знаний [3].

В течение многих лет молодые специалисты, приходившие в такие компании, как Nortel или IBM, сначала проходили серьезное обучение, во время которого они часто постигали огромные объемы исходного кода; кроме того, своими знаниями с ними делились ведущие архитекторы и разработчики, которые рассказывали новым специалистам о сути систем. Сведения, которыми они делились, были неточными и порой неверными, однако они часто формировали важный контекст, который позволял новым сотрудникам работать над продуктами компании. Благодаря этому неофиты быстро узнавали, где находятся «опасные области», почему система работает не так, как они предполагали, или даже каков способ, используемый для ее документирования, а также многое другое.

И до сих пор лучше всего любознательные ученики могут постичь суть того, как работает система, изучая горы сложного кода, параллельно получая информацию от знающих специалистов. «Главной историей» в экстремальном программировании называют метафору (metaphor), а «небольшими историями» — описания случаев применения. Эти практические описания представляют своего рода «срезы» системы, позволяющие понять ее сущность. Понимание сути работы системы — важная часть процесса поддержки программ, и сделать это можно с помощью agile-методик. Обсуждения всегда лучше документации.

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

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

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

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

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

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

«Самым поразительным было то, что за три года моего участия в проекте месяц, когда я занимался поддержкой, дал мне больше, чем месяц программирования при создании системы. Я думаю о практических решениях как о своего рода сети безопасности, которая позволяет использовать процесс поддержки как возможность учиться, не беспокоясь о возможных неприятностях. Самые ценные моменты в продукте не были обнаружены и даже не могли быть обнаружены до тех пор, пока мы не использовали все многообразие возможностей среды поддержки agile-разработки», — отмечает Вард Каннингэм [4].

Каким образом agile-разработку можно использовать для работы с крупными системами, которые включают в себя хорошо известные модули, по той или иной причине имеющие значительное количество дефектов? Исторически сложилось так, что эти модули, как правило, менее всего понятны разработчикам, и последние вносят каждое новое исправление или реализуют новую функцию с большой осторожностью. В некоторых случаях очень трудно своевременно выпускать новые версии из-за того, что специалисты опасаются трогать базовые компоненты системы. Зарекомендовавшее себя решение этих проблем заключается в постепенной замене некорректных компонентов — по одному компоненту за раз. Этот подход часто называют «разработкой вместо поддержки».

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

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

***

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

“Делай, что можешь, с тем, что имеешь, там, где ты есть.”
Теодор Рузвельт