Главная - Литература

0 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 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294

которые вещи. Второй: уделяйте внимание проблемам, с которыми сталкиваетесь. Поработав над несколькими крупными программами, вы прекрасно поймете пользу заблаговременного планирования. Положитесь на свой опыт.

Наконец, еще одна причина пренебрежения подготовкой к конструированию состоит в том, что менеджеры прохладно относятся к программистам, которые тратят на это время. Это довольно странно: такие люди, как Барри Бом (Barry Boehm), Гради Буч (Grady Booch) и Карл Вигерс (Karl Wiegers), отстаивают важность выработки требований и проектирования уже 25 лет, и менеджеры, казалось бы, уже должны понимать, что разработка ПО не ограничивается кодированием, но...

Несколько лет назад я работал над проектом Минобороны,

ттШ зту как-то на этапе выработки требований нас посетил кура-тему е«1. IS шсшешц труде Р проекта - генерал. Мы сказали ему, что работаем над Джераящ бШбера *Tlie Psy- требованиями: большей частью общаемся с клиентами, chology of Computer Program- определяем их потребности и разрабатываем проект при-ming* (Weinberg, ложения. Он, однако, настаивал на том, чтобы увидеть код.

Мы сказали, что у нас нет кода, и тогда он отправился в рабочий отдел, намереваясь хоть кого-нибудь из 100 человек поймать за программированием. Огорченный тем, что почти все из них находились не за своими компьютерами, этот крупный человек наконец указал на инженера рядом со мной и проревел: «А он что делает? Он ведь пишет код!» Вообще-то этот инженер работал над утилитой форматирования документов, но генерал хотел увидеть код, нашел что-то похожее на него и хотел, чтобы хоть кто-то писал код, так что мы сказали ему, что он прав: это код.

Этот феномен известен как синдром WISCA или WIMP: «Why Isnt Sam Coding Anything? (Почему Сэм не пишет код?)» или «Why Isnt Mary Programming (Почему Мэри не программирует)?»

Если менеджер проекта претендует на роль бригадного генерала и приказывает вам немедленно начать программировать, вы можете с легкостью ответить: «Есть, сэр!» (И впрямь, какое вам дело? Умудренные опытом ветераны должны отвечать за свои слова.) Это плохой ответ, и у вас есть несколько лучших вариантов. Во-первых, вы можете решительно отвергнуть неэффективную методику работы. Если у вас нормальные отношения с начальником и все в порядке с банковским счетом, это может сработать.

Во-вторых, вы можете притвориться, что работаете над кодом. Разложите на столе листинги старой программы и продолжайте работать над требованиями и архитектурой как ни в чем не бывало. Так вы выполните проект быстрее и качественнее. Порой этот подход находят неэтичным, но начальник-то останется доволен!

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

Наконец, вы можете найти другую работу. Независимо от экономических подъемов и спадов хороших программистов всегда не хватает (BLS, 2002), а жизнь слишком коротка, чтобы тратить ее на работу в отсталом учреждении при наличии множества лучших вариантов.



Самый веский аргумент в пользу выполнения предварительных условий перед началом конструирования

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

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

Обращение к логике

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

До начала создания системы не менее важно подумать и о том, как вы собираетесь ее создавать. Никому не хочется тратить время и деньги на бесплодные блуждания по лабиринту.

Обращение к аналогии

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

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

Программисты - последнее звено пищевой цепи разработки ПО. Архитекторы поглощают требования, проектировщики потребляют архитектуру, а программисты - проект приложения.

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



Если среда загрязнена, жучки плавают в ядерных отходах, а рыба плещется в нефтяных пятнах. Чайкам не повезло больше всего: находясь в конце пищевой цепи, они травятся и нефтью, и ядерными отходами. Если ваши требования неудачны, они отравляют архитектуру, которая в свою очередь травит процесс конструирования. Результат? Раздражительные программисты и полное изъянов ПО.

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

Обращение к данным

Исследования последних 25 лет убедительно доказали выгоду правильного выполнения проектов с первого раза и дороговизну внесения изменений, которых можно было избежать.

Ученые из компаний Hewlett-Packard, IBM, Hughes Aircraft, TRW и других организаций обнаружили, что исправление ошибки к началу конструирования обходится в 10-100 раз дешевле, чем ее устранение в конце работы над проектом, во время тестирования приложения или после его выпуска (Pagan, 1976; Humphrey, Snyder, and Willis, 1991; Leffingwell 1997; Willis et al., 1998; Grady 1999; Shull et al, 2002; Boehm and Turner, 2004).

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

Вот данные об относительной дороговизне исправления дефектов в зависимости от этапов их внесения и обнаружения (табл. 3-1):



0 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 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294



0.0101