Читать онлайн «Человеческий фактор в программировании». Страница 7

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

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

Из журнала Computer Language Magazine, том 9, № 5, май 1992 г.

Помните, как Боб Крэтчит (Bob Cratchit) трудился над книгами в солидной фирме Скруджа (Scrooge) и Марли (Marley), надев на руки перчатки без пальцев, чтобы они не замерзали, пока Боб перелистывал страницы? Я очень люблю «Рождественский гимн» (A Christmas Carol). Недавно мне подарили видеокассету с изумительной черно-белой экранизацией, где главную роль играет Алистэр Сим (Alistair Sim). Посмотрев этот фильм, я задумался о старом Бобе и других «клерках», которые на протяжении столетий вели учетные книги для множества предприятий. Эти писари были настоящими компьютерами своего времени. Без них предприятия пришли бы к банкротству, а целые отрасли были бы ввергнуты в хаос. Их реальная власть и влияние намного превосходили их скудные жалования или невысокий статус. Вообще говоря, продолжительный успех Скруджа и Марли был в большей мере связан с работой старого доброго Боба и его соотечественников, чем с тем, что привнес Эбенезер.

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

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

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

Особые трудности в работе групп, сохраняющих только конечный программный продукт, вызывает отсутствие записей о решениях, от которых отказались. Знать о том, какие методы были отклонены и по каким причинам, часто бывает так же важно, как и о том, какие методы были выбраны. Это жизненно важно в тех случаях, когда готовятся новые версии или системы или когда разработка текущей системы заходит в тупик.

Наверное, вы когда-нибудь рассматривали свой код, написанный несколько месяцев или лет назад. Случалось ли так, что вы находили такие места, которые казались неверными, и вы удивлялись, как же программа вообще могла работать? Если вы поддавались соблазну «исправить» эту скрытую ошибку, как это иногда делал и я, то могли обнаружить, что «исправление» загоняло систему «в угол». Естественно, код только казался неправильным, но сам по себе он не объяснял, почему здесь все в порядке. Не помогут и такие комментарии в коде: «Ничего здесь не меняйте. Это место кажется неверным, но здесь все правильно». Если программист знал, что «здесь все правильно» и почему другой вариант будет неверным, то почему же тогда эта логика не отражена в комментарии? Если мы хотим поддерживать систему не один год или иметь возможность выпустить следующую версию через пять лет после того, как все разработчики первой версии системы будут далеко, нам нужно знать, какие варианты рассматривались, какие были отклонены и почему.

Сегодня бизнес-консультанты говорят об организационном обучении как о ключе к долговременному успеху предприятия. Организации, как и люди, могут учиться на своем опыте, накапливая знания и улучшая свою производительность. Если в организационное обучение вовлечены только отдельные сотрудники, то такая организация становится уязвимой. Работники болеют, уходят в отпуск, меняют работу. В конце концов, они забывают.

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

Входит скромный писарь. Звучат фанфары и приветствия!

В команде, разрабатывающей программное обеспечение, писарь или протоколист отвечает за коллективную память команды, в которой хранятся как рабочие продукты, так и описание процессов, давших результаты. Писарь ведет учетные книги. В модели командной работы с открытой структурой (Structured Open teamwork), которую независимо друг от друга разработали Роб Томсет (Rob Thomsett, 1990 [62]) и я (Constantine, 1989 [11], 1991 [13]), такая роль была обозначена как «информационный менеджер». Этот термин был введен для того, чтобы повысить статус этой роли, подобно тому как в объявлениях о вакансиях вместо «водитель мусоровоза» пишут «инженер санитарно-гигиенического транспорта».

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