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

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

Я ттт т встречай чеяове- ДРУГой стороны, иногда я имею дело с проектами, страна, желающего читать 17 ООО дающими от слишком объемной проектной документации, щтщ !тщшш% а если Здесь вступает в игру своеобразный закон Грешема, и «ме-бы встретил, то убил бы его, ханические действия начинают вытеснять творчество» чтобы он не портил генофонд, (Simon, 1965). Чрезмерное внимание к созданию проектной Дш0зеф Кттето документации - хорошее подтверждение этого закона. Я бы {Joseph Costelto) предпочел, чтобы разработчики тратили 80% усилий на разработку и анализ различных вариантов проектирования и 20% - на создание менее изысканной документации, а не наоборот: 20% - на создание посредственных решений и 80% - на совершенствование документации не совсем удачных проектов.

Регистрация процесса проектирования

Традиционным способом регистрации проекта является его http:/ycc2e-com/0606 описание в формальной проектной документации. Однако

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

Включайте проектную документацию прямо в код

Плохие шости ааключщотсй в „ . i

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

и хорошая НОВОСТЬ мы можем -легкостью обращаться к соответствующей проектной

его помштк документации, и повысите вероятность того, что они будут

Дзв$1Д Парте поддерживать ее актуальность. т Пой Кдтентс (ОШ Ршт Регистрируйте протоколы обсуждения проекта и and Paul Clements) принятые решения при помощи Wiki Сохраняйте письменные протоколы обсуждения проекта в системе Wiki (набор Web-страниц, которые может редактировать каждый член группы при помощи Web-браузера). Это позволяет автоматизировать регистрацию нужных данных, хотя и требует дополнительных затрат на набор текста. Кроме того, в Wiki можно хранить полезные цифровые фотографии, ссылки на Web-сайты, содержащие обоснования принятых решений, документы и другие материалы. Этот метод особенно полезен, если члены группы отдалены друг от друга.

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

Закон Грешема (Greshams Law) - монетарный принцип, названный в честь лорда Томаса Гре-шема, управляющего английским монетным двором при королеве Елизавете. Суть закона Грешема в том, что «худшие» деньги (некачественные или с пониженным содержанием благородного металла) вытесняют «лучшие» деньги из обращения, т. е. более «дешевые» деньги вытесняют более «дорогие». - Пргш. перев.



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

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

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

Используйте карточки CRC {Class, Responsibility,

Collaborator - класс, ответственность, сотрудни- Шр: сс2е,сот/0513

чество) Еще один простой вариант документирования

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

Создавайте диаграммы UML с уместным уровнем детальности Одним из популярных способов создания диаграмм проектов является язык UML (Unified Modeling Language; унифицированный язык моделирования), стандартизацией которого занимается организация Object Management Group (Fowler, 2004). Пример UML-диаграммы классов вы уже видели на рис. 5-6. UML предоставляет богатый набор формализованных репрезентаций для проектирования сущностей и их отношений. Вы можете использовать неформальные версии UML для анализа и обсуждения подходов к проектированию. Начните с минимальных набросков и добавляйте детали, только выбрав конкретный вариант проекта. Так как UML стандартизирован, он позволяет эффективнее обмениваться идеями и может ускорить процесс рассмотрения вариантов проектов при работе в группе.

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

5.5. Комментарии по поводу популярных методологий

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



Люди, тшттт проешро- середине первого десятилетия XXI века, некоторые

mm ПО как дисцйгшийироеан- «проповедники» утверждают, что проектирование вообще не

ный процесс, тратят много знер- требуется. «Крупномасштабное Предварительное Проектиро-

гйй, ааставляя всех нас почув- вание - это плохо, - говорят они. - Лучше вообще не вы-

ствовать себя виноватыми. Мы полнять проектирование перед началом кодирования!» никогда не станем достаточно

структурированными ши обьек- За десять лет маятник сместился от «проектирования все-

тно-ориентированными дпя до- го» до «проектирования ничего». Но альтернативой Крупно-

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

вородныи грех изучение

Basic в особо впечатлительном большое Предварительное Проектирование или Достаточ-

возрасте. Но я готов спорить, ное Предварительное Проектирование.

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

к г f точно ответить на этот вопрос. Тем не менее можно с пол-

кажется пуристам.

Ф Дж Плоджер " уверенностью утверждать, что два варианта обязатель-(Р J Pkvger) окажутся неудачными: проектирование всех деталей до единой и полное отсутствие проектирования. Крайние точки зрения всегда ошибочны!

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

Дополнительные ресурсы

Проектирование ПО описанно во множестве работ. Пробле-http: cc2e.com/0520 ма в том, чтобы определить, какие из них наиболее полез-

ны. Позволю себе дать вам некоторые советы.

Общие вопросы проектирования ПО

Weisfeld, Matt. The Object-Oriented Thought Process, 2d ed. - SAMS, 2004 - понятное введение в объектно-ориентированное программирование. Если вы уже знакомы с объектно-ориентированным программированием, возможно, вам следует поискать более серьезную книгу, но если вы новичок в этой области, эта книга познакомит вас с фундаментальными объектно-ориентированными концепциями, такими как объекты, классы, интерфейсы, наследование, полиморфизм, перегрузка, абстрактные классы, агрегация и ассоциация, конструкторы/деструкторы, исключения и т. д.

Riel, Arthur J. Object-Oriented Design Heuristics. - Reading, MA: Addison-Wesley 1996. В этой книге основное внимание уделяется проектированию на уровне классов. Еще она легко читается.

Plauger, R J. Programming on Purpose: Essays on Software Design. - Englewood Cliffs, NJ: PTR Prentice Hall, 1993. В этой книге я нашел столько хороших советов по проектированию ПО, сколько во всех остальных прочитанных мной книгах вме-



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