Читаем Человеческий фактор в программировании полностью

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

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

Создание эскизов

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

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

Альтернативы и альтернативные точки зрения

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

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

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

Перейти на страницу:

Похожие книги

Основы программирования в Linux
Основы программирования в Linux

В четвертом издании популярного руководства даны основы программирования в операционной системе Linux. Рассмотрены: использование библиотек C/C++ и стан­дартных средств разработки, организация системных вызовов, файловый ввод/вывод, взаимодействие процессов, программирование средствами командной оболочки, создание графических пользовательских интерфейсов с помощью инструментальных средств GTK+ или Qt, применение сокетов и др. Описана компиляция программ, их компоновка c библиотеками и работа с терминальным вводом/выводом. Даны приемы написания приложений в средах GNOME® и KDE®, хранения данных с использованием СУБД MySQL® и отладки программ. Книга хорошо структурирована, что делает обучение легким и быстрым. Для начинающих Linux-программистов

Нейл Мэтью , Ричард Стоунс , Татьяна Коротяева

ОС и Сети / Программирование / Книги по IT
97 этюдов для архитекторов программных систем
97 этюдов для архитекторов программных систем

Успешная карьера архитектора программного обеспечения требует хорошего владения как технической, так и деловой сторонами вопросов, связанных с проектированием архитектуры. В этой необычной книге ведущие архитекторы ПО со всего света обсуждают важные принципы разработки, выходящие далеко за пределы чисто технических вопросов.?Архитектор ПО выполняет роль посредника между командой разработчиков и бизнес-руководством компании, поэтому чтобы добиться успеха в этой профессии, необходимо не только овладеть различными технологиями, но и обеспечить работу над проектом в соответствии с бизнес-целями. В книге более 50 архитекторов рассказывают о том, что считают самым важным в своей работе, дают советы, как организовать общение с другими участниками проекта, как снизить сложность архитектуры, как оказывать поддержку разработчикам. Они щедро делятся множеством полезных идей и приемов, которые вынесли из своего многолетнего опыта. Авторы надеются, что книга станет источником вдохновения и руководством к действию для многих профессиональных программистов.

Билл де Ора , Майкл Хайгард , Нил Форд

Программирование, программы, базы данных / Базы данных / Программирование / Книги по IT
Программист-прагматик. Путь от подмастерья к мастеру
Программист-прагматик. Путь от подмастерья к мастеру

Находясь на переднем крае программирования, книга "Программист-прагматик. Путь от подмастерья к мастеру" абстрагируется от всевозрастающей специализации и технических тонкостей разработки программ на современном уровне, чтобы исследовать суть процесса – требования к работоспособной и поддерживаемой программе, приводящей пользователей в восторг. Книга охватывает различные темы – от личной ответственности и карьерного роста до архитектурных методик, придающих программам гибкость и простоту в адаптации и повторном использовании.Прочитав эту книгу, вы научитесь:Бороться с недостатками программного обеспечения;Избегать ловушек, связанных с дублированием знания;Создавать гибкие, динамичные и адаптируемые программы;Избегать программирования в расчете на совпадение;Защищать вашу программу при помощи контрактов, утверждений и исключений;Собирать реальные требования;Осуществлять безжалостное и эффективное тестирование;Приводить в восторг ваших пользователей;Формировать команды из программистов-прагматиков и с помощью автоматизации делать ваши разработки более точными.

А. Алексашин , Дэвид Томас , Эндрю Хант

Программирование / Книги по IT

Все жанры