Человеческий фактор в программировании
Добавить в закладки К обложке
- Предисловие - Страница 1
- Предисловие к первому изданию - Страница 3
- IГрупповая разработка - Страница 5
- 2Консенсус и компромисс - Страница 7
- 4Скромный и высокопоставленный писарь - Страница 11
- 5Официальное пространство - Страница 14
- 6Раздражающие прерывания - Страница 17
- IIКовбои и ковгерлы - Страница 19
- 8Возвращение блудного ковбоя - Страница 22
- 9Единство в разнообразии - Страница 25
- 10Кодеры-ковбои и программисты-мудрецы - Страница 28
- IIIОрганизация работы - Страница 33
- 12Методы хаоса - Страница 36
- 13Открытая архитектура - Страница 39
- 14Синхронное плавание - Страница 42
- 15Командная политика - Страница 45
- 16Все сразу - Страница 47
- 17Заговор упрямцев - Страница 49
- IVИнструменты, модели и методы - Страница 51
- 19Вопросы моделирования - Страница 54
- 20Свет мой, зеркальце - Страница 56
- 21Методичное сумасшествие - Страница 58
- 22Говоря по существу - Страница 60
- 23Будущие формы - Страница 63
- 24Цели программного обеспечения - Страница 66
- 25Шито белыми нитками - Страница 69
- VСовершенствование процесса - Страница 73
- 27Повторение и вознаграждение - Страница 76
- 28Суперобучение - Страница 79
- 29Вверх по водопаду - Страница 81
- 30Своевременная поставка - Страница 83
- 31Под давлением - Страница 85
- 32Re: Архитектура - Страница 87
- 33Пошаговое улучшение качества - Страница 89
- VIЮзабилити программного обеспечения - Страница 95
- 35Сложность и прогрессирующий функционизм - Страница 98
- 36Назад к истокам - Страница 101
- 37Цветной язык - Страница 104
- 38Совершенствующиеся середнячки - Страница 107
- 39Пригодны ли вы - Страница 110
- 40Редактирование интерфейсов - Страница 113
- 41Сервис - Страница 115
- VIIУдобные объекты - Страница 117
- 43Глубокое понимание - Страница 121
- 44Абстрактные объекты - Страница 125
- 45Новая среда - Страница 128
- 46Полезные ситуации - Страница 132
- 47Эффективные объекты - Страница 136
- 48Связанные объекты - Страница 140
- VIIIЭто превосходное новое программное обеспечение - Страница 143
- 50Интерфейсы разнообразные - Страница 146
- 51Мастеры - Страница 148
- 52Образы будущего - Страница 150
- IXКультура и качество - Страница 152
- 54Агенты изменения - Страница 154
- 55Встроено самое лучшее - Страница 156
- 56Заметки из итальянского ресторана - Страница 159
- 57Наставничество - Страница 162
- 58На обучение - Страница 164
- 59Одаренные программисты - Страница 166
- 60Иконы отрасли - Страница 168
- 61Импресарио - Страница 170
- Приложение - Страница 172
- Библиография - Страница 174
4Скромный и высокопоставленный писарь
Помните, как Боб Крэтчит (Bob Cratchit) трудился над книгами в солидной фирме Скруджа (Scrooge) и Марли (Marley), надев на руки перчатки без пальцев, чтобы они не замерзали, пока Боб перелистывал страницы? Я очень люблю «Рождественский гимн» (A Christmas Carol). Недавно мне подарили видеокассету с изумительной черно-белой экранизацией, где главную роль играет Алистэр Сим (Alistair Sim). Посмотрев этот фильм, я задумался о старом Бобе и других «клерках», которые на протяжении столетий вели учетные книги для множества предприятий. Эти писари были настоящими компьютерами своего времени. Без них предприятия пришли бы к банкротству, а целые отрасли были бы ввергнуты в хаос. Их реальная власть и влияние намного превосходили их скудные жалования или невысокий статус. Вообще говоря, продолжительный успех Скруджа и Марли был в большей мере связан с работой старого доброго Боба и его соотечественников, чем с тем, что привнес Эбенезер.
Сегодня вряд ли что-то изменилось. Сотрудники, которые ведут учетные книги, по-прежнему ценятся невысоко. Но в их карандашах, маркерах и клавиатурах может скрываться сила, предопределяющая успех или провал разработки программного обеспечения.
Если группы по разработке программного обеспечения ведут какие-то записи, то в архивах и заметках отражаются только результаты и выводы, рабочие продукты или готовые компоненты. Программисты особенно не любят записывать что-нибудь кроме самого кода, если только перед ними не стоит угроза штрафа или тюремного заключения. Заставить их нари-совать диаграммы — это все равно, что заставить слона сделать наброски карандашом. В конце концов, разве не является хороший код самодокументируемым?
Жизненно важная статистикаТакое отношение приводит к потере жизненно важной информации. Вообще говоря, когда сохраняется только конечный продукт, нам известен результат, но мы не знаем, как его получили. Как создавалось программное обеспечение, какие решения были найдены в процессе работы — все это является важным. Можем ли мы полагаться на свою память? Беспокоимся ли мы только об ошибках или вдобавок хотим извлечь из них пользу?
Особые трудности в работе групп, сохраняющих только конечный программный продукт, вызывает отсутствие записей о решениях, от которых отказались. Знать о том, какие методы были отклонены и по каким причинам, часто бывает так же важно, как и о том, какие методы были выбраны. Это жизненно важно в тех случаях, когда готовятся новые версии или системы или когда разработка текущей системы заходит в тупик.
Наверное, вы когда-нибудь рассматривали свой код, написанный несколько месяцев или лет назад. Случалось ли так, что вы находили такие места, которые казались неверными, и вы удивлялись, как же программа вообще могла работать? Если вы поддавались соблазну «исправить» эту скрытую ошибку, как это иногда делал и я, то могли обнаружить, что «исправление» загоняло систему «в угол». Естественно, код только казался неправильным, но сам по себе он не объяснял, почему здесь все в порядке. Не помогут и такие комментарии в коде: «Ничего здесь не меняйте. Это место кажется неверным, но здесь все правильно». Если программист знал, что «здесь все правильно» и почему другой вариант будет неверным, то почему же тогда эта логика не отражена в комментарии? Если мы хотим поддерживать систему не один год или иметь возможность выпустить следующую версию через пять лет после того, как все разработчики первой версии системы будут далеко, нам нужно знать, какие варианты рассматривались, какие были отклонены и почему.
Сегодня бизнес-консультанты говорят об организационном обучении как о ключе к долговременному успеху предприятия. Организации, как и люди, могут учиться на своем опыте, накапливая знания и улучшая свою производительность. Если в организационное обучение вовлечены только отдельные сотрудники, то такая организация становится уязвимой. Работники болеют, уходят в отпуск, меняют работу. В конце концов, они забывают.
В действительности знания организации содержатся в ее архивах, в ее стратегии, в ее правилах и процессах, а не только в ее работниках. Чем больше мы документируем и ведем записи о происходящем, тем более вероятно, что эти знания переживут группу или команду, создавшую их.
КаракулиВходит скромный писарь. Звучат фанфары и приветствия!
В команде, разрабатывающей программное обеспечение, писарь или протоколист отвечает за коллективную память команды, в которой хранятся как рабочие продукты, так и описание процессов, давших результаты. Писарь ведет учетные книги. В модели командной работы с открытой структурой (Structured Open teamwork), которую независимо друг от друга разработали Роб Томсет (Rob Thomsett, 1990 [62]) и я (Constantine, 1989 [11], 1991 [13]), такая роль была обозначена как «информационный менеджер». Этот термин был введен для того, чтобы повысить статус этой роли, подобно тому как в объявлениях о вакансиях вместо «водитель мусоровоза» пишут «инженер санитарно-гигиенического транспорта».
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 66
- 67
- 68
- 69
- 70
- 71
- 72
- 73
- 74
- 75
- 76
- 77
- 78
- 79
- 80
- 81
- 82
- 83
- 84
- 85
- 86
- 87
- 88
- 89
- 90
- 91
- 92
- 93
- 94
- 95
- 96
- 97
- 98
- 99
- 100
- 101
- 102
- 103
- 104
- 105
- 106
- 107
- 108
- 109
- 110
- 111
- 112
- 113
- 114
- 115
- 116
- 117
- 118
- 119
- 120
- 121
- 122
- 123
- 124
- 125
- 126
- 127
- 128
- 129
- 130
- 131
- 132
- 133
- 134
- 135
- 136
- 137
- 138
- 139
- 140
- 141
- 142
- 143
- 144
- 145
- 146
- 147
- 148
- 149
- 150
- 151
- 152
- 153
- 154
- 155
- 156
- 157
- 158
- 159
- 160
- 161
- 162
- 163
- 164
- 165
- 166
- 167
- 168
- 169
- 170
- 171
- 172
- 173
- 174
- 175
- 176
В конце февраля 2009 года в продаже на Amazon появил
Электронная читалка - вещь очень хрупкая. Если с ней обращаться не правильно - она может сломаться. Чтобы этого не случилось, нужно придерживаться лиш
Большинство книг в сети интернет распространяется в формате FB2 (Fiction Book). Этот формат очень удобен для чтения. Файлы, в нем созданные, отличаютс
Популярность электронных книг у читателей неуклонно растет. Для доказательства этого мы провели маленький эксперимент. Из 10 людей, читающих в метро,
Файлы формата FB2 часто можно увидеть среди огромнейшего разнообразия текстовых форматов. Такая высокая популярность объясняется его предназначением.
Первую версию формата PDF (Portable Document Format) еще в 1993 году разработала фирма Adobe Systems. В 2006 году она уже разработала версию 1.7, а с
Фирма Apple порадовала пользователей iPad, выпустив под него красивую и удобную читалку iBooks.