К вопросу о современной организации программирования

Александр Фридман
TechKnowledge, Inc.

Эти заметки являются продолжением темы, начатой двумя статьями, появившимися в недавних номерах журнала "Открытые системы" [1,2], где авторы попытались проанализировать и сравнить стиль организации программирования в российских и американских компаниях. Профессионально занимаясь программированием как в России, так и в США, я убежден, что эта тема заслуживает самого серьезного разговора.

Должен прежде всего отметить, что сравнение программирования (и программистов) по государственному признаку - крайне неблагодарная задача. Автор неминуемо впадает в опасность выдать те или иные особенности конкретной организации за характерные черты всей нации. То, что на совещание созывают по электронной почте или голосом, кто размножает материалы к совещанию: секретарша или начальник, и в какой ящичек эти материалы кладутся - скорее любопытные путевые заметки, которые больше отражают наличие секретарши и ящичков, чем реальные способы организации работы. Гораздо продуктивнее, на мой взгляд, попытаться выделить характерные черты современного высокопроизводительного программирования. Разумеется, эта тема огромна, поэтому ограничусь только вопросами организации программистских коллективов и одним из существующих подходов.

Движущей силой разработки новых методов организации программирования в настоящее время является осознание двух реалий: массовости программирования и его сложности.

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

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

Разумеется картина будет неполной без упоминания простого принципа рынка: "кто не успел, тот опоздал". Если вы не выпустили вашу систему на рынок сегодня, завтра это сделают ваши конкуренты.

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

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

Архитектура имеет долгую историю и в начале 20-го века она столкнулась с теми-же проблемами, что и программирование сегодня: необходимость сочетать массовость, творчество и инженерию. Успех или неуспех архитектурного проекта зависит не только от того, что здание не рухнет, но и от того, удобно оно или неудобно для человека.

Новое направление получило название "проектирование по образцам" и первая книга - "Design Patterns" [4] - немедленно стала бестселлером. Начавшись с собирания лучших проектных решений, это направление ставит перед собой гораздо более амбициозные цели - создание мета-языков проектирования, описывающих не столько средства разработки, сколько его процесс. Тем самым от "проектирования по образцам" оно постепенно сдвигается в "анализ и организацию по образцам" [5,6,7].

Чтобы не быть голословными, рассмотрим небольшой пример. В работе [6] Джим Коплен предлагает систему шаблонов организации группы разработчиков программного обеспечения, которая обеспечивает наивысшую продуктивность. Вот в сокращенном виде образец под названием "Архитектор тоже программирует":

Задача: Как сохранить стройную архитектуру в процессе разработки?

Контекст: Коллектив нуждается в стратегическом направлении.

Силы: Тотальный контроль рассматривается большинством коллективов как драконовская мера, необходимая информация должна свободно достигать ключевых разработчиков.

Решение: Кроме руководства и обсуждения идей с разработчиками, архитектор должен непосредственно участвовать в создании кода.

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

Уместно привести также названия и некоторых других образцов: "Команда сама себя подбирает", "Разработчик управляет процессом", "Архитектор управляет продуктом", "У кода есть владелец", "Проектирование программы привязано к проектированию тестов" и т.д.

Принципиальными особенностями работы Коплена (характерными и для всего подхода организации по образцам) являются:

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

Образцы связаны в систему через явно сформулированные зависимости и взаимосвязи между ними.

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

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

Среди других методов организации программирования наиболее распространенными в Европе являются стандарт ISO 9000 [8], а в США - модель SEI-CMM [9,10].

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

Литература

[1] А. Васильев. Заметки об американском программировании.Открытые системы # 5 1996 сc. 70-71

[2] Дм. Волков, А. Гавердовский, И. Косякин. Заметки о российском программировании. Открытые системы. # 3, 1997 сc. 78-80

[3]. Cristopher Alexander et al. "A Pattern Languadge". Oxford University Press, New-York, 1977.

[4]. E. Gamma et al. "Design Patterns". Addison-Wesley, 1995.

[5]. M. Fowler. "Analisys Patterns: Reusable Object Model". Addison-Wesley, 1997.

[6]. Pattern Languadges of Program Design. Ed. J. Coplien and D. Schmidt. Addison-Wesly, 1995.

[7]. Pattern Languadges of Program Design. Part 2. Ed. J. Vlissides, J. Coplien N. Kerth. Addison-Wesly, 1996.

[8]. O. Oskarssen, R.L. Glass. "An ISO 9000 Approach to Building Quality Software".

[9]. W. Humphrey. "A Discipline for Software Engineering". MA: Addison-Wesly, 1994.

[10]. M. Paulk, C. Weber, B. Curtis, M. Chrissis, et al. "The Capability Maturity Model"

к оглавлению

Знаете ли Вы, что диаграмма состояний состоит
- из множества состояний объектов;
- из множества событий, сообщающих о перемещении чего-либо в новое состояние;
- из множества правил переходов, определяющих новое состояние объекта при возникновении тех или иных событий;
- из множества действий, которые должны быть выполнены объектом, когда он переходит в новое состояние.

НОВОСТИ ФОРУМА

Рыцари теории эфира