ХР подходит далеко не каждому, и далеко не каждый подходит для ХР. Однако вовсе необязательно с самого первого дня внедрения ХР все свое рабочее время программировать в паре и только в паре. Как и ко всему остальному в ХР, вы должны привыкать к программированию в парах постепенно. Попробуйте работать в паре в течение часа. Если у вас плохо получится, попытайтесь понять, что именно вы делаете не так, затем попробуйте поработать в паре еще один час.
Почему программирование парами хорошо работает в рамках ХР? Прежде всего потому, что программирование парами обеспечивает отличную коммуникацию. Мало того, программирование в парах обеспечивает более интенсивную коммуникацию, чем обмен сведениями между двумя людьми. Таким образом, программирование в парах хорошо работает в ХР потому, что оно стимулирует коммуникацию. Я часто сравниваю команду с миской, в которую налита прозрачная вода. Как только кто-либо в команде узнает какую-либо важную новость, это напоминает падение капли краски в миску с прозрачной водой. Партнеры в парах все время меняются, поэтому важная свежая информация быстро распространяется среди членов команды подобно тому, как краска растворяется в воде. Однако в отличие от краски по мере распространения информация становится более насыщенной и более продуманной. Она насыщается за счет опыта и интеллекта каждого из членов команды.
Мой опыт показывает, что программирование в парах более продуктивно, чем разделение работы между двумя отдельными программистами и последующая интеграция результатов. Программирование парами часто становится на первый план для людей, желающих использовать ХР. Все, что я могу посоветовать, это то, что вы должны вначале хорошо овладеть им, затем попробовать выполнить очередную итерацию продукта так, чтобы весь код был написан в парах, а затем следующую итерацию разработать так, чтобы программисты работали по отдельности. После этого вы сможете сформировать ваше собственное мнение.
Даже если вы не получили роста продуктивности, вы все равно не должны сбрасывать со счетов программирование в парах, потому что получаемый в результате этого код обладает существенно более высоким качеством. Пока один из партнеров занят набиванием кода на клавиатуре, другой партнер размышляет на более высоком стратегическом уровне. Куда ведет избранный путь кодирования? Не попадем ли мы в тупик? Существует ли более эффективная стратегия организации этого кода? Какие есть возможности для переработки кода?
Еще одной важной особенностью программирования парами является то обстоятельство, что некоторые из методик ХР без него не работают. В состоянии стресса люди забывают о правилах хорошего тона. Они перестают писать тесты. Они отказываются от выполнения переработки. Они откладывают на потом интеграцию. Однако если за вами следит ваш партнер и при этом вы собираетесь нарушить одну из методик, у вас возникает чувство вины. Вам неудобно перед вашим партнером, так как вам кажется, что он никогда бы так не поступил. Сказанное не означает, что пары никогда не нарушают нормальный ход процесса разработки. Конечно же иногда это происходит, в противном случае вам не понадобился бы инструктор (coach). Однако если вы работаете в паре, вероятность того, что вы проигнорируете некоторые общепринятые правила, ниже, чем если бы вы работали в одиночку.
Противоречивая природа программирования парами также существенно улучшает процесс разработки программного обеспечения. Вы быстро учитесь разговаривать на нескольких разных уровнях – этот код здесь, код, подобный этому, в другом месте системы, эпизоды разработки, подобные этому, в прошлом, системы, подобные этой, над которыми вы работали несколько лет назад, методики, которые вы используете, и как их можно улучшить.
Глава 17.
Стратегия проектирования
Мы начнем с самого простого дизайна, который только возможен. После этого мы будем постоянно пересматривать дизайн системы. Мы будем удалять из системы любую гибкость, которая оказывается бесполезной.
Во многих отношениях эта глава оказалась для меня самой сложной из всей книги. Стратегия дизайна в ХР предусматривает, что система всегда должна обладать наиболее простым дизайном, при которым срабатывает текущий набор тестов.
Рассмотрим подробнее, что такое простота и что такое наборы тестов.
Самая простая вещь, которая, возможно, сработает
Давайте сделаем шаг назад и подойдем к решению проблемы постепенно. В формировании этой стратегии участвуют все четыре ценности.
• Коммуникация – сложный дизайн сложнее описать, чем простой. По этой причине мы должны создать стратегию проектирования, которая формирует наиболее простой возможный дизайн, согласующийся со стоящими перед нами целями. С другой стороны, мы должны создать стратегию дизайна, которая формирует описательные и информативные дизайны, элементы которого хорошо описывают внутреннее строение системы тому, кто изучает этот дизайн.
• Простота – мы собираемся сформировать стратегию, которая помогала бы нам создавать простые дизайны, однако при этом, и сама стратегия должна быть простой. Это не означает, что она должна просто воплощаться в жизнь. Хороший дизайн – это всегда не так уж просто. Однако объяснить стратегию должно быть просто.
• Обратная связь – одна из проблем, с которой мне приходилось сталкиваться в процессе проектирования, прежде чем я начал практиковать ХР, состояла в том, что я никогда не мог сказать точно, прав я или нет. Чем дольше я проектировал, тем значительней становилась эта проблема. Простой дизайн решает проблему благодаря тому, что он формируется быстро. Далее следует закодировать его и посмотреть, как выглядит и ведет себя код.
• Храбрость – что может быть более отважным, чем остановиться, обладая лишь частью дизайна, приступить к реализации и быть уверенным в том, что в дальнейшем вы сможете добавить в систему больше, если в этом возникнет необходимость.
Следуя этим ценностям, мы должны:
• сформировать стратегию проектирования, в результате использования которой формируется простой дизайн;
• найти быстрый способ убедиться в том, что дизайн качественный;
• организовать обратную связь для того, чтобы быстро воплощать наши новые открытия и выводы в дизайне системы;
• сжать цикл времени, в течение которого выполняется весь этот процесс, и сделать его как можно короче.
Принятые нами ранее принципы также хорошо воплощаются в стратегии дизайна.
• Небольшие изначальные инвестиции – прежде чем получить первую отдачу от дизайна, мы должны инвестировать в проектирование системы так мало, насколько это возможно.
• Приемлемая простота – мы должны быть уверенными в предположении, что самый простой дизайн, решающий проблему, который мы только можем себе представить, скорее всего, будет работать.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61
Почему программирование парами хорошо работает в рамках ХР? Прежде всего потому, что программирование парами обеспечивает отличную коммуникацию. Мало того, программирование в парах обеспечивает более интенсивную коммуникацию, чем обмен сведениями между двумя людьми. Таким образом, программирование в парах хорошо работает в ХР потому, что оно стимулирует коммуникацию. Я часто сравниваю команду с миской, в которую налита прозрачная вода. Как только кто-либо в команде узнает какую-либо важную новость, это напоминает падение капли краски в миску с прозрачной водой. Партнеры в парах все время меняются, поэтому важная свежая информация быстро распространяется среди членов команды подобно тому, как краска растворяется в воде. Однако в отличие от краски по мере распространения информация становится более насыщенной и более продуманной. Она насыщается за счет опыта и интеллекта каждого из членов команды.
Мой опыт показывает, что программирование в парах более продуктивно, чем разделение работы между двумя отдельными программистами и последующая интеграция результатов. Программирование парами часто становится на первый план для людей, желающих использовать ХР. Все, что я могу посоветовать, это то, что вы должны вначале хорошо овладеть им, затем попробовать выполнить очередную итерацию продукта так, чтобы весь код был написан в парах, а затем следующую итерацию разработать так, чтобы программисты работали по отдельности. После этого вы сможете сформировать ваше собственное мнение.
Даже если вы не получили роста продуктивности, вы все равно не должны сбрасывать со счетов программирование в парах, потому что получаемый в результате этого код обладает существенно более высоким качеством. Пока один из партнеров занят набиванием кода на клавиатуре, другой партнер размышляет на более высоком стратегическом уровне. Куда ведет избранный путь кодирования? Не попадем ли мы в тупик? Существует ли более эффективная стратегия организации этого кода? Какие есть возможности для переработки кода?
Еще одной важной особенностью программирования парами является то обстоятельство, что некоторые из методик ХР без него не работают. В состоянии стресса люди забывают о правилах хорошего тона. Они перестают писать тесты. Они отказываются от выполнения переработки. Они откладывают на потом интеграцию. Однако если за вами следит ваш партнер и при этом вы собираетесь нарушить одну из методик, у вас возникает чувство вины. Вам неудобно перед вашим партнером, так как вам кажется, что он никогда бы так не поступил. Сказанное не означает, что пары никогда не нарушают нормальный ход процесса разработки. Конечно же иногда это происходит, в противном случае вам не понадобился бы инструктор (coach). Однако если вы работаете в паре, вероятность того, что вы проигнорируете некоторые общепринятые правила, ниже, чем если бы вы работали в одиночку.
Противоречивая природа программирования парами также существенно улучшает процесс разработки программного обеспечения. Вы быстро учитесь разговаривать на нескольких разных уровнях – этот код здесь, код, подобный этому, в другом месте системы, эпизоды разработки, подобные этому, в прошлом, системы, подобные этой, над которыми вы работали несколько лет назад, методики, которые вы используете, и как их можно улучшить.
Глава 17.
Стратегия проектирования
Мы начнем с самого простого дизайна, который только возможен. После этого мы будем постоянно пересматривать дизайн системы. Мы будем удалять из системы любую гибкость, которая оказывается бесполезной.
Во многих отношениях эта глава оказалась для меня самой сложной из всей книги. Стратегия дизайна в ХР предусматривает, что система всегда должна обладать наиболее простым дизайном, при которым срабатывает текущий набор тестов.
Рассмотрим подробнее, что такое простота и что такое наборы тестов.
Самая простая вещь, которая, возможно, сработает
Давайте сделаем шаг назад и подойдем к решению проблемы постепенно. В формировании этой стратегии участвуют все четыре ценности.
• Коммуникация – сложный дизайн сложнее описать, чем простой. По этой причине мы должны создать стратегию проектирования, которая формирует наиболее простой возможный дизайн, согласующийся со стоящими перед нами целями. С другой стороны, мы должны создать стратегию дизайна, которая формирует описательные и информативные дизайны, элементы которого хорошо описывают внутреннее строение системы тому, кто изучает этот дизайн.
• Простота – мы собираемся сформировать стратегию, которая помогала бы нам создавать простые дизайны, однако при этом, и сама стратегия должна быть простой. Это не означает, что она должна просто воплощаться в жизнь. Хороший дизайн – это всегда не так уж просто. Однако объяснить стратегию должно быть просто.
• Обратная связь – одна из проблем, с которой мне приходилось сталкиваться в процессе проектирования, прежде чем я начал практиковать ХР, состояла в том, что я никогда не мог сказать точно, прав я или нет. Чем дольше я проектировал, тем значительней становилась эта проблема. Простой дизайн решает проблему благодаря тому, что он формируется быстро. Далее следует закодировать его и посмотреть, как выглядит и ведет себя код.
• Храбрость – что может быть более отважным, чем остановиться, обладая лишь частью дизайна, приступить к реализации и быть уверенным в том, что в дальнейшем вы сможете добавить в систему больше, если в этом возникнет необходимость.
Следуя этим ценностям, мы должны:
• сформировать стратегию проектирования, в результате использования которой формируется простой дизайн;
• найти быстрый способ убедиться в том, что дизайн качественный;
• организовать обратную связь для того, чтобы быстро воплощать наши новые открытия и выводы в дизайне системы;
• сжать цикл времени, в течение которого выполняется весь этот процесс, и сделать его как можно короче.
Принятые нами ранее принципы также хорошо воплощаются в стратегии дизайна.
• Небольшие изначальные инвестиции – прежде чем получить первую отдачу от дизайна, мы должны инвестировать в проектирование системы так мало, насколько это возможно.
• Приемлемая простота – мы должны быть уверенными в предположении, что самый простой дизайн, решающий проблему, который мы только можем себе представить, скорее всего, будет работать.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61