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

Основополагающие практики XP

Теоретический материал

Экстремальное программирование

Лекция №12

Вопросы для контроля

1. Что понимается под объектом? Что такое класс?
2. Перечислите основные элементы (принципы) объектно-ориентированного программирования
3. Перечислите дополнительные элементы (принципы) объектно-ориентированного программирования
4. Дайте характеристику языка моделирования UML

Цели занятия:

Обучающая: получить представление об экстремальном программировании, о качествах, предъявляемых методологией XP к человеку;

Ведущий метод обучения: объяснительно-иллюстративный.

Форма занятия: лекция.

Оснащение занятия: конспект лекции, презентации.

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

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

В основе XP лежит предположение, что эту кривую можно сгладить до такой степени, чтобы можно было применять эволюционное проектирование. Такое сглаживание, с одной стороны, возникает при использовании методологии XP, а с другой – оно же в ней и используется.

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

Подобный эффект имеет и рефакторинг (переработка написанного кода).

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

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

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

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

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

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

Необходимо, чтобы программный код был максимально прост.

Четыре критерия простой системы (в порядке убывания важности):

1. Система успешно проходит все тесты.
2. Код системы ясно раскрывает все изначальные замыслы.
3. В ней отсутствует дублирование кода.
4. Используется минимально возможное количество классов и методов.

Дата добавления: 2014-01-05