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

Пошаговая разработка программного обеспечения

Следование методам экстремального программирования, сулит улучшение качества ПО, но так ли это на самом деле?

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

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

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

Синица в руках

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

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

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

Помимо методов работы программистов ХР предполагает изменение методов планирования проектов. Действительно, создание кода — занятие очень сложное. Многие программные проекты закончились неудачей частично из-за плохого руководства, частично из-за плохого кодирования, а иногда из-за серьезных упущений в исходной концепции или архитектуре.

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

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

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

Постепенные улучшения

Как бы мы ни относились к XP, один из его основополагающих принципов — разложение (refactoring). Этим термином обозначают набор систематизированных методик для идентификации и улучшения плохого кода, предполагающих безжалостное удаление ненужного кода и сохранение максимальной простоты проекта.

Насколько безжалостным следует быть? В своей книге «Разложение: улучшение структуры существующего кода» (Refactoring: Improving the Design of Existing Code) Мартин Фоулер разделяет один «подозрительный» метод в одном классе на десять методов, распределенных по семи классам, пытаясь создать более строгий, высококачественный и простой для чтения код. Даже комментирование кода (первейшее правило для настоящих программистов) не осталось без внимания Фоулера. После разложения код должен стать настолько простым, чтобы никаких комментариев к нему не понадобилось. Хотя разложение, безусловно, имеет смысл, не столь давно нас убеждали делать комментарии, проектировать программы так, чтобы их фрагменты можно было повторно использовать, и призывали стать сторонниками модульного программирования. Возможно, через несколько лет вы придете в немалое изумление, наткнувшись на статью, в которой предлагается метод, противоположный разложению, суть которого в объединении вышеупомянутых десяти методов в один.

Неустрашимые

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

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

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