Эндрю Хант - Программист-прагматик. Путь от подмастерья к мастеру

Начиная со структурного программирования, через бригады главного программиста, CASE-средства, разработку методом «водопада», спиральную модель, метод Джексона, диаграмму «сущность-связь», облака Буча, метод объектного моделирования, метод Objectory, метод Коуда/Йордона до современного языка UML информатика никогда не страдала от недостатка методов, стремившихся уподобить программирование инженерной дисциплине. Каждый метод имеет своих приверженцев, и каждый из них переживает период популярности. Затем ему на смену приходит следующий. Долгая жизнь была суждена возможно лишь одному из всех этих методов – структурному программированию.

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

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

Подсказка 58: Не будьте рабом формальных методов

Формальные методы имеют ряд серьезных недостатков.

• Большинство формальных методов фиксируют требования, используя сочетание диаграмм и нескольких пояснительных фраз. На этих рисунках показано, как проектировщик понимает требования. Однако в многих случаях для конечных пользователей эти диаграммы бессмысленны, поэтому они нуждаются в их интерпретации проектировщиками. Следовательно, в реальности формальная проверка требований со стороны фактического пользователя отсутствует – все основывается на объяснениях проектировщика, как и в старомодных письменных требованиях. В этом способе фиксирования требований есть определенная польза, но мы предпочитаем, если это возможно, предоставить в распоряжение пользователя некий прототип и дать ему с ним поиграться.

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

• Мы предпочитаем создавать настраиваемые динамичные системы, используя метаданные, позволяющие изменять характер приложений в ходе их выполнения. Большинство современных формальных методов сочетают модель статического объекта или данных с некоторой разновидностью механизма построения диаграммы событий или процесса. Мы пока не встречали механизма, позволяющего отображать динамизм, ожидаемый от систем. На самом деле большинство формальных методов уводят в сторону, поощряя стремление к заданию статических отношений между объектами, которые на самом деле должны быть связаны между собой динамически.

В своей статье в журнале САСМ [Gla99b], написанной в 1999 г., Роберт Гласе сделал обзор исследований улучшений в производительности и качестве, достигнутых благодаря семи различным технологиям разработки программ (технология 4GL, структурные методики, CASE-средства, формальные методы, методология «чистой комнаты», модели процессов и ООТ). Он сообщает, что первоначальное оживление, связанное со всеми этими методами, было преувеличено. Хотя существуют указания на то, что у некоторых методов есть преимущества, эти преимущества начинают проявляться только после существенного снижения производительности и качества, в период принятия технологии на вооружение и обучения пользователей.