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

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

Ключевые моменты

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

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

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

Установите в настройках компилятора самый строгий уровень диагностики и устраняйте причины всех ошибок и предупреждений. Как вы исправите неуловимые ошибки, если будете игнорировать явные?

Инструменты отладки значительно облегчают разработку ПО. Найдите их и используйте, но не забывайте, что у вас есть еще и голова.



ГЛАВА 24

Рефакторинг

Содержание

24.1. Виды эволюции ПО

24.2. Введение в рефакторинг

24.3. Отдельные виды рефакторинга

24.4. Безопасный рефакторинг

24.5. Стратегии рефакторинга

Связанные темы

Советы по устранению дефектов: раздел 23.3

Подход к оптимизации кода: раздел 25.6

Проектирование при конструировании: глава 5

Классы: глава 6

Высококачественные методы: глава 7

Совместное конструирование: глава 21

Тестирование, выполняемое разработчиками: глава 22

Области вероятных изменений: подраздел «Определите области вероятных изменений» раздела 5.3

Миф: в начале реализации программного проекта проводит- удачные программы mm-ся методичная выработка требований, и составляется устой- няются. чивый список аспектов ответственности программы. Про- ВтШ$)

ектирование соответствует требованиям и выполняется со

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

Реальность: во время разработки первоначальной версии системы в код вносятся значительные изменения. Многие из изменений во время кодирования не менее масштабны, чем изменения, характерные для стадии сопровождения программы. В зависимости от размера проекта кодирование, отладка и блочное тестирование обычно составляют от 30 до 65% общего объема



работы над проектом (см. главу 27). Если бы кодирование и блочное тестирование бьши линейными однократными процессами, они составляли бы не более 20-30% общего объема работы. Однако даже в хорошо управляемых проектах требования изменяются примерно на 1-4% в месяц (Jones, 2000). Изменения требований неизбежно приводят к изменениям кода, порой весьма существенным.

Другая реальность: современные методики разработки предполагают больший масштаб изменений кода во время конструирования. Целью более старых методик (достигалась она или нет - другой вопрос) было предотвращение изменений кода. Современные подходы снижают предсказуемость кодирования. Они в большей степени ориентированы на код, поэтому вы вполне можете ожидать, что на протяжении жизненного цикла проекта код будет изменяться сильнее, чем когда бы то ни было.

24.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.0025