Как пасти котов. Наставление для программистов, руководящих другими программистами

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

Урок 6. Несмотря на то, что всех новоиспеченных сотрудников нам привело одно и то же агентство, все они работали на разные консалтинговые компании. Я платил за их услуги по 125 долларов в час, из которых самим исполнителям доставалось только от 15 до 55.

Но… все эти уроки я выучил слишком поздно. Лишь один из трех проектов был успешно завершен; остальные два постигла печальная судьба – немалые деньги оказались выброшенными. Ни за что больше не буду ввязываться в подобные авантюры.

Оценка методологий разработки программных средств

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

Со мной другая ситуация – я пытаюсь продать принцип эклектичности в методиках разработки. Задействуйте и совершенствуйте те методы, которые доказали свою практичность для вас лично, для группы и для компании. Создавайте собственные методы и приспосабливайте их для нужд своей организации – вне зависимости от того, что они собой представляют, суть должна быть одна: оперативная разработка качественного программного обеспечения. В следующих разделах я привожу обзор заметных школ разработки программных средств, причем основной акцент делаю на их концептуальной основе. Школы проектирования я обсуждать не собираюсь. Структурное программирование, объектно-ориентированное проектирование, эталоны проектирования – все эти течения в основном сфокусированы на деталях конструкции и значительно меньше внимания уделяют общей методологии разработки. Архитектурные проблемы (рассматриваемые в главе 6) также не получают в них достаточно глубокого развития. Итак, отступив от деталей, я собираюсь представить на ваш суд наиболее общий анализ ситуации.

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

Программная инженерия

В конце 1960-х годов, когда тогдашним инженерным гениям удалось высадить человека на Луну, располагая при этом меньшими вычислительными мощностями, чем любой современный калькулятор[110], в обиход вошел термин «программная инженерия». Эта концепция зиждется на представлении, согласно которому программное обеспечение можно разрабатывать средствами традиционных инженерных дисциплин. Применительно к сверхкрупным программным проектам, которые, как правило, заказывались правительством или крупными подрядчиками министерства обороны, эта методика несколько раз показала достойные результаты, но в остальных случаях потерпела фиаско[111]. Метод программной инженерии зачастую применялся в условиях одновременной разработки программного и аппаратного обеспечения. Кроме того, с его помощью удалось создать несколько коммерческих продуктов. IEEE определяет этот метод следующим образом:

«Программная инженерия – это систематический, структурированный, количественный подход к разработке, функционированию и сопровождению программных средств; иначе говоря, способ применения инженерных методов в разработке программных продуктов»[112].

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

Это не в меру сжатое определение, по-моему, можно расширить.

• Систематически – все аспекты разработки можно контролировать в едином процессе.