Библиотека Интернет Индустрии I2R.ru |
|||
|
К вопросу о современной организации программированияДолжен прежде всего отметить, что сравнение программирования (и программистов) по государственному признаку - крайне неблагодарная задача. Автор неминуемо впадает в опасность выдать те или иные особенности конкретной организации за характерные черты всей нации. То, что на совещание созывают по электронной почте или голосом, кто размножает материалы к совещанию: секретарша или начальник, и в какой ящичек эти материалы кладутся - скорее любопытные путевые заметки, которые больше отражают наличие секретарши и ящичков, чем реальные способы организации работы. Гораздо продуктивнее, на мой взгляд, попытаться выделить характерные черты современного высокопроизводительного программирования. Разумеется, эта тема огромна, поэтому ограничусь только вопросами организации программистских коллективов и одним из существующих подходов. Движущей силой разработки новых методов организации программирования в настоящее время является осознание двух реалий: массовости программирования и его сложности. Компьютеризация всех аспектов производства является жизненной необходимостью для большинства компаний. Сбой программы означает остановку производства, легкость и удобство использование программы означает преимущество перед конкурентами. Это относится к любому типу организаций: академические институты, телефонные компании, банки, магазины и заводы. Несомненно, подобное положение вещей характерно для западных компаний, прежде всего американских. Можно спорить, хорошо это или плохо, зашла ли наша зависимость от компьютеров слишком далеко, но тенденция необратима и эта тенденция общемировая. Программирование, несмотря на свою массовость, осталось искусством. На сегодняшний день все попытки полностью формализовать или автоматизировать процесс написания программ оказались несостоятельными. Самая лучшая методология и самый современный язык программирования в конце-концов оказываются в руках человека, со всеми его человеческими слабостями. Но только он может заставить программу работать. Успех или неуспех проекта определяется прежде всего способностями и квалификацией команды разработчиков, и только во вторую очередь - иструментарием, которым они пользуются. Разумеется картина будет неполной без упоминания простого принципа рынка: "кто не успел, тот опоздал". Если вы не выпустили вашу систему на рынок сегодня, завтра это сделают ваши конкуренты. Перечисленные факторы кажутся очевидными и не заслуживающими особого упоминания. Однако без их ясного осознания невозможно понять доминирующие тенденции разработки ПО. Мы имеем дело с массовым творческим инженерным процессом производства удобных в использовании вещей. И любые способы организации разработки, которые игнорируют хотя бы одно из перечисленных прилагательных, обречены на провал. В течении долгого времени программирование обращалось за примерами организации производства к другим инженерным дисциплинам и прежде всего к проектированию электроники. Немало полезного было оттуда заимствованно - в частности, методы тестирования. Однако программирование обладает спецификой, аналогов которой нет в чисто инженерных областях. В последнее время был найден более адекватный пример - архитектура. Слово архитектура встречалось в словаре программистов давным-давно, но лишь недавно программирование стало напрямую заимствовать и развивать способы работы архитекторов [3]. Архитектура имеет долгую историю и в начале 20-го века она столкнулась с теми-же проблемами, что и программирование сегодня: необходимость сочетать массовость, творчество и инженерию. Успех или неуспех архитектурного проекта зависит не только от того, что здание не рухнет, но и от того, удобно оно или неудобно для человека. Новое направление получило название "проектирование по образцам" и первая книга - "Design Patterns" [4] - немедленно стала бестселлером. Начавшись с собирания лучших проектных решений, это направление ставит перед собой гораздо более амбициозные цели - создание мета-языков проектирования, описывающих не столько средства разработки, сколько его процесс. Тем самым от "проектирования по образцам" оно постепенно сдвигается в "анализ и организацию по образцам" [5,6,7]. Чтобы не быть голословными, рассмотрим небольшой пример. В работе [6] Джим Коплен предлагает систему шаблонов организации группы разработчиков программного обеспечения, которая обеспечивает наивысшую продуктивность. Вот в сокращенном виде образец под названием "Архитектор тоже программирует": Задача: Как сохранить стройную архитектуру в процессе разработки? Контекст: Коллектив нуждается в стратегическом направлении. Силы: Тотальный контроль рассматривается большинством коллективов как драконовская мера, необходимая информация должна свободно достигать ключевых разработчиков. Решение: Кроме руководства и обсуждения идей с разработчиками, архитектор должен непосредственно участвовать в создании кода. Результат: Организация, которая более полно использует опыт ведущего архитектора и сама приобретает архитектурный опыт. Уместно привести также названия и некоторых других образцов: "Команда сама себя подбирает", "Разработчик управляет процессом", "Архитектор управляет продуктом", "У кода есть владелец", "Проектирование программы привязано к проектированию тестов" и т.д. Принципиальными особенностями работы Коплена (характерными и для всего подхода организации по образцам) являются:
|
|
2000-2008 г. Все авторские права соблюдены. |
|