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

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

Я видел несколько довольно хитрых способов, предназначенных для преодоления этого ограничения. В одной фирме у системного аналитика были в распоряжении две рабочие станции. На одной из них он вносил изменения и таким образом мог анализировать преимущества и недостатки сразу двух полных версий одной системы. Однако чаще всего альтернативный вариант содержится на бумаге, а другой — в хранилище CASE-инструмента.

Вот сцена, которую вы, возможно, видели или даже принимали в ней участие. Разработчик программного обеспечения, использующий CASE-инструмент, отдает команду распечатать или вывести на плоттер модель проектируемой системы, например схему потоков данных. Далее он бежит по коридору к серверу печати и получает результат. Затем он возвращается в офис, чтобы вывести другую модель той же системы, например ее структурную схему. После этого разработчик разрывается между моделью на экране и моделью на бумаге.

Даже так называемые «интегрированные» наборы CASE-инструментов обычно не дают возможности просто и быстро переходить от одной модели системы к другой. Такие переходы должны осуществляться одним нажатием клавиши. Еще лучше, если будет предусмотрена возможность наглядного сопоставления. Окна не очень подходят для этого. К тому времени, как вы откроете два окна в CASE-инструменте, работающем в оконном режиме или среде, на экране уже не останется места, чтобы хорошо рассмотреть что-либо. Или будет виден только небольшой кусочек каждой схемы, или на экране будут отображены маленькие, нечитаемые символы и текст. Вряд ли компьютер может помочь [24] Автор с юмором намекает на аббревиатуру CASE (Computer-Aided Software Engineering). «Aid» (англ.) — помощь, поддержка. в разработке программного обеспечения!

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

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

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

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

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

Следует ли нам оставить надежды и поставить CASE-инструменты на полку? Нет, надежда все же остается. Современные CASE-инструменты — это примитивные предшественники тех инструментов, которые нам действительно нужны. Они еще появятся.

Все это немного напоминает первые программы обработки текстов, такие как Electric Pencil или первые версии WordStar. Согласно сегодняшним стандартам функциональности и удобства, они не выдерживают критики. Пользователю приходилось ждать минуты, чтобы перейти с одного конца документа на другой. Для выполнения элементарных действий требовались непонятные и сложные нажатия клавиш, а средства форматирования были ограниченными. Однако применять эти редакторы было намного'удобнее, чем писать от руки или печатать на машинке, а потом перепечатывать и перепечатывать.