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

Из журнала Object Magazine, декабрь, 1997 г.

Помню, как я писал свою первую программу. Это было упражнение по Фортрану в рамках курса, известного под названием 6.41. В те дни в Мас-сачусетском технологическом институте все шло под своими номерами, в том числе и моя программа. Написать ее не составило труда — она всего лишь не скомпилировалась с первого раза. Или со второго. Я был подавлен и опустошен. Когда мне все-таки удалось ее скомпилировать, я был просто шокирован тем, что она не работала. Я не мог понять, почему — мне казалось, что все написано правильно. Я показал ее своему соседу по комнате. Маршалл специализировался на математике. Я думаю, что он начал писать алгоритмы еще до появления компьютеров, на которых их можно было применять.

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

«А это что?» — спрашивал Маршалл, тыча своим корявым бруклинским пальцем.

«Похоже, что С.»

«Здесь это не нужно.» И он был прав. Этот оператор компилировался, однако компьютер прочитывал его не так, как я предполагал. Маршалл возвращался к чему-то, связанному с градиентами и операторами Гамильтона, и оттачивал свою интерпретацию песни Марлона Брандо (Marlon Brando) из «А Streetcar Named Desire». Из всего этого я уяснил, что Маршаллу никогда нельзя показывать то, что я написал, особенно если это код. Он всегда найдет в нем что-нибудь неправильное, а мне придется на-ходить в себе силы, чтобы отнестись к этому, как к одолжению. Кроме того, это неизменно вызывало у него очередной приступ музыкального мычания: «Стелла! Стелла!». Скоро начало занятий, а я все еще не был готов. Конечно, со временем я понял, что обсуждение проблемы с приятелем-программистом часто оказывается самым эффективным способом обнаружения какого-нибудь незаметного бага или составления какого-нибудь мудреного алгоритма. На самом деле многие из нас знают, что изложение своих идей коллеге, играющему роль «звукового экрана», или выяснение его мнения по поводу чего-то неясного может быть не только полезной и ценной процедурой для конечного продукта, но и веселым занятием, помогающим построить хорошие рабочие отношения.

П. Дж. Плоджеру (P. J. Plauger) все же пришлось потратить силы, чтобы научить меня пользоваться преимуществами видимости. Вскоре после того как он создал компанию Whitesmith, Ltd., я стал приходить в его нью-йоркскую «штаб-квартиру» — небольшую квартиру на Манхэттене. В углу одной из комнат стоял мини-компьютер, принтер был засунут в шкаф, чтобы не было шума, а по всей комнате, которая считалась «гостиной», были расставлены несколько терминалов. И за каждым терминалом находилось по два программиста!

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

Я предположил, что недостаток оборудования связан с нехваткой денежных средств, но Плоджер заверил меня, что на самом деле это был особый режим работы. Довольно неэффективный режим, да? Нет. Приняв такой подход, они стали производить законченный и протестированный код быстрее, чем когда-либо. При близком рассмотрении становится понятно, почему. Код, который выходил из этих терминалов-с-двумя-программис-тами, был почти на 100 % свободен от багов. Программа не только содержала меньше ошибок, но и была более рациональной, краткой и эффек-тивной благодаря тому, что над ее созданием работали две светлых головы, а также благодаря ценному диалогу, происходящему между сидящими за терминалом напарниками. Такую модель работы я стал называть «динамическим дуэтом». Принцип, который здесь работает, довольно ясен: увеличение рабочей видимости приводит к увеличению качества! Два программиста, работающие в тандеме, — это не излишество, а прямой путь к большей эффективности и лучшему качеству. (Об этом знают те, кто занимается ХР (extreme programming, экстремальное программирование.)