МДК.03.01 технология разработки программного обеспечения (стр. 12 )

Подобный эффект имеет и рефакторинг (переработка написанного кода). Те, кто делают рефакторинг в той строгий манере, что принята в ХР, отмечают значительное повышение его эффективности по сравнению с более бессистемной реструктуризацией.

Все эти основополагающие практики (непрерывная интеграция, тестирование и рефакторинг) создают новую среду, в которой эволюционное проектирование выглядит вполне убедительно.

Преимущества простого дизайна

В ХР очень популярны два лозунга: «Do the Simplest Thing that Could Possibly Work» («Ищите самое простое решение, кото рое может сработать») и YAGNI («You Aren't Going to Need It» — «Это вам не понадобится»)- Оба они олицетворяют собой одну из практик ХР под названием Простой дизайн.

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

Тем не менее ХР не советует заниматься созданием гибких компонентов и каркасов до того, как понадобится именно эта функциональность. Лучше, если эти структуры будут наращиваться по мере необходимости. Если сегодня мне нужен класс Money, который обрабатывает сложение, а не умножение, то сегодня я буду встраивать в этот класс только сложение. Даже если я абсолютно уверен, что умножение понадобится мне уже в следующей итерации, и я знаю, как очень просто и быстро это сделать сейчас, все равно я должен оставить это на следующую итерацию, когда в нем появится реальная необходимость.

Такое поведение оправдано с экономической точки зрения. Занимаясь работой, которая понадобится только завтра, я тем самым расходую силы и время, предназначенные для задач, которые должны были быть сделаны сегодня. План выпуска про граммы четко указывает, над чем мне нужно работать в настоящий момент. Если я отклоняюсь от него, чтобы поработать над тем, что понадобится в будущем, я нарушаю свое соглашение с заказчиком. Кроме того, появляется риск не успеть сделать все записанное в требованиях для текущей итерации. И даже в том случае, если такой опасности нет и у вас появилось свободное время, то решать, чем вам заняться. — прерогатива заказчика, который может попросить заняться вовсе не умножением.

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

Другая причина, по которой простой дизайн лучше сложно го, — отказ от принципа «блуждающего огонька». Сложную конструкцию гораздо труднее понять, чем простую. Именно поэтому любая модификация системы делает ее все более сложной. Это опять-таки ведет к увеличению стоимости работ в период между тем временем, когда дизайн системы стал более сложным, и временем, когда это действительно стало необходимо [3].

Такой стиль работы многим кажется абсурдным, и надо сказать, что они правы. Правы при одном условии — абсурд получится, если эту практику начать применять в обычном процессе разработки, а все остальные практики ХР игнорировать. Если же изменить существующий баланс между эволюционным и предварительным проектированием, то YAGNI становится очень полезным принципом (тогда и только тогда).

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

Простой дизайн

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

В книге Extreme Programming Explained Кент приводит четыре критерия простой системы. Вот они в порядке убывания важности:

·  система успешно проходит все тесты;

·  код системы ясно раскрывает все изначальные замыслы;

·  в ней отсутствует дублирование кода;

·  используется минимально возможное количество классов и методов.

Успешное тестирование системы — довольно простой критерий. Отсутствие дублирования кода тоже вполне четкое требование, хотя большинство разработчиков нужно учить, как этого достичь. Самое сложное скрывается в слонах «раскрывает изначальные замыслы». Что это значит?

Основное достоинство программного кода в данном случае — его ясность. ХР всячески подчеркивает, что хороший код — это код, который можно легко прочесть. Скажите ХР-шнику, что он пишет «заумный код», и будьте уверены, что обругали этого человека. Но понимание замыслов программиста, написавшего код, зависит также и от опыта и ума того, кто этот код пытается прочесть. Однако отмстим, что не стоит думать над вопросом, как сделать дизайн максимально простым. В конце концов, позже вы сможете (и должны, и будете) заняться рефакторингом. В конце работы над проектом желание делать рефакторинг гораздо важнее, чем точное понимание того, какое решение является самым простым.

Эта тема сравнительно недавно всплыла в списке рассылки, посвященном ХР, и, коль скоро мы заговорили о роли проектирования, нам стоит ее обсудить.

Дело в том, что процесс рефакторинга требует времени, но не добавляет новой функциональности. С другой стороны, принцип YAGN1 гласит, что надо проектировать только для те кущей функциональности, а не для того, что понадобится в будущем. Не сталкиваемся ли мы здесь с противоречием?

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

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

Наращивание архитектуры

Термин «архитектура» передает идею основных элементов системы, тех ее частей, которые трудно изменить. Они являются фундаментом, на котором можно построить все остальное.

Какую роль играет архитектура в эволюционном проектировании? Критики ХР считают, что эта методология вообще не признает работы над архитектурой, что вся суть ХР — сразу садиться за написание кода и уповать на то, что рефакторинг решит все проблемы с проектированием. Они правы, и, может быть, в этом заключается некоторая слабость ХР Приверженцы ХР - Кент Бек (Kent Beck), Рон Джеффриз (Ron Jeffries) и Боб Мартин (Bob Martin) — прикладывают очень много сил, чтобы вообще избежать любого предварительного проектирования архитектуры. Не добавляйте в систему базу данных, пока она вам действительно не понадобилась. Работайте поначалу с файлами, а база данных появится в следующей итерации, в результате ре-факторинга.

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

UML и ХР

В идеале ХР полностью отрицает проектирование системы, в частности методами UML. Тем не менее программисты все же часто используют на начальном этапе диаграммы UML. На самом деле диаграммы очень полезны для понимая разрабатываемого продукта, но чтобы они сделали процесс более длительным и трудоемким, необходимо их использовать правильно.

Советы тем, кто хочет правильно использовать диаграммы.

Во-первых, пока рисуете диаграмму, не забывайте, для чего вы это делаете. Основное ее достоинство — коммуникация с людьми. Чтобы коммуникация была эффективной, нужно отображать на диаграмме только важные аспекты, не обращая внимания на все второстепенные. Такая избирательность — основа правильной работы с UML. Не надо отображать на диаграмме каждый класс —- только самые важные. У классов не нужно задавать каждый атрибут или операцию — только самые важные. Не надо рисовать диаграммы последовательности для всех вариантов использования и сценариев — ну, и так далее. Самая распространенная проблема с использованием диаграмм — это то, что их пытаются сделать максимально всеобъемлющими. Однако самый лучший источник всеобъемлющей информации — это программный код, так как именно его легче всего синхронизировать с кодом. Для диаграммы же всеобъемлемость – враг удобопонятности.

Чаще всего диаграммы используются для того, чтобы про анализировать проектные решения еще до написания кода. Не редко при этом возникает чувство, что в ХР этого делать нельзя. Это совсем не так. Многие полагают, что перед разработкой сложной задачи стоит ненадолго собраться всей командой для ее предварительного проектирования. Тем не менее, когда проводите такие собрания, не забывайте, что: