Как проектировать ПО? 13 лет спустья

Меня порой спрашивают, получила ли какое-либо развитие статья «Что такое программное проектирование?». Ответ — отрицательный.

Меня порой спрашивают, получила ли какое-либо развитие статья «Что такое программное проектирование?». Ответ — отрицательный. И дело не в том, что я забросил эту тему или изменил свои взгляды.

Когда статья появилась, я надеялся — а на самом деле, даже ждал этого — на реакцию отторжения со стороны отдельных «экспертов». Взяться за статью меня в немалой степени подвигло желание спровоцировать серьезные дебаты в софт-индустрии на тему процесса разработки ПО. Ничего подобного не случилось! Не было ни писем в редакцию, ни вопросов автору.

Вскоре после этой публикации «C++ Journal» канул в Лету, и я решил, что и мою статью поглотила некая пучина, в которой пропадает большая часть журнальных публикаций. Я переключился на другие занятия. Году в 97-м или 98-м по электронной почте мне пришло письмо от Боба Мартина (новоиспеченного редактора журнала «C++ Report»), в котором сообщалось, что на сайте Уорда Каннингэма (Ward Cunningham) c2.com моей статье посвящена wiki-страница. Это было первым свидетельством того, что кто-то ее прочитал (за исключением, конечно, тех, кому я лично вручил копию).

Я начал следить за дискуссиями на wiki-странице, иногда заглядывал в новостные группы, однако намеренно предпочитал не вмешиваться. Во-первых, я тогда работал над другими вещами; во-вторых, мне было ясно, что в профессионализме те, кто защищал мою позицию, не только не уступали мне, но иногда и превосходили (особенно мне запомнились реплики Майкла Физерса), и наконец, слишком уж много было у моей концепции противников. К сожалению, большинство аргументов мало отличались от тех, которые мне приходилось выслушивать на протяжении почти пятнадцати лет (напомню, что я вынашивал эту идею десять лет, прежде чем взялся за перо). Меня не вдохновляет общение с людьми, которые ни на минуту не способны подняться выше собственных предубеждений, хотя бы для того, чтобы просто выслушать чужое мнение. С тем же успехом можно учить французскому человека, который уверен, что любые иностранные языки — всего лишь диалекты английского. Не важно, что именно вы говорите, вас в лучшем случае перебьют, в худшем — начнут переубеждать. У меня было несколько проектов, в которых идея «проектирования в коде» работала, но даже те, кто участвовал в этих проектах, зачастую отказывались верить фактам. Скажи мне кто в ту пору, что ситуация может измениться, я бы тоже не поверил.

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

А.Чаще всего мне ставят в упрек следующее: «Если исходный код считать проектом, тогда программисты — это проектировщики. А поскольку это не так, то исходный код проектом не является». Конечно, здесь приведена обобщенная формулировка, но если начать разбирать высказывания оппонентов, то сухой остаток примерно таков. Есть некий набор доказательств, идущих по замкнутому кругу, которые начинаются с того, что программирование/кодирование есть вид производственной деятельности. Такова скрытая предпосылка. По сути вам говорят, что «ваше предположение ( «исходный код — это проект») противоречит моему («программисты — это рабочие-сборщики»), поэтому оно ложно».

Со стороны может показаться, что я впадаю в ту же крайность со своей предпосылкой, что исходный код — это проект. Возможно, но лишь до определенного момента. Не исключаю, что большая часть статьи выглядит так, будто я хочу доказать свое предположение, но, на самом деле, я пытался сделать вовсе не это. Заглянем в начало статьи:

«Я исхожу из того, что именно конечный исходный код является проектом программного продукта, и исследую некоторые следствия из этого допущения. Возможно, мне не удастся доказать, что эта точка зрения верна, но я надеюсь показать, что в действительности она объясняет некоторые замеченные мною факты, касающиеся индустрии программирования…»

Я не собирался доказывать, что «исходный код является проектом программного продукта», я готов согласиться с тем, что такое определение — до некоторой степени вкусовщина, но ведь о словаре можно договориться. Суть статьи — в попытке показать, что это допущение приводит к ясному и понятному объяснению множества рассматриваемых фактов. Ради бога, пусть кто-нибудь предложит лучшее объяснение, построенное на альтернативных предпосылках.

