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

Принцип видимости в работе достигает зенита в некоторых специальных моделях командной или групповой работы, предназначенных для проектирования программного обеспечения. В модели под названием «Совместное проектирование приложений» (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 г.

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

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

Тогда в чем же проблема? К сожалению, большинство программистов любят программировать. Некоторые из них могут даже не есть и не мыться, а только заниматься программированием. Большинство из них предпочитают писать код, а не рыться в документации, или искать в каталогах, или разбираться в идиотской работе какого-то тупого программиста. Разработчики программного обеспечения создают продукты, а пользователи их применяют. При прочих равных условиях программисты будут разрабатывать и строить с нуля, а не использовать что-либо повторно. Каждый из них убежден, что сможет написать более короткую и более элегантную программу, чем код его предшественника. В силу своего характера программисты имеют предубеждение против повторного использования, даже если оно может повысить их продуктивность. Как побудить их изменить свои привычки? Внезапно с балкона раздается контрапунктное пение хора: «Премии. Рыночные меры. Поощрительные схемы. Гонорары. Графики поощрений. Изменение культуры». Какая приятная какофония!