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

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

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

Хорошо известен недорогой способ получить ответы на эти вопросы - экспериментальное прототипирование. В слово «прототипирование» люди вкладывают разный смысл (McConnell, 1996). В данном контексте оно означает написание абсолютно минимального объема подлежащего выбрасыванию кода, нужного для ответа на отдельный вопрос проектирования.

Если разработчики недисциплинированно относятся к написанию абсолютно минимального объема кода, нужного для ответа на вопрос, прототипирование работает плохо. Допустим, вопрос проектирования таков: «Может ли выбранная нами организация базы данных поддерживать нужный объем транзакций?» Для ответа не нужно писать полноценный код, который можно было бы использовать в готовой системе. Вы можете даже не знать специфику базы данных. Вам лишь нужна информация, достаточная для аппроксимации проблемной области: число таблиц, число элементов в таблицах и т. д. Далее вы можете написать простой прототипный код, использующий таблицы и столбцы с именами вроде Table!, Table2 и Columnl, Со1итп2, заполнить таблицы фиктивными данными и протестировать производительность.

Прототипирование также работает плохо, если задача недостаточно конкретна. Вопрос «Будет ли эта организация базы данных работать?» недостаточно хорошо определяет направление прототипирования. В то же время вопрос «Будет ли эта организация базы данных поддерживать 1000 транзакций в секунду при условиях X, Y и Z?» предоставляет более прочную основу для прототипирования.

Наконец, еще один фактор риска возникает, если разработчики не рассматривают код как подлежащий выбрасыванию. Я обнаружил, что люди не могут написать абсолютно минимальный объем кода, нужный для ответа на вопрос, если думают, что код в конечном счете войдет в итоговую версию системы. Из-за этого они вместо прототипирования занимаются реализацией системы. Настроившись на то, что, как только ответ на вопрос будет получен, код будет выброшен, вы сведете этот риск к минимуму Избежать этой проблемы можно, если создавать прототипы и основную программу используя разные технологии. Вы можете создать прототип проекта Java на языке Python или смоделировать пользовательский интерфейс в Microsoft PowerPoint. Если вы все-таки создаете прототипы, используя ту же технологию, пусть имена прототипичных классов и пакетов начинаются с префикса prototype. Это хотя бы заставит программиста дважды подумать, прежде чем он решит расширять прототипный код (Stephens, 2003). При дисциплинированном применении прототипирование - эффективный способ борьбы с «грязнотой» проектирования. В противном случае оно делает проектирование еще более грязным.



Совместное проектирование

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

вы подходите к столу коллеги и просите его обсудить с вами некоторые идеи;

вы с коллегой идете в конференц-зал и рисуете на доске варианты проекта;

вы с коллегой садитесь перед клавиатурой и выполняете детальное проектирование на выбранном языке программирования, т. е. вы можете использовать парное программирование (см. главу 21);

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

вы назначаете формальную инспекцию, включающую все аспекты, описанные в главе 21;

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

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

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

Какую степень проектирования считать достаточной?

мы пытаемся решш проблему, "" "Р " кодирования создается только самый

максимально ускоряя процесс общий набросок архитектуры. В других случаях группы

проектирования, чтобы в конце создают проекты с таким уровнем подробностей, что коди-

работы над системой у нас ос- рование становится практически механическим занятием,

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

ных из-за слишком быстрого

проектирования. Родственный вопрос заключается в том, насколько формаль-

Глеифорд Майерс ным делать проект. Нужны ли вам формальные, тщательно

(Glenford Myers) выполненные диаграммы проекта системы или цифровых снимков нескольких рисунков на доске будет достаточно?

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



Табл. 5-2. Необходимые уровни формальности и детальности проекта

Уровень детальности проекта, нужный перед началом

Уровень формальности

Фактор

конструирования

документации

Члены группы проектирования/

Низкий

Низкий

конструирования имеют большой

опыт работы в прикладной области.

Члены группы проектирования/

Средний

Средний

конструирования имеют большой

опыт, но плохо знакомы

с прикладной областью.

Члены группы проектирования/

Средний - высокий

Низкий -

средний

конструирования неопытны.

Для группы проектирования/конст-

Средний

руирования характерен средний -

высокий уровень текучести.

От приложения будет зависеть

Высокий

Высокий

безопасность людей.

Приложение предназначено

Средний

Средний -

- высокий

для решения ответственных задач.

Проект небольшой.

Низкий

Низкий

Проект крупный.

Средний

Средний

Предполагается, что ПО будет

Низкий

Низкий

использоваться недолго

(недели или месяцы).

Предполагается, что ПО будет

Средний

Средний

использоваться длительное

время (месяцы или годы).

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

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

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



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