B.Сегодня, благодаря экстремальному программированию (eXtreme Programming) и «быстрым методам» разработки программ (agile methods), люди вынуждены, хоть и с большой неохотой, признать, что программисты вовсе не андроиды на конвейере. Однако, несмотря на это, они не готовы согласиться с концепцией исходного кода как проекта. Все возражения можно свести к следующей цитате (с той же wiki-страницы): «…Проектировать в коде с самого начала? Ха-ха-ха! Нет, правда? Ха-ха-ха!»

Меня бесят такие заявления. Я не понимаю, почему вменяемые образованные люди старательно валят в одну кучу совершенно разные вещи — проектирование как процесс и проект как продукт. Никого ведь не удивляет, что выпускник средней школы понимает разницу между, например, выражениями «лист бумаги» и «исписать бумагу». Определенно, можно ожидать от человека с высшим образованием понимания того, что к одному и тому же решению могут привести разные пути.

И все-таки они продолжают утверждать (переиначивая мою мысль), что предпосылка «код как проект» означает «не надо проектировать, надо кодировать». Да я в жизни не говорил ничего подобного. Я говорил:

«Нам отчаянно необходимо хорошее проектирование на всех уровнях. В частности, на уровне архитектуры. Чем лучше будет спроектирована архитектура, тем проще детализировать проект. Проектировщики должны использовать все, что им нужно: структурные схемы, диаграммы Буча, таблицы состояний, PDL и т. д. Если это работает, пользуйтесь!»

Сегодня я бы выразился иначе. Нам необходимы хорошая архитектура (проектирование высокого уровня), хорошие абстракции (проектирование классов) и хорошие реализации (проектирование нижнего уровня). Ну и, наверное, добавил бы пару слов о диаграммах UML или CRC-картах — в качестве альтернатив. Но все же я не собираюсь окончательно отрекаться от своих слов.
«Однако надо иметь в виду, что весь этот инструментарий еще не проект. Настоящий программный проект пишется на одном из языков программирования. Поэтому мы должны кодировать наши проекты с самого начала».

Это главное. Я не предлагаю отказаться от проектирования. Но когда речь идет о процессе, я считаю, что его нельзя считать завершенным раньше, чем написан и протестирован код.

Лично мне кажется, что проектировать можно и задумчиво глядя в потолок, и тасуя UML-диаграммы в Rose. Если прежде, чем взяться за какое-то дело, вы его хорошенько обдумаете, то успех вам почти обеспечен. Чтобы мыслительный процесс протекал живее, люди используют самые разные средства. Кому-то необходима бумага и карандаш. Кому-то — «белый экран» или компьютер. Одни оттачивают свои идеи на аудитории, другим нужна тишина и покой. Кто-то оперирует диаграммами, теми же UML, кому-то больше нравятся CRC-карты.

И совершенно не важно, кто чем пользуется, только не надо настаивать, что ваш инструментарий, который, по сути, не что иное, как проектный полуфабрикат, и есть собственно проект. Значение имеет только код. Если он хорош, то неважно, как он получен, лишь бы работал. А вот если хорошего кода нет — какая разница, сколько чепухи вы рассказали программистам до того, как они написали плохой код?

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

С другой стороны, человек, знакомый с традиционным подходом к разработке, — когда нельзя написать ни единой строчки кода прежде, чем «проект» не будет завершен, проверен, принят, утвержден и т. д., — знает, что кучу времени отнимает составление документов, которые устаревают в тот самый миг, когда начинается собственно кодирование. Так зачем суетиться?

Возможно, вы думаете, что можно найти золотую середину — уделяя проектированию достаточное, но не чрезмерное внимание. Не выйдет. Единственный способ проверки проекта — сделать билд и протестировать его. Сапогов-скороходов не существует, «правильного способа» проектирования — тоже. Порой предварительное обдумывание — в течение часа, дня или даже недели — может иметь значение для написания кода. Но бывает и так, что пять минут тестирования выявляют нечто, о чем вы и подумать не могли — неважно, сколько времени у вас было. Мы стараемся, как можем, а потом улучшаем то, что у нас получилось.

