Профессионально занимаясь программированием как в России, так и в США, я убежден, что эта тема заслуживает самого серьезного разговора.
Должен прежде всего отметить, что сравнение программирования (и программистов) по государственному признаку - крайне неблагодарная задача. Автор неминуемо впадает в опасность выдать те или иные особенности конкретной организации за характерные черты всей нации. То, что на совещание созывают по электронной почте или голосом, кто размножает материалы к совещанию: секретарша или начальник, и в какой ящичек эти материалы кладутся - скорее любопытные путевые заметки, которые больше отражают наличие секретарши и ящичков, чем реальные способы организации работы. Гораздо продуктивнее, на мой взгляд, попытаться выделить характерные черты современного высокопроизводительного программирования. Разумеется, эта тема огромна, поэтому ограничусь только вопросами организации программистских коллективов и одним из существующих подходов.
Движущей силой разработки новых методов организации программирования в настоящее время является осознание двух реалий: массовости программирования и его сложности.
Компьютеризация всех аспектов производства является жизненной необходимостью для большинства компаний. Сбой программы означает остановку производства, легкость и удобство использование программы означает преимущество перед конкурентами. Это относится к любому типу организаций: академические институты, телефонные компании, банки, магазины и заводы. Несомненно, подобное положение вещей характерно для западных компаний, прежде всего американских. Можно спорить, хорошо это или плохо, зашла ли наша зависимость от компьютеров слишком далеко, но тенденция необратима и эта тенденция общемировая.
Программирование, несмотря на свою массовость, осталось искусством. На сегодняшний день все попытки полностью формализовать или автоматизировать процесс написания программ оказались несостоятельными. Самая лучшая методология и самый современный язык программирования в конце-концов оказываются в руках человека, со всеми его человеческими слабостями. Но только он может заставить программу работать. Успех или неуспех проекта определяется прежде всего способностями и квалификацией команды разработчиков, и только во вторую очередь - иструментарием, которым они пользуются.
Разумеется картина будет неполной без упоминания простого принципа рынка: "кто не успел, тот опоздал". Если вы не выпустили вашу систему на рынок сегодня, завтра это сделают ваши конкуренты.
Перечисленные факторы кажутся очевидными и не заслуживающими особого упоминания. Однако без их ясного осознания невозможно понять доминирующие тенденции разработки ПО. Мы имеем дело с массовым творческим инженерным процессом производства удобных в использовании вещей. И любые способы организации разработки, которые игнорируют хотя бы одно из перечисленных прилагательных, обречены на провал.
В течении долгого времени программирование обращалось за примерами организации производства к другим инженерным дисциплинам и прежде всего к проектированию электроники. Немало полезного было оттуда заимствованно - в частности, методы тестирования. Однако программирование обладает спецификой, аналогов которой нет в чисто инженерных областях. В последнее время был найден более адекватный пример - архитектура. Слово архитектура встречалось в словаре программистов давным-давно, но лишь недавно программирование стало напрямую заимствовать и развивать способы работы архитекторов [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"
