Управление проектами - статьи


              

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


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

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

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

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

Интересно, а если перевернуть все наоборот? Если бы вы вначале решили не использовать EJB, не было бы сложнее в последний момент внести его в систему? Действительно ли не стоит начинать делать систему с EJB, пока вы окончательно не убедитесь, что без этого не обойтись? Этот вопрос затрагивает сразу несколько факторов. Разумеется, работать без такого сложного компонента легче и быстрее. Однако иногда легче что-то выбросить из системы, чем вставить.

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



Содержание  Назад  Вперед





Forekc.ru
Рефераты, дипломы, курсовые, выпускные и квалификационные работы, диссертации, учебники, учебные пособия, лекции, методические пособия и рекомендации, программы и курсы обучения, публикации из профильных изданий