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

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

желание ясно понять программу и отказ от компиляции кода с той лишь целью, чтобы узнать, работает ли он;

предоставление реалистичных отчетов о статусе проекта;

предоставление реалистичных оценок срока выполнения проекта и отстаивание своей позиции, даже если руководители просят адаптировать оценку.

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

Оценивайте степень своей уверенности в тех или иных суждениях. Если вы обычно уверены в них на 100%, это предупреждающий знак.

Отказ от признания ошибок - особенно вредная привычка. „ ,

к Яюбой дурак шюсобенотаайвагь

Если Салли отказывается признать ошибку, она, очевидно, своя ошиб10« - большинство ду-

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

ку допустила Салли. Ошибки - естественный результат подъ- фШ CBmQie)

емов и спадов сложных интеллектуальных процессов, и если Салли не была небрежной, никто не будет ее ни в чем упрекать.

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

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

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



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

Оценка статуса проекта - один из главных источников лжи На первые 90% кода приходят- j

ся первые 90% еремеии разра- нашей работе. Программисты печально известны своими ботки. На оставшиеся 10% кода заявлениями, согласно которым на протяжении всей второй приходятся другие 90% щьш- половины проекта программа неизменно «готова на 90%». ни разработки. Yqrw вы плохо представляете ход работы над проектом, по-

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

С сообщением неверного статуса проекта связана неверная Шр: сс2е.сот/3341 оценка сроков выполнения проекта. Типичный сценарий

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

К сожалению, Берт не учел, что оценка не может являться предметом переговоров. Он может пересмотреть оценку и сделать ее более точной, но переговоры с руководителем не повлияют на время, необходимое для реализации проекта. Билл Ваймер из IBM однажды заявил: «Мы обнаружили, что технические специалисты в целом очень точно оценивали требования, предъявляемые к проектам, и сроки их реализации. Но они не могли защитить свои решения - им нужно научиться отстаивать свое мнение» (Weimer в Metzger and Boddie, 1996). Пообещав выполнить проект за четыре месяца и выполнив за шесть, Берт едва ли обрадует своего руководителя сильнее, чем пообещав выполнить проект за шесть месяцев и сдержав свое слово. Не сдержав обещания, Берт потеряет доверие, а отстаивая свою позицию, лишь заслужит уважение.

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



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

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

Абсолютное заблуждение! Начальство отвечает за управление компанией в целом. Если какая-то функция программы обойдется компании в 250 ООО долларов, а вы оцените ее в 750 ООО, разрабатывать программу не следует. Принимать такие решения должны руководители. Когда лектор отстаивал недооценку проекта, он отстаивал скрытое воровство власти у руководителей. Если вы считаете, что проект интересен, открывает перед компанией новые возможности или позволяет многому научиться, так и скажите. Руководители тоже способны взвесить эти факторы. Но подталкивание их к неверным решениям может стоить компании сотен тысяч долларов. Если из-за этого вы лишитесь работы, пеняйте на себя.

33.5. Общение и сотрудничество

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

33.6. Творчество и дисциплина

Закончив институт, я считал себя лучшим программистом в мире. Я мог разработать непобедьшый алгоритм игры в крестики-нолики, владел пятью разными языками и мог писать программы из 1000 строк, которые РАБОТАЛИ (в самом деле!). Затем я очутился в Реальном Мире. Первая моя задача в Реальном Мире требовала, чтобы я разобрался в программе из 200 ООО строк, написанной на Фортране, и ускорил ее в два раза. Любой Реальный Программист скажет вам, что никакие методики Структурного Кодирования никогда не помогут решить подобную проблему - для этого требуется настоящий талант.

Эд Пост (Ed Post)



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.009