Компания, которая за один раз передает в руки заказчика достаточно крупный программный продукт, не может выпускать очередные версии этого продукта достаточно часто. Эта компания должна сократить время работы над очередной версией настолько, насколько это возможно.
Метафора
Каждый программный проект ХР направляется при помощи единой всеобъемлющей метафоры. Иногда эта метафора выглядит наивной, как, например, система управления контрактами, о которой рассказывается в терминах контрактов, заказчиков и индоссаментов. Иногда метафора требует дополнительных разъяснений, например, требуется отметить, что компьютер должен рассматриваться как рабочий стол или вычисление пенсии должно выглядеть как электронная таблица. Все это метафоры, так как на самом деле мы не говорим буквально, что система – это электронная таблица. Метафора просто помогает каждому участнику проекта понять базовые элементы программы и то, как они взаимосвязаны.
Слова, которые используются для идентификации технических элементов системы, должны постоянно заимствоваться из выбранной метафоры. По мере того как идет работа над проектом, метафора развивается и вся команда продолжает ее анализировать, получая при этом новые источники вдохновения.
В ХР метафора во многом заменяет собой то, что другие люди называют термином архитектура. Проблема состоит в том, что архитектура – это, как правило, огромная по размерам схема системы, которая не дает представления о ее целостности. Архитектура – это большие прямоугольники и соединения между ними.
Конечно же, вы можете сказать: плохо сформированная архитектура – это плохо. Однако нам требуется подчеркнуть саму цель, для которой формируется архитектура, а это значит, что мы должны предоставить каждому участнику проекта связную историю о строении и функционировании системы. Эта история должна быть изложена на языке, понятном как технарям, так и бизнесменам. В рамках этой истории будет осуществляться работа над проектом. Спросив о метафоре, мы получаем в ответ сведения об архитектуре, причем эти сведения передаются нам в такой форме, которая удобна для общения и обдумывания.
Простой дизайн
В каждый момент времени правильным является дизайн системы, в рамках которого:
1. Выполняются все тесты.
2. Нет дублирующейся логики. (Опасайтесь скрытого дублирования, например, применения параллельных иерархий классов.)
3. Выражается каждая из идей, важных для программистов.
4. Существует наименьшее возможное количество классов и методов.
Каждый фрагмент дизайна системы должен доказать свое право на существование на основании всех перечисленных правил. Эдвард Туфт (Edward Tufte) придумал упражнение для разработчиков графов – нарисуйте граф так, как хотите, затем стирайте до тех пор, пока вы не удаляете из графа полезную информацию. Если вы не можете больше продолжать стирание, значит, перед вами наиболее удачный дизайн для графа. Простой дизайн программной системы можно сформировать точно таким же образом – уберите из системы все элементы, какие вы сможете убрать, не нарушив при этом правил 1-3.
Edward Tufte, The Visual Display of Quantitative Information (Визуальное отображение численной информации), Graphics Press, 1992.
Этот совет противоположен тому, что обычно приходится слышать программистам: Реализуйте для сегодняшнего дня, а проектируйте – для завтрашнего. Однако если вы уверены, что будущее – в неопределенности, если вы верите в то, что завтра вы можете сменить направление своих мыслей и не платить за это слишком дорого, значит, включение в дизайн функциональности только на основании абстрактных размышлений – это безумство. Добавляйте в дизайн то, что вам нужно, только тогда, когда это действительно вам нужно.
Тестирование
Любая возможность программы, для которой нет автоматических тестов, просто не существует. Программисты пишут тесты модулей, благодаря чему их уверенность в правильности функционирования программы становится частью самой программы. Заказчики пишут функциональные тесты, благодаря чему их уверенность в функционировании программы также становится частью программы. В результате всеобщая уверенность в работоспособности программы со временем все возрастает и возрастает. Эта уверенность выражена в наборе тестов, количество которых увеличивается и которые продолжают функционировать по мере продолжения работы над программой. Благодаря этому со временем программа становится не менее, а более приспособленной для внесения в нее изменений.
Нет необходимости писать тесты для каждого разрабатываемого вами метода, проверять надо только производственные методы, которые могут не сработать. Иногда вы тратите усилия только на то, чтобы понять, возможно ли в процессе функционирования кода возникновение той или иной ситуации. В течение получаса вы анализируете код. Да, это возможно. Теперь вы отбрасываете код и начинаете писать его заново – начиная с тестов.
Переработка
Когда программисты приступают к реализации некоторой возможности программы, они всегда задаются вопросом, существует ли способ изменения имеющейся программы для того, чтобы упростить добавление в нее требуемой новой возможности? После того как возможность добавлена, программисты спрашивают себя, можно ли теперь упростить программу и при этом обеспечить выполнение всех тестов? Это и называется переработкой кода (refactoring).
Обратите внимание, это означает, что иногда вы должны сделать больше работы, чем это на самом деле необходимо для того, чтобы добавить в программу новую возможность. Однако, работая в этом ключе, вы обеспечиваете снижение затрат, связанных с добавлением в программу последующих возможностей. Переработав код, вы упрощаете его дальнейшую модернизацию. Вы не выполняете переработку исходя из предварительных нечетких размышлений, напротив, вы перерабатываете код тогда, когда система нуждается в этом. Когда при добавлении новой возможности вы дублируете код, это означает, что система просит вас выполнить переработку.
Если программист видит некоторый черновой способ обеспечить выполнение теста, для реализации которого потребуется одна минута, и, помимо этого, он также видит другой, более элегантный способ обеспечить выполнение теста, предусматривающий также упрощение дизайна, но для реализации которого требуется десять минут, программист должен предпочесть второй способ, то есть потратить больше времени, но в результате получить более простой и более элегантный дизайн. К счастью, в рамках ХР вы получаете возможность вносить в дизайн системы любые, даже самые радикальные изменения, делая это небольшими, малорискованными шагами.
Программирование парами
Весь код системы вплоть до ее внедрения в производство пишется парами программистов, каждая из которых работает на одном компьютере, оснащенном одной клавиатурой и одной мышью.
В каждой паре существуют две роли. Один партнер, в руках которого находится клавиатура и мышь, думает о том, как прямо сейчас реализовать некоторый метод самым лучшим образом. Второй партнер думает более стратегически:
• Сработает ли используемый подход в целом?
• Какими могут быть другие, еще не рассмотренные тестовые случаи?
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
Метафора
Каждый программный проект ХР направляется при помощи единой всеобъемлющей метафоры. Иногда эта метафора выглядит наивной, как, например, система управления контрактами, о которой рассказывается в терминах контрактов, заказчиков и индоссаментов. Иногда метафора требует дополнительных разъяснений, например, требуется отметить, что компьютер должен рассматриваться как рабочий стол или вычисление пенсии должно выглядеть как электронная таблица. Все это метафоры, так как на самом деле мы не говорим буквально, что система – это электронная таблица. Метафора просто помогает каждому участнику проекта понять базовые элементы программы и то, как они взаимосвязаны.
Слова, которые используются для идентификации технических элементов системы, должны постоянно заимствоваться из выбранной метафоры. По мере того как идет работа над проектом, метафора развивается и вся команда продолжает ее анализировать, получая при этом новые источники вдохновения.
В ХР метафора во многом заменяет собой то, что другие люди называют термином архитектура. Проблема состоит в том, что архитектура – это, как правило, огромная по размерам схема системы, которая не дает представления о ее целостности. Архитектура – это большие прямоугольники и соединения между ними.
Конечно же, вы можете сказать: плохо сформированная архитектура – это плохо. Однако нам требуется подчеркнуть саму цель, для которой формируется архитектура, а это значит, что мы должны предоставить каждому участнику проекта связную историю о строении и функционировании системы. Эта история должна быть изложена на языке, понятном как технарям, так и бизнесменам. В рамках этой истории будет осуществляться работа над проектом. Спросив о метафоре, мы получаем в ответ сведения об архитектуре, причем эти сведения передаются нам в такой форме, которая удобна для общения и обдумывания.
Простой дизайн
В каждый момент времени правильным является дизайн системы, в рамках которого:
1. Выполняются все тесты.
2. Нет дублирующейся логики. (Опасайтесь скрытого дублирования, например, применения параллельных иерархий классов.)
3. Выражается каждая из идей, важных для программистов.
4. Существует наименьшее возможное количество классов и методов.
Каждый фрагмент дизайна системы должен доказать свое право на существование на основании всех перечисленных правил. Эдвард Туфт (Edward Tufte) придумал упражнение для разработчиков графов – нарисуйте граф так, как хотите, затем стирайте до тех пор, пока вы не удаляете из графа полезную информацию. Если вы не можете больше продолжать стирание, значит, перед вами наиболее удачный дизайн для графа. Простой дизайн программной системы можно сформировать точно таким же образом – уберите из системы все элементы, какие вы сможете убрать, не нарушив при этом правил 1-3.
Edward Tufte, The Visual Display of Quantitative Information (Визуальное отображение численной информации), Graphics Press, 1992.
Этот совет противоположен тому, что обычно приходится слышать программистам: Реализуйте для сегодняшнего дня, а проектируйте – для завтрашнего. Однако если вы уверены, что будущее – в неопределенности, если вы верите в то, что завтра вы можете сменить направление своих мыслей и не платить за это слишком дорого, значит, включение в дизайн функциональности только на основании абстрактных размышлений – это безумство. Добавляйте в дизайн то, что вам нужно, только тогда, когда это действительно вам нужно.
Тестирование
Любая возможность программы, для которой нет автоматических тестов, просто не существует. Программисты пишут тесты модулей, благодаря чему их уверенность в правильности функционирования программы становится частью самой программы. Заказчики пишут функциональные тесты, благодаря чему их уверенность в функционировании программы также становится частью программы. В результате всеобщая уверенность в работоспособности программы со временем все возрастает и возрастает. Эта уверенность выражена в наборе тестов, количество которых увеличивается и которые продолжают функционировать по мере продолжения работы над программой. Благодаря этому со временем программа становится не менее, а более приспособленной для внесения в нее изменений.
Нет необходимости писать тесты для каждого разрабатываемого вами метода, проверять надо только производственные методы, которые могут не сработать. Иногда вы тратите усилия только на то, чтобы понять, возможно ли в процессе функционирования кода возникновение той или иной ситуации. В течение получаса вы анализируете код. Да, это возможно. Теперь вы отбрасываете код и начинаете писать его заново – начиная с тестов.
Переработка
Когда программисты приступают к реализации некоторой возможности программы, они всегда задаются вопросом, существует ли способ изменения имеющейся программы для того, чтобы упростить добавление в нее требуемой новой возможности? После того как возможность добавлена, программисты спрашивают себя, можно ли теперь упростить программу и при этом обеспечить выполнение всех тестов? Это и называется переработкой кода (refactoring).
Обратите внимание, это означает, что иногда вы должны сделать больше работы, чем это на самом деле необходимо для того, чтобы добавить в программу новую возможность. Однако, работая в этом ключе, вы обеспечиваете снижение затрат, связанных с добавлением в программу последующих возможностей. Переработав код, вы упрощаете его дальнейшую модернизацию. Вы не выполняете переработку исходя из предварительных нечетких размышлений, напротив, вы перерабатываете код тогда, когда система нуждается в этом. Когда при добавлении новой возможности вы дублируете код, это означает, что система просит вас выполнить переработку.
Если программист видит некоторый черновой способ обеспечить выполнение теста, для реализации которого потребуется одна минута, и, помимо этого, он также видит другой, более элегантный способ обеспечить выполнение теста, предусматривающий также упрощение дизайна, но для реализации которого требуется десять минут, программист должен предпочесть второй способ, то есть потратить больше времени, но в результате получить более простой и более элегантный дизайн. К счастью, в рамках ХР вы получаете возможность вносить в дизайн системы любые, даже самые радикальные изменения, делая это небольшими, малорискованными шагами.
Программирование парами
Весь код системы вплоть до ее внедрения в производство пишется парами программистов, каждая из которых работает на одном компьютере, оснащенном одной клавиатурой и одной мышью.
В каждой паре существуют две роли. Один партнер, в руках которого находится клавиатура и мышь, думает о том, как прямо сейчас реализовать некоторый метод самым лучшим образом. Второй партнер думает более стратегически:
• Сработает ли используемый подход в целом?
• Какими могут быть другие, еще не рассмотренные тестовые случаи?
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