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

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

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

Этот же принцип можно применить к процессу обучения. Большинство людей — не все, но большинство — быстрее обучаются в небольших группах, а не самостоятельно. Это относится даже ко многим твердолобым, которые убеждены, что не могут учиться таким способом, или не любят работать в группе. В таком подходе есть множество благоприятных факторов. Обсуждение выявляет темы и идеи, которые никогда бы не пришли в голову одному человеку. Коллеги, общающиеся на равных, зачастую могут объяснить друг другу трудные понятия, если это не может сделать наставник. Новые идеи и точки зрения возникают в самом диалоге. Вероятно, самое главное — это то, что студенты в группах могут учиться друг у друга, а не просто смотреть на учителя или в учебник. Такова одна из причин, по которым на своих семинарах и практических занятиях я почти всегда создаю проектные или учебные группы.

Наверное, это правило особенно подходит для изучения языков программирования. Плоджер заметил, что при изучения языков существует оптимальное количество студентов, которые садятся за один терминал. Это не один студент. Скорее, два. Три тоже подходит, однако в одиночку студент чаще всего изучает язык значительно медленнее, чем в паре в партнером. С другой стороны, четыре и более студентов, сидящих за одним компьютером, всегда мешают друг другу — как в переносном, так и в прямом, физическом смысле. Такие большие группы часто распадаются на более мелкие или начинают применять «разделение машинного времени», что в конечном итоге приводит к снижению эффективности. Поэтому, если вы действительно хотите добавить в свой репертуар язык С++ или Smalltalk, не запирайтесь с руководствами и учебниками, а хватайте своего приятеля-программиста и вместе садитесь за клавиатуру. Знание этого принципа может быть полезным для школ с ограниченным бюджетом, а также для компаний, в которых был расформирован отдел обучения.

Виртуальная видимость

Интересно отметить, что для получения выигрыша от видимости в работе необязательно, чтобы кто-нибудь сказал хоть слово. Большинство из нас сталкивалось со случаем, когда какая-то ошибка никак не находилась. Вы изучили тестовый прогон и листинг. Вы знаете, что проблема скрыта в одном из блоков кода, но сколько бы вы по нему не проходили, вам не удается обнаружить, где собака зарыта. Отчаявшись, вы стучите в дверь соседней комнаты и настойчиво требуете помощи. В конце концов, Шарлотта имеет степень Ph.D в Computer Science. Вы начинаете описывать ей суть проблемы. Как только вы добираетесь до цикла, что-то бросается вам в глаза. Шарлотта еще не успела ничего сказать, а вы тихо восклицаете: «О!» — и начинаете робко выходить за дверь, на ходу бормоча благодарности. «Пожалуйста, в любое время», — слышите вы в ответ.

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