И напоследок. Я никогда не утверждал и не утверждаю, что исходный код — это единственная необходимая документация. Я специально отметил, что «вспомогательная документация так же важна для программного проекта, как и для «железного».
Исходный код может быть основным проектным документом, но почти никогда — единственным.

B’ Не могу удержаться и не упомянуть, казалось бы, второстепенный вопрос, который часто возникает в дискуссиях об экстремальном программировании и так называемых быстрых методах: «Что делать, если программист недостаточно компетентен?» Видимо, считается, что проектировать и кодировать одновременно могут только гении. Стало быть, все предварительное проектирование необходимо, поскольку нам приходится иметь дело с обычными программистами и мы должны заложиться на отсутствие опыта и таланта.

По мне, это все равно что спросить: «А что делать, если вам попался не очень квалифицированный врач?» Медицина и проектирование программных продуктов — дисциплины весьма далекие друг от друга, однако имейте, пожалуйста, терпение проследить мою мысль. К сожалению, всем нам нередко доводилось сталкиваться с докторами-«пустозвонами» («примите аспирин и позвоните мне завтра»). И все же, чтобы получить право называться доктором медицины, необходимо получить образование, накопить достаточный опыт и знания. Иными словами, мы хотим, чтобы врачи знали, что они делают.

В программировании вопрос о компетентности программиста обычно сводится к попытке замены процесса логикой, способностями и опытом. Очевидно, считается, что если заставить народ создавать больше UML-диаграмм (подставьте нужный инструмент), производить больше перекрестных проверок и всячески контролировать процесс детализации, то программисты вдруг поймут, чем они занимаются, и начнут кодировать лучше. Как показывает практика, подобный подход еще не увенчивался успехом, и нет оснований надеяться, что в будущем что-то изменится. Мой собственный опыт подсказывает, что грамотное использование надлежащих инструментов, например таких, как UML, сам по себе требует определенного уровня компетентности.

C.Другой встречавшийся мне аргумент ставит под сомнение утверждение, гласящее, что целью деятельности разработчика является определенный вид документации. Некоторые считают, что целью проектирования является «продукт» и что настоящие инженеры часто «строят штуки», которые и являются продуктом проектирования в той же степени, что и любая документация.

Такой подход пытается обойти вопрос «Как проектировать ПО?», выстраивая параллель между «штуками», которые строят «железячники», и тем, что создают программисты. По правде говоря, это чушь. Да, есть инженеры, которые строят «штуки» с небольшим количеством или без формальной проектной документации, но я подозреваю, что даже в этих случаях какая-то документация существует (даже если это надпись на обороте конверта). Как бы то ни было, подобные проекты порождают продукты-«однодневки», и обычно их создают одиночки.

Когда в процесс проектирования вовлекается более двух человек или когда в нем формально выделена стадия производства, документация начинает принимать угрожающие размеры. Инженеры Toyota и Motorola занимаются производством документации, не говоря уже о сотрудниках Boeing и Lockheed. Наверняка обязанности многих инженеров не ограничиваются только этим, но каждый уважающий себя спец знает, как выглядит проектная документация в его области, и занимается ею скорее чаще, чем реже. Можно ли сказать то же самое о «софтверных инженерах»?

Точку зрения, касающуюся инженеров и документации, я выудил из статьи в журнале «Datamation» аж в 1979 году. И полностью ее разделяю.

D.И еще одно соображение — так сказать, вдогонку. Исходный код недостаточно детализирован, чтобы считаться проектом. По крайней мере, один критик называл исходный код «спецификацией». Он считал, что настоящий проект — это то, что выходит из компилятора. Это, конечно, до некоторой степени вопрос формулировки, однако я все же не согласен.

Общепринятое определение гласит: «спецификация» говорит что, а за ней следует проектная документация, которая детализирует как. Хотя компилятор допускает некоторую степень гибкости в определении как объектного кода, творческим подходом в этом процессе и не пахнет. И именно здесь я провожу черту. Документ только тогда может называться проектной документацией, когда он достаточно детализирован, полон и недвусмыслен, чтобы быть интерпретированным механически, вне зависимости от того, будет ли эта операция производиться компьютером или рабочим на конвейере. Если же требуется творческая человеческая интерпретация, называние должно быть иным.

В программировании проектная документация — это листинг исходного кода.