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

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

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

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

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

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

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