Эволюция требует изменений в культуре программирования
Парадоксально, но факт: разработчики ПО создают наиболее сложные элементы инфраструктуры предприятий, но сами при этом могут опираться лишь на очень незначительный набор средств. Чтобы изменить эту парадигму, превратить обеспечение инфраструктуры программирования в норму при создании центра разработки приложений, требуется гораздо больше, чем просто приобрести и инсталлировать инструменты для автоматизации управления проектами и тестирования ПО. Необходимы изменения в культуре программирования, без которых даже самые передовые средства разработки будут в лучшем случае просто "украшениями", а в худшем - неуклюжей попыткой отвлечь внимание от проблемы.
Утверждение, что процесс написания программ в сущности не изменился за последнюю четверть века, а то и больше, может показаться абсурдным. Начиная с появления языка Turbo Pascal компании Borland в 1983 г., либо даже Smalltalk в начале 80-х, или LISP в 70-х, стоящие перед программистами задачи все более сужались и часто стали сводиться к формуле "отредактировать, откомпилировать, отладить" ("edit, compile, debug").
Процесс, который некогда требовал набивки перфокарт, запуска задач и просмотра объемистых распечаток с результатами работы диагностических программ, стал для большинства программистов короче и единообразнее, протекает в одной-единственной электронной среде. Не является ли использование этих интегрированных сред большим шагом к созданию мощной "инфраструктуры программирования"?
Я бы возразил, что интегрированные среды сами по себе играют по отношению к разработке ПО ту же роль, что машины по отношению к запутанным и перегруженным улицам Бостона. Да, уровень комфорта вырос, и если все идет гладко, автомобили движутся гораздо быстрее, чем прежде. Но "сложные системы обычно функционируют в режиме неисправности", как заметил в 1978 г. Джон Голл в своем сатирическом произведении "Систесемантика" ("Systemantics"), содержащем много плодотворных идей. Команда разработчиков, если ее размеры больше обычного, несомненно, является сложной системой. И когда программисты обнаруживают путаницу или ошибку, их современные среды разработки могут оказаться столь же бессильными решить проблему, как бессилен был бы гоночный автомобиль "Формулы-1", если бы ему нужно было преодолеть пробку в деловой части города быстрее, чем это сделает нормальный пешеход.
Продолжающееся использование термина "отладка" служит доказательством того, что процесс программирования в сущности не изменился. И это тогда, когда все больше людей осознает, что объем встающих перед разработчиками задач увеличивается все быстрее. Каждый так называемый баг появляется в результате того же самого процесса, что и остальная часть кода, составляющего приложение. Это означает, что каждое действие, связанное с отладкой программы, требует определенных затрат труда, а затем еще и дополнительной работы, чтобы исправить проделанную ранее.
SOAtest 5.0 компании Parasoft проверяет качество обслуживания
Идея отладки, и так никогда не считавшаяся особо привлекательной, становится совершенно неработоспособной в условиях, когда ПО все чаще попадает к пользователям столь же быстро, как и создается. И когда приложение может включать как специально написанный код, так и удаленные сервисы других разработчиков. Мы говорим не об извлечении статуи из глыбы мрамора и все новой и новой ее доработке с целью доведения до совершенства. Мы говорим о процессе, который не должен порождать никаких ошибок, чтобы весь новый код добавлял дополнительные функции вместо того, чтобы снабжать пользователей опасной смесью из усовершенствованных функций и пониженной надежности.
Сторонники принципиального изменения подхода характеризуют последствия отладки для культуры программирования такими словами, как "автоматическое предотвращение дефектов в ПО" (Automated Software Defect Prevention). Это основная идея учебника " Automated Defect Prevention: Best Practices in Software Management", который написан Доротой М. Хейзинга (Dorota M. Huizinga) и Адамом Колава (Adam Kolawa) и должен выйти в августе в издательстве John Wiley & Sons. Авторы предлагают набор из шести принципов, которые я кратко сформулировал бы следующим образом: создание инфраструктуры, использование передового опыта, адаптация этого опыта к конкретному проекту, измерение и отслеживание статуса проекта, автоматизация повторяющихся задач и применение этих приемов по нарастающей.
Без автоматизации данный подход не может быть реализован по техническим причинам, а без расширения сферы применения он не имеет смысла с точки зрения культуры программирования.
Адам Колава подкрепляет свою позицию ссылками на опыт, приобретенный им, когда он выступал в качестве одного из создателей и генерального директора калифорнийской компании Parasoft (www. parasoft.com). 29 января эта компания выпустила решение SOAtest 5.0 (см.рисунок). Это значительно переработанный вариант продукта, о версии 4.5 которого лаборатория eWeek Labs писала в мае 2006 г. как о способной "внести ценный вклад в дело превращения процесса разработки в прозрачный и сертифицированный".
В январе нынешнего года, изучая вместе с инженерами из Parasoft релиз 5.0 за неделю до его появления в продаже, лаборатория eWeek Labs сочла, что особый интерес представляют средства определения сервисов и воспроизводящейся проверки их качества, а также инструменты обеспечения корректного функционирования. Но Адам Колава и Дорота Хейзинга могут лишь указать путь к изменению подхода к разработке ПО. Причем Адам Колава еще больше облегчает поиск верного направления с помощью инструментов своей компании и продемонстрированного успеха в их применении. Следовать ли этой дорогой - зависит от руководителей. Но если они этого не сделают, значит, они плохо управляют своими программистами.
