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

Как и все руководства для построения лучших систем, «принцип видимости в работе» может завести слишком далеко. Одной из форм «доведения до абсурда» (или «расширения» до него?) является модель программирования, к которой прибегают некоторые крупные производители программного обеспечения. Этот подход можно назвать «подходом стаи дворняг». Просто соберите много-много программистов и поместите их в большую комнату — некую «арену для быков», заполненную столами и терминалами. Обеспечьте их всем необходимым для доступа к онлайновым базам данных и электронным рассылкам, чтобы все могли читать информацию и обмениваться мнениями. Все мы знаем, к чему приводят такие подходы.

В большинстве ситуаций преимущества видимости существенно возрастают, если к процессу подключается второй человек, однако с каждым новым человеком отдача снижается. Конечно, бывают и исключения из правил, особенно на самых первых или самых последних стадиях разработки системы. Метод мозгового штурма лучше работает при большом количестве мозгов, способных пробудить этот шторм.[35] Небольшие группы смогут создать только пылевой вихрь или могут просто сесть и посидеть спокойно. В разборе кода и анализе дизайнерских проектов также полезно участие нескольких критиков. Чем больше людей просмотрит работу, тем с большей вероятностью могут быть обнаружены ошибки и упущения. С другой стороны, в реальных задачах, связанных с поиском хорошей архитектуры программного обеспечения при наличии сложных взаимосвязанных ограничений, участие слишком большого количества умов зачастую приводит к взаимным стычкам. Вероятно, в качестве оптимального значения здесь подойдет известное правило «7 ± 2».

Видимость структуры

Принцип видимости в работе достигает зенита в некоторых специальных моделях командной или групповой работы, предназначенных для проектирования программного обеспечения. В модели под названием «Совместное проектирование приложений» (Joint Application Design, JAD) (Wood и Silver, 1989 [69]) группа конечных пользователей и разработчиков проводят анализ требований и выполняют высокоуровневое проектирование с помощью высокоструктурированного процесса обсуждения. Видимость процесса для пользователей и возможность активно вносить свой вклад приводят к созданию превосходных систем и улучшению взаимопонимания между пользователями и разработчиками.

Так называемая «структурно-открытая» команда, описанная в главе 16 (Constantine, 1989 [11]; Thomsett 1990 [62]), является другой моделью, в которой принцип видимости применяется для улучшения качества системы и, в конечном итоге, эффективности разработки. На протяжении всего рабочего цикла участники такой команды проектирования большую часть своей работы выполняют в присутствии друг друга. Марк Ре-тиг (Marc Rettig, 1990 [60]) сообщает, что одна успешная команда тратила половину своего рабочего дня на общие собрания. Конечно, это были не просто приятные встречи, а рабочие сессии. Их цель заключалась не в том, чтобы обсудить черновики или похвалить друг друга за успехи, а в том, чтобы заниматься работой. При «структурно-открытой» командной работе члены группы анализируют задачи, модули и даже разрабатывают детали кода. Такие рабочие сессии проводятся под руководством одного из членов команды, что позволяет сделать их более эффективными и плодотворными. Но самую главную роль здесь играет видимость, которая достигается за счет открытости процесса разработки.

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

Помните, Программист Скрытный — это исчезающий вид. Из журнала Computer Language Magazine, том 9, № 2,1992 г.

27 Повторение и вознаграждение

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

Старые проблемы