Ларри Константин - Человеческий фактор в программировании

Впрочем, кто-нибудь из тех, кто создает CASE-инструменты, возможно, прислушается к сказанному.

Из журнала Computer Language Magazine, том 9, № 1, январь 1992 г.

«Хороший инструмент для разработки — это тот инструмент, который не замедляет мою работу». Программист осторожно посмотрел на коробку весом почти 40 кг, в которой находилась новейшая и лучшая среда разработки на С++. «Мне нужен такой инструмент, который даст мне возможность программировать так, как я хочу. После этого на основе кода такой инструмент должен составить эти дурацкие схемы, которые требует от меня начальник». Думаю, что сейчас, наверное, самое время поговорить об этих дурацких схемах.

Многие разработчики — особенно те, которые ломают головы над созданием микрокомпьютеров и рабочих станций, — имеют очень смутное представление о структурных схемах, диаграммах объектных коммуникаций, схемах информационных потоков и блок-схемах. Довольно многие из них никогда не рисовали функциональных иерархий и растерялись бы, обнаружив такие схемы на своем столе. Увидев Booch-грамму, [25] Grady Booch (Гради Буч) — признанный эксперт в области объектно-ориентированной методологии разработки программного обеспечения. они подумали бы, что это какая-нибудь плохая новость, доставленная на желтой бумаге курьером из компании Booch Telecommunications.

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

коренной объектно-ориентированной разработке программ на основе создания прототипов. Схемы и диаграммы не находят своего места в быстро меняющемся мире скороспелых микроприложений, разрабатываемых с помощью методов визуального программирования и быстрого создания приложений. «У нас нет времени на рисование картинок. Нас поджимают жесткие сроки выпуска новой версии!» «Зачем вообще рисовать схемы, если можно просто писать код?» Это хороший вопрос. Для чего нужны эти рисунки?

Конечно, структурные схемы и другие классические модели проектирования и анализа были разработаны не для того, чтобы замедлить процесс программирования, так же, как они не были созданы для того, чтобы удовлетворить нужды суетливых потребителей или осчастливить во все вмешивающихся руководителей. Большинство этих методов разработчики придумали для собственных нужд — чтобы упростить и ускорить свою работу. Время, затраченное на обдумывание программ с помощью моделей, — это время, которое экономится при программировании и отладке. Модели проектирования и анализа сокращают время разработки, так как позволяют моделировать программы без необходимости их кодирования и облегчают принятие замысловатых решений для сложных задач. Все это хорошо известно. Хороший план сокращает время разработки; хорошие модели проектирования упрощают планирование.

На практике не все графические модели работают таким образом. Некоторые, например HIPO-схемы [26] HIPO (hierarchical-input-processing-output) — технология разработки программного обеспечения на базе идеи структурного программирования. и их вспомогательные методы от компании IBM, вполне заслуженно канули в лету. Другие страдают от громоздкости и сложности обозначений или механизмов их рисования. Первоначально CASE-инструменты появились как специальные инструменты рисования, облегчающие создание схем. Со временем они превратились в более комплексные средства, облегчающие разработку программного обеспечения.

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

То же самое можно сказать и о компьютерных программах. В те времена, когда 64 Кбайт оперативной памяти было пределом, а в качестве операционной среды использовалась СР/М, было вполне возможно и разумно удерживать всю программу в своей голове. Но тот, кто говорит, будто сможет запомнить все детали в сотнях тысяч строк программы на С, говорит неправду — если не вам, то себе. Именно здесь возникает необходимость в моделях проектирования.

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

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

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