Шрифт:
Урок 6. Несмотря на то, что всех новоиспеченных сотрудников нам привело одно и то же агентство, все они работали на разные консалтинговые компании. Я платил за их услуги по 125 долларов в час, из которых самим исполнителям доставалось только от 15 до 55.
Но… все эти уроки я выучил слишком поздно. Лишь один из трех проектов был успешно завершен; остальные два постигла печальная судьба – немалые деньги оказались выброшенными. Ни за что больше не буду ввязываться в подобные авантюры.
Оценка методологий разработки программных средств
Раньше программирование считалось уделом инженеров и ученых, весьма далеких от суеты бизнес-центров. Нынче компьютерами пользуются все подряд, а употребление технологических достижений в коммерческих целях обязывает создавать качественные программные продукты вовремя и в рамках установленного бюджета. К последнему утверждению можно, конечно, относиться с иронией, но факт остается фактом: эпоха программ, разрабатывавшихся энтузиастами по собственным правилам, ушла в историю. Бизнес требует тщательности в разработке и внимания к практическому результату деятельности персонала. Здесь-то и начинается самое интересное. Практически все представители нашей индустрии, получившие какое-никакое признание, считают себя экспертами и норовят продать «уникальные» методологии разработки.
Со мной другая ситуация – я пытаюсь продать принцип эклектичности в методиках разработки. Задействуйте и совершенствуйте те методы, которые доказали свою практичность для вас лично, для группы и для компании. Создавайте собственные методы и приспосабливайте их для нужд своей организации – вне зависимости от того, что они собой представляют, суть должна быть одна: оперативная разработка качественного программного обеспечения. В следующих разделах я привожу обзор заметных школ разработки программных средств, причем основной акцент делаю на их концептуальной основе. Школы проектирования я обсуждать не собираюсь. Структурное программирование, объектно-ориентированное проектирование, эталоны проектирования – все эти течения в основном сфокусированы на деталях конструкции и значительно меньше внимания уделяют общей методологии разработки. Архитектурные проблемы (рассматриваемые в главе 6) также не получают в них достаточно глубокого развития. Итак, отступив от деталей, я собираюсь представить на ваш суд наиболее общий анализ ситуации.
Создавайте собственные методы и приспосабливайте их для нужд своей организации – вне зависимости от того, что они собой представляют, суть должна быть одна: оперативная разработка качественного программного обеспечения.
Программная инженерия
В конце 1960-х годов, когда тогдашним инженерным гениям удалось высадить человека на Луну, располагая при этом меньшими вычислительными мощностями, чем любой современный калькулятор [110] , в обиход вошел термин «программная инженерия». Эта концепция зиждется на представлении, согласно которому программное обеспечение можно разрабатывать средствами традиционных инженерных дисциплин. Применительно к сверхкрупным программным проектам, которые, как правило, заказывались правительством или крупными подрядчиками министерства обороны, эта методика несколько раз показала достойные результаты, но в остальных случаях потерпела фиаско [111] . Метод программной инженерии зачастую применялся в условиях одновременной разработки программного и аппаратного обеспечения. Кроме того, с его помощью удалось создать несколько коммерческих продуктов. IEEE определяет этот метод следующим образом:
110
Первый функционирующий микропроцессор появился в 1971 году.
111
См. Glass, Software Runaways, op. cit.
«Программная инженерия – это систематический, структурированный, количественный подход к разработке, функционированию и сопровождению программных средств; иначе говоря, способ применения инженерных методов в разработке программных продуктов» [112] .
Полагаю, вы, как и я, в замешательстве. Основное внимание в этом методе уделяется сокращению количества дефектов в коде – о соблюдении бюджетных рамок ни слова.
Это не в меру сжатое определение, по-моему, можно расширить.
112
См. IEEE Standard Computer Dictionary (Institute of Electrical and Electronics Engineers, Институт инженеров по электротехнике и электропике, 1990).
• Систематически – все аспекты разработки можно контролировать в едином процессе.
• Структурно – последовательное употребление должных методов с целью производства качественного программного продукта.
• Количественно – все требования известны и допускают отображение на методы реализации.
Прежде чем чесать затылок, глядя на мою интерпретацию трех основных концепций программной инженерии, согласитесь: всем нам хотелось бы достичь определенности, точности и завершенности, которые декларируются. Посмотрим, как относится к мифу о суперпрограммистах один из наиболее последовательных поборников программной инженерии:
«Существует распространенное мнение, согласно которому несколько высококлассных специалистов, собранных вместе, способны сделать больше, чем стандартная группа разработчиков. Имеется в виду, что их знания о способах достижения высоких результатов интуитивны, а значит, потребность в систематизации процесса отпадает. Будь это действительно так, можно было бы предположить, что компании, у которых в штате числятся наиболее квалифицированные специалисты, не должны испытывать типичных проблем с качеством разрабатываемых программных средств и продуктивностью. Опыт же подсказывает нам, что это совершенно не так» [113] .
113
Humphrey, op. cit., p. ix.
Видите, какой получается конфликт. «Человек» противопоставляется «машине» – в контексте программной инженерии «машиной» можно назвать дисциплинированную группу разработчиков, работающую на основе общей методологии. «Человеком» же обозначается программист-светило, который как по волшебству мастерит продукты, руководствуясь исключительно своими познаниями. В дискуссию по этому поводу (по-моему, она немного искусственна) вступать не стоит. Хорошие специалисты и надежный процесс в равной степени необходимы – не будь одного из этих компонентов, создавать качественные программные продукты было бы крайне сложно. Вопрос лишь в том, является ли надежным процессом программная инженерия.