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

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

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

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

• кодирование;

• тестирование;

• слушание;

• проектирование.

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

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

Вот исходные материалы, из которых нам предстоит построить новую дисциплину разработки программного обеспечения:

• история об управлении автомобилем;

• четыре ценности – коммуникация, простота, обратная связь и храбрость;

• принципы;

• четыре базовые активности – кодирование, тестирование, слушание и проектирование.

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

Нет проблем.

Э-э-э...

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

Для начала перечислю все методики.

• Игра в планирование (planning game) – быстро определяет перечень задач (объем работ), которые необходимо реализовать в следующей версии продукта. Для этого рассматриваются бизнес-приоритеты и технические оценки. Если со временем план перестает соответствовать действительности, происходит обновление плана.

• Небольшие версии (small releases) – самая первая упрощенная версия системы быстро вводится в эксплуатацию, после этого через относительно короткие промежутки времени происходит выпуск версии за версией.

• Метафора (metaphor) – эта простая общедоступная и общеизвестная история, которая коротко описывает, как работает вся система. Эта история управляет всем процессом разработки.

• Простой дизайн (simple design) – в каждый момент времени система должна быть спроектирована так просто, как это возможно. Чрезмерная сложность устраняется, как только ее обнаруживают.

• Тестирование (testing) – программисты постоянно пишут тесты для модулей. Для того чтобы разработка продолжалась, все тесты должны срабатывать. Заказчики пишут тесты, которые демонстрируют работоспособность и завершенность той или иной возможности системы.

• Переработка (refactoring) – программисты реструктурируют систему, не изменяя при этом ее поведения. При этом они устраняют дублирование кода, улучшают коммуникацию, упрощают код и повышают его гибкость.

• Программирование парами (pair programming) – весь разрабатываемый код пишется двумя программистами на одном компьютере.

• Коллективное владение (collective ownership) – в любой момент времени любой член команды может изменить любой код в любом месте системы.

• Непрерывная интеграция (continuous integration) – система интегрируется и собирается множество раз в день. Это происходит каждый раз, когда завершается решение очередной задачи.

• 40-часовая неделя (40-hour week) – программисты работают не более 40 часов в неделю. Это правило. Никогда нельзя работать сверхурочно две недели подряд.

• Заказчик на месте разработки (on-site customer) – в состав команды входит реальный живой пользователь системы. Он доступен в течение всего рабочего дня и способен отвечать на вопросы о системе.

• Стандарты кодирования (coding standards) – программисты пишут весь код в соответствии с правилами, которые обеспечивают коммуникацию при помощи кода.

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

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