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

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

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

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

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

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

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

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

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

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

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

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

• Количественно – все требования известны и допускают отображение на методы реализации.

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

Видите, какой получается конфликт. «Человек» противопоставляется «машине» – в контексте программной инженерии «машиной» можно назвать дисциплинированную группу разработчиков, работающую на основе общей методологии. «Человеком» же обозначается программист-светило, который как по волшебству мастерит продукты, руководствуясь исключительно своими познаниями. В дискуссию по этому поводу (по-моему, она немного искусственна) вступать не стоит. Хорошие специалисты и надежный процесс в равной степени необходимы – не будь одного из этих компонентов, создавать качественные программные продукты было бы крайне сложно. Вопрос лишь в том, является ли надежным процессом программная инженерия.

Мнения на этот счет расходятся. Предположим, перед вами стоит задача конструирования системы управления воздушным движением. На первый взгляд, программная инженерия прекрасно подходит для ее решения. Но… стоит подумать еще раз. К провалу проекта комплексной системы автоматизации (Advanced Automation System, AAS) Федерального управления гражданской авиации США (Federal Aviation Administration, FAA), с помощью которого в 1980-х годах предполагалось модернизировать систему управления воздушным движением, методика программной инженерии имеет непосредственное отношение. Несмотря на миллионные затраты, проект так и не оправдал ожиданий[114].

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