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

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

Технологии поощрения хорошего кодирования

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

Назначьте двух человек на каждую часть проекта щщхщу

Если над каждой строкой кода приходится работать двоим, пщтттшт см. раздел

то у вас есть гарантия, что хотя бы два человека думают, что t\Z

код работает и его можно читать. Механизм работы команды

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

«наставник - стажер» или рецензирования кода методом близнецов.

Рецензируйте каждую строку кода В рецензировании щщщ 0 р, кода обычно участвует программист и минимум два рецен- зированин см. разделы 21.3 зента. Это значит, что каждую строку кода читают не менее щ at Л трех человек. Другое название парного рецензирования - «парное давление» (peer pressure). Кроме предоставления страховки на тот случай, если первоначальный программист покинет проект, рецензирование кода улучшает его качество, так как программист знает, что его код будут читать другие. Даже если у вас нет явных стандартов кодирования, рецензирование позволяет незаметно продвигаться к созданию группового стандарта - в процессе рецензирования группа принимает решения, которые со временем могут стать ее стандартами.

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

Распространяйте для ознакомления хорошие примеры кода Важной составляющей хорошего управления является способность ясно донести свои требования. Для этих целей вы можете распространять хороший код между программистами или выставлять его на всеобщее обозрение. Так вы предоставляете ясный пример того качества, которого вы добиваетесь. Точно так же кодовые стандарты могут состоять главным образом из «листингов отличного кода». Присвоение определенному листингу «знака качества» - пример для подражания. Подобные руководства легче обновлять, чем писаные (словами) стандарты. Кроме того, так легко показать тонкости стиля кодирования, которые тяжело по пунктам описать словами.

Подчеркивайте, что код - это общее имущество щщишилЫтшт

Иногда программисты считают, что код, который они на- часть програмширшйИй сост-писали, - «их» личная собственность. Хотя это результат их ит » сообивнии резрьтатов аа-работы, но он является частью всего проекта и должен быть шей работы шш пщт (т. доступен любому участнику проекта. Он должен просмат- Рвлы 33.5 и 343). риваться другими хотя бы во время рецензирования и сопровождения.



Один из самых успешных проектов, о котором когда-либо сообщалось, был реализован за И лет и состоял из 83 000 строк кода. За первые 13 месяцев эксплуатации была выявлена только одна ошибка, приведшая к системному сбою. Это достижение еще больше ошеломляет, если учитывать, что проект был завершен в конце 19б0-х, без использования онлайн-компиляции и интерактивной отладки. Производительность проекта -7500 строк кода в год в конце 60-х - и по сегодняшним стандартам достаточно впечатляет. Главный программист проекта сообщил, что одним из залогов успеха было признание всех машинных прогонов (ошибочных и нет) общим, а не частным достоянием (Baker and Mills, 1973). Эта идея нашла свое воплощение и в современной ситуации, например, в ПО с открытым исходными кодом (Open Source Software) (Raymond, 2000), экстремальном программировании с его понятием о коллективном владении (Веек, 2000) и во многих других случаях.

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

Награда должна представлять интерес для программиста. (Многим из них поощрения типа «Какой молодец!» неприятны, особенно когда исходят от нетехнических менеджеров.)

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

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

Роль ЭТОЙ книги

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



28.2. Управление конфигурацией

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

Что такое управление конфигурацией?

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

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

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

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

Несмотря на очевидную необходимость управления конфигурацией, многие программисты избегают его десятилетиями. Опрос, проведенный более 20 лет назад, выяснил, что около трети программистов даже не бьши знакомы с этой идеей (Веек and Perkins, 1983), и нет никаких признаков, что это положение изменилось. Более свежее исследование Института Разработки ПО показало, что среди организаций, использующих неформальные методики разработки ПО менее 20% применяют адекватное управление конфигфацией (SEI, 2003).

Управление конфигурацией изобрели не программисты, но поскольку программные проекты чрезвычайно изменчивы, то для них оно особенно полезно. Применительно к программным проектам управление конфигурацией обычно называется «управление конфигурацией ПО» (software configuration management, SCM). SCM сосредотачивается на программных требованиях, исходном коде, документации и тестах.



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