Все новости от 21 мая 2001 г.

Тенденции программостроения

С 8 по 12 апреля в Сан-Хосе прошла конференция разработчиков ПО — SD 2001 West. На ней выступило немало известных специалистов по программированию. Большая дискуссия разгорелась вокруг наиболее эффективных способов создания ПО (вопросы, которыми занимается программная инженерия). Мнение практически всех участников SD 2001 было единодушным — время тяжелых методологий проходит.

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

Джим Хайсмич, редактор издания, посвященного вопросам разработки ПО, при возглавляемом Эдом Йордоном консорциуме Cutter, отмечает, что тенденции развития современных методологий создания ПО характеризуются двумя положениями:

1) процессы, способные быстро адаптироваться к меняющимся требованиям, важнее процессов, ориентированных на создание ПО в условиях полной информации о проекте;

2) люди работают в реальном мире, и необходимо учитывать не только теоретико-методологические рекомендации, но и практические условия взаимодействия сотрудников.

Стремление к переходу на легкие (специалисты часто употребляют слово “проворные” — agile) методики четко прослеживается по всему миру. В начале 2001 г. Хайсмич посетил Индию, где насчитывается самое большое число компаний, сертифицированных по 4-му и 5-му уровням тяжелой методологии CMM (фактического американского стандарта для крупных компаний). По его мнению, индийцы под видом CMM часто скрывают несложные проворные методики, ориентированные на скорейшее получение результата — нередко в ущерб качеству или функциональным возможностям.

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

Поведал Хайсмич и о собственной разработке — модели адаптивного создания приложений (ASD). Ее отличительная особенность — акцент на эффективном взаимодействии между сотрудниками.

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

Уменьшение объема документации — еще одна особенность ASD (в принципе, и всех других легких методологий). Хайсмич достаточно точно выразил их суть — всегда стремиться минимизировать реальные объемы работ и делать это везде, где только возможно.

Гради Буч

Гради Буч, научный руководитель компании Rational Software, автор книг по объектному проектированию и один из разработчиков языка UML, считает насущным создание хорошей оболочки для групповой работы программистов. В ее рамках каждый проект хранится и ведется в виртуальном пространстве.

При этом состав команды, выполняющей проект, может постоянно меняться, личные встречи заменяются онлайновыми обсуждениями в чатах и форумах, а вся рутинная работа по сопровождению проекта выполняется программными агентами. Подобный стиль работы Буч назвал кочевым программированием. В качестве примеров он привел такие системы, как Yahoo Groups, Webmonkey и Groove.

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

Основная проблема подобных оболочек — обеспечение конфиденциальности. Здесь, считает Буч, поможет только время.

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

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

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

Ларри Константин, известный автор и консультант Constantine & Lockwood, отмечает, что для клиента пользовательский интерфейс и есть система. Все, что человек не видит на экране, для него не существует. Поэтому Константин предлагает сосредотачиваться не на процессах, а на продуктах, которые нужны рынку и заказчикам, и строить работу, исходя прежде всего из модели деятельности конечных пользователей.

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

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

Джон Хэлл “Maddog”

Джон Хэлл “Maddog”, популярнейшая личность в мире поклонников открытого программного кода, начал свою презентацию, посвященную будущему свободно распространяемых ОС, с замечания, что динамические картинки, которые присутствующие могли лицезреть на экране, сделаны не с помощью PowerPoint и Windows, а с помощью Linux.

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

Столь популярная сегодня бесплатная система Linux — одна из первых ОС, портированных на 64-разрядные платформы. Это случилось в начале 90-х годов, когда Maddog и Линус Торвальдс в составе группы добровольцев за девять месяцев перенесли прообраз Linux на платформу DEC Alpha.

Сегодня в мире насчитывается 30 млн. пользователей Linux, а китайское правительство приняло решение об использовании этой ОС как государственного стандарта. Другое направление применения Linux — встраиваемые системы. Ее ядро умещается в 100 Кб ОЗУ, разработчикам доступны тысячи драйверов всевозможных устройств, поддерживается 256 уровней прерываний, реализована удобная схема поддержки масштаба реального времени, имеется возможность настраивать интерфейс управления с помощью сценариев.

Довольно пессимистично на общем фоне прозвучало выступление Чарльза Коннелла, президента CHC-3 Consul-ting. Он сравнил программную инженерию — науку о том, как создавать эффективно работающее и качественное ПО в предсказуемые сроки, с метеорологией.

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

Детально проработано множество компьютерных дисциплин — теория языков программирования и баз данных, объектные модели, анализ алгоритмов, численные методы и т. д.

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

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

В ходе конференции один из ее спонсоров — журнал Dr. Dobb’s Journal, вручил очередную ежегодную награду за вклад в развитие программной индустрии Андерсу Хеджлсбергу.

В разные годы ее получали Александр Степанов (создатель библиотеки шаблонов C++ STL), Линус Торвальдс (разработчик Linux), Ларри Уолл (автор языка программирования Perl), Джеймс Гослинг (архитектор Java), Гуидо ван Рассэм (автор языка программирования Python) и др.

