Человеческий фактор в программировании
Шрифт:
Если вы когда-нибудь пользовались текстовым редактором или электронной печатной машинкой, снабженной системой проверки орфографии в реальном времени, вы сами знаете, почему. Этот вредный гном постоянно встревает, чтобы сказать вам, что, возможно, вы сделали ошибку. При этом он подпрыгивает, словно резвящийся щенок, или пищит, как сканер штрих-кода в магазинной кассе. Даже если он прав, а вы не правы, вас это не волнует. Вы хотите просто записать свои мысли, и чтобы при этом вас не прерывал никакой сумасшедший умник, знающий орфографию.
Одно из правил простого, но мощного метода «мозгового штурма» заключается в том, что никто не может критиковать или комментировать какую-либо идею до тех пор, пока весь процесс не закончен и все идеи не изложены. Отделение творческого процесса от процесса
CASE-инструмент, который соответствует способу мышления человека, не выступает в роли критика, пока вы создаете что-либо. По существу, такой инструмент позволят нарисовать и описать все виды элементов, которые «неправильны», поскольку эти «отступления от правил» часто имеют решающее значение для нахождения удачных решений. Такой инструмент позволит вам отклониться от предписываемого порядка введения элементов, так как «методологии», описанные в книгах, не обязательно являются последним словом в разработке программного обеспечения. (На самом деле многие методологии являются неверными с точки зрения решения проблем человеком, но это уже другая тема.)
Следует ли нам оставить надежды и поставить CASE-инструменты на полку? Нет, надежда все же остается. Современные CASE-инструменты — это примитивные предшественники тех инструментов, которые нам действительно нужны. Они еще появятся.
Все это немного напоминает первые программы обработки текстов, такие как Electric Pencil или первые версии WordStar. Согласно сегодняшним стандартам функциональности и удобства, они не выдерживают критики. Пользователю приходилось ждать минуты, чтобы перейти с одного конца документа на другой. Для выполнения элементарных действий требовались непонятные и сложные нажатия клавиш, а средства форматирования были ограниченными. Однако применять эти редакторы было намного'удобнее, чем писать от руки или печатать на машинке, а потом перепечатывать и перепечатывать.
Впрочем, кто-нибудь из тех, кто создает CASE-инструменты, возможно, прислушается к сказанному.
Из журнала Computer Language Magazine, том 9, № 1, январь 1992 г.
19
Вопросы моделирования
«Хороший инструмент для разработки — это тот инструмент, который не замедляет мою работу». Программист осторожно посмотрел на коробку весом почти 40 кг, в которой находилась новейшая и лучшая среда разработки на С++. «Мне нужен такой инструмент, который даст мне возможность программировать так, как я хочу. После этого на основе кода такой инструмент должен составить эти дурацкие схемы, которые требует от меня начальник». Думаю, что сейчас, наверное, самое время поговорить об этих дурацких схемах.
Многие разработчики — особенно те, которые ломают головы над созданием микрокомпьютеров и рабочих станций, — имеют очень смутное представление о структурных схемах, диаграммах объектных коммуникаций, схемах информационных потоков и блок-схемах. Довольно многие из них никогда не рисовали функциональных иерархий и растерялись бы, обнаружив такие схемы на своем столе. Увидев Booch-грамму, [25] они подумали бы, что это какая-нибудь плохая новость, доставленная на желтой бумаге курьером из компании Booch Telecommunications.
25
Grady Booch (Гради Буч) — признанный эксперт в области объектно-ориентированной методологии разработки программного обеспечения.
Многим сегодняшним волшебникам в области программного обеспечения эти прямоугольники и овалы, окружности и стрелки кажутся иероглифами, которые оставили исчезнувшие служители культа. Такие значки рассматриваются ими как наследие отживающих свой век методов, таких как структурный анализ и проектирование, которые уступили дорогу ус-
коренной объектно-ориентированной разработке программ на основе создания прототипов. Схемы и диаграммы не находят своего места в быстро меняющемся мире скороспелых микроприложений, разрабатываемых с помощью методов визуального программирования и быстрого создания приложений.
Конечно, структурные схемы и другие классические модели проектирования и анализа были разработаны не для того, чтобы замедлить процесс программирования, так же, как они не были созданы для того, чтобы удовлетворить нужды суетливых потребителей или осчастливить во все вмешивающихся руководителей. Большинство этих методов разработчики придумали для собственных нужд — чтобы упростить и ускорить свою работу. Время, затраченное на обдумывание программ с помощью моделей, — это время, которое экономится при программировании и отладке. Модели проектирования и анализа сокращают время разработки, так как позволяют моделировать программы без необходимости их кодирования и облегчают принятие замысловатых решений для сложных задач. Все это хорошо известно. Хороший план сокращает время разработки; хорошие модели проектирования упрощают планирование.
На практике не все графические модели работают таким образом. Некоторые, например HIPO-схемы [26] и их вспомогательные методы от компании IBM, вполне заслуженно канули в лету. Другие страдают от громоздкости и сложности обозначений или механизмов их рисования. Первоначально CASE-инструменты появились как специальные инструменты рисования, облегчающие создание схем. Со временем они превратились в более комплексные средства, облегчающие разработку программного обеспечения.
26
HIPO (hierarchical-input-processing-output) — технология разработки программного обеспечения на базе идеи структурного программирования.
Разработчики программного обеспечения рисуют картинки перед созданием самих программ по тем же причинам, что и архитекторы, рисующие поэтажные планы и вертикальные профили перед тем, как приступить к строительству дома. Тем не менее здания не всегда строились с помощью планов и рисунков. Если схема здания достаточно проста и знакома, строители могут работать без помощи моделей, ведя проектирование в процессе строительства. Сельским общинам на рубеже веков не требовались чертежи, чтобы построить сарай. В те времена сараи имели простую конструкцию, а в их строительстве применялись несложные методы. Каждый знал, как выглядит сарай, как он строится и что для этого требуется. Большинство членов общины уже занималось этим, а новички могли научиться, внимательно наблюдая за тем, что делают другие, и делая то же самое. Но если перейти от хижин и сараев к домам в колониальном стиле с четырьмя спальнями или высотным квартирным комплексам, то все становится сложнее.
То же самое можно сказать и о компьютерных программах. В те времена, когда 64 Кбайт оперативной памяти было пределом, а в качестве операционной среды использовалась СР/М, было вполне возможно и разумно удерживать всю программу в своей голове. Но тот, кто говорит, будто сможет запомнить все детали в сотнях тысяч строк программы на С, говорит неправду — если не вам, то себе. Именно здесь возникает необходимость в моделях проектирования.
Обратите внимание, что мы говорим о моделях, а не о схемах, о проектировании, а не о документировании. Для многих разработчиков эти странные картинки — все равно что китайская грамота. В лучшем случае это еще одна часть документации, которую нужно держать в папочке потому, что это требуется по контракту. Действительно, проектные модели могут быть полезными в качестве документации. Чертежи вашего дома не только нужны для строителей, но и могут помочь определить, где пробить стену, чтобы добраться до трубы с горячей водой (и не задеть ее). Структурные схемы и диаграммы взаимодействия между блоками могут показать, где нужно искать те или иные процедуры, или помочь отследить потоки движения информации, или понять, как организована система в целом. Однако основное назначение моделей проектирования — помогать проектировать.