Хеджлсберг трудится в Microsoft, занимался проектированием Visual J++ и Windows Foundation Classes, а сейчас работает главным архитектором языка C#. Но наибольшую известность он получил как автор средства создания программ на Паскале Turbo Pascal, которое и по сей день активно используется в качестве обучающей системы по программированию (все версии Turbo Pascal можно бесплатно переписать с сайта http://community. borland.com).

Проживая в Дании, он в начале 80-х годов начал сотрудничать в виртуальном режиме с корпорацией Borland, используя модем на 9600 бод. 20 ноября 1982 г. в продажу поступил созданный им продукт Borland Turbo Pascal 1.0 по цене 50 долл. (аналогичные по возможностям системы тогда продавались по 500 и более долларов).

Интегрированная среда разработки, встроенный редактор и библиотека времени выполнения умещались в файле turbo.com размером 33 280 байтов. В ОЗУ они занимали 140 Кб. Turbo Pascal работал очень быстро, потому что большая его часть была написана на ассемблере — по мнению сотрудников Borland, в блестящем неповторимом стиле.

Спустя десять лет Хеджлсберг стал руководителем проекта по созданию Borland Delphi — общеизвестной визуальной среды разработки для Windows, а еще через три года перешел в Microsoft. Важнейшее в разработке программ, полагает он, — это простота.

Если вкратце подвести итоги конференции, то можно с уверенностью сказать, что никаких кардинальных сдвигов в сфере создания ПО не предвидится. Начиная с 1968 г., когда Дейкстра опубликовал свое знаменитое письмо “Оператор GOTO вреден” (“GOTO Statement Considered Harmful”), с которого и берет свое начало программная инженерия, самые крупные инвестиции в исследования в лучшем случае увеличивали эффективность труда программистов не более чем на 10%.

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

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

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

С автором можно связаться по э-адресу: sbo@pcweek.ru.

Обсуждение и комментарии

	Сергей Филатов - sfilatovrosneft.ru 22 May 2001 9:24 AM
Когда я начал изучать программирование (конец 70х), довелось услышать фразу: "Программисты - это люди убивающие свою профессию", т.е. люди, которые работают и разрабатывают продукты помогающие другим, менее квалифицированным людям выполнять ИХ РАБОТУ. Но, ИМХО, сегодня программисты - сапожники без сапог. Есть много хороших продуктов автоматизирующих самые разные виды деятельности, но я не видел удовлетворительных систем, автоматизирующих процесс создания программного продукта. И главная причина - отсутствие формализации процесса, попыток много, но ... С уважением, Сергей Филатов
	Yuri V. Blazhevich - yurinival.com 22 May 2001 5:12 PM
2Сергей Филатов а Вы почитайте про Intensional Programming от всеми любимой Microsoft - это действительно прорыв в программировании...
	Кир - ksmmail.ru 22 May 2001 5:41 PM
2Yuri V. Blazhevich : урл в студию !
	Nikolai 24 May 2001 2:34 PM
Какой прорыв в программировании от Microsoft!!!?? Это убогие VB 7.0 и С# (с открытыми в отличие от Java 2 полями классов визуальных элементов - привет создателю Дельфей!) прорыв на пополам с ASP что ли? VisualС++ как бало у них примитивным редактором кода, так и в .Net Studio и осталось. A COM+! Множество вложений шаблонов друг в друга - просто "рай" для программера. IMHO, единственно нормальным языком программирования для прикладных систем был Smalltalk. Альтернатива: не писать монстроподобный софт, что невозможно хардверщикам надо продавть свои железки, иначе рынок рухнет. (Сам пишу на С (дома для души под Linux) и на Java (на работе приходится))
	Сергей Филатов - sfilatovrosneft.ru 28 May 2001 8:40 PM
2Yuri V. Blazhevich : Конечно, в И-нете можно найти все, но ссылочка не помешала бы. Что касается инструмента: Мне не нужен инструмент, имеющий библиотеку красивых фенечек и прибамбасиков. Мне нужен инструмент с библиотекой серьезных, универсальных алгоритмов. И чтобы можно было накапливать решения без необходимости полного переписывания кода при появлении новых "модных" языков или технологий. Николай прав насчет Smalltalk. Это уже ближе к "автоматизации программирования", да и к объектному программированию он имеет большее отношение чем, например Visual C++. А где потерялся Лисп? Будем ли когда-нибудь использовать реалиционную алгебру, или SQL - это надолго? Эх, где же ты "холодная война". Время, когда в развитие технологий вкладывались огромные средства, когда было создано то, что мы сегодня только начинаем осваивать.
	Антон Блинков - bavinfopac.ru 29 May 2001 3:18 AM
А вот и ссылочка: http://www.research.microsoft.com/ip/ Вообчем generics programming в своей крайней форме. Изменять можно все, это то и беспокоит :)
	MishGUN - aliezzetemeil.ru 27 May 2004 9:45 PM
Что такое в общих чертах реалиционная алгебра