3.Основные приемы экстремального программирования.

Технология экстремального программирования базируется на совокупности основных приемов. Некоторые из этих приемов используются в других технологиях программирования. Принципиально важно, что в технологии XP данные приемы собраны вместе. При рассмотрении данных приемов, целесообразно, использовать названия приемов, которые им дали разработчики экстремального программирования.  Можно выделить следующие приемы экстремального программирования. Основной прием экстремального программирования, который называется «Разработка через тестирование (Test-driven development, TDD)». Разработка через тестирование, представляет собой технику разработки программного обеспечения, которая основывается на повторении очень коротких циклов разработки: сначала пишется тест, покрывающий желаемое изменение, затем пишется код, который позволит пройти тест, и под конец проводится рефакторинг (refactoring) нового кода к соответствующим стандартам. Эксперты считают, что разработка через тестирование поощряет простой дизайн и внушает уверенность. Экстремальность подхода заключается в том, что тесты пишутся до написания программного кода. Каждый модуль обязан иметь юнит-тест (unit test) данного модуля. Разработчик не может быть уверен в правильности написанного им кода до тех пор, пока не сработают абсолютно все тесты модулей разрабатываемой им системы. Тесты модулей (юнит-тесты) позволяют разработчикам убедиться в том, что каждый из них по отдельности работает корректно. Данные тесты помогают разработчикам понять, зачем нужен тот или иной фрагмент кода. Логика работы тестируемого кода становится понятной, так как видно, как он должен использоваться. Тесты модулей также позволяют разработчику без каких-либо опасений выполнять рефакторинг (refactoring). Кроме юнит-тестов, в соответствии с разработкой через тестирование, разрабатываются функциональные тесты. Функциональные тесты предназначены для тестирования функционирования логики, образуемой взаимодействием нескольких частей. Разрабатываемые функциональные тесты менее детальны, чем юнит-тесты, но затрагивают больший объём кода. Следовательно, у функциональных тестов возможность обнаружить какое-либо некорректное поведение программного кода больше, по сравнению с юнит-тестами. По этой причине, по мнению специалистов, в промышленном программировании написание функциональных тестов нередко имеет больший приоритет, чем написание юнит-тестов. Таким образом, в экстремальном программировании осуществляется возвратное тестирование (regression testing), которое предусматривает, не ухудшение качества при добавлении функциональности. Большинство ошибок исправляются на стадии кодирования. Тесты, в соответствии с технологией экстремального программирования, пишут сами программисты. Любой программист, входящий в команду разработчиков, имеет право написать тест для любого модуля. В соответствии с Test-driven development сначала пишется тест, который изначально не проходит, так как программного кода, который тест должен проверять, при написании теста не существует. Затем пишется программный код, необходимый для того, чтобы тест прошел. По мнению специалистов, использующих данную технологию, TDD, позволяет писать код, более удобный в использовании, потому что при написании теста, когда программного кода ещё нет, проще позаботиться об удобстве будущей системы. Используя разработку через тестирование, в каждый момент времени, выполнив все тесты, разработчик можем считать, что система работает так, как от нее ожидают. Важной особенностью является то, что неукоснительное соблюдение принципа TDD гарантирует, что любая часть функциональности системы покрывается тестами. Характерно, что такой подход ускоряет разработку программного продукта. Это связано с тем, что знание того, что нужно сделать, и, требуемого объема работ, позволят сэкономить время, отказавшись от реализации невостребованных в данный момент деталей. Основной прием экстремального программирования, который называется «Игра в планирование (Planning game)». Основная цель игры в планирование заключается в том, чтобы быстро сформировать приблизительный план работы и постоянно обновлять его по мере того, как условия задачи становятся всё более чёткими. Суть данного приема состоит в следующем. Вся команда собирается вместе, принимается коллективное решение о том, какие функции системы будут реализованы в ближайшей итерации. Набор свойств определяется пользовательскими историями (user story). Трудоемкость каждого свойства определяется самими программистами. На данной стадии разработчики обсуждают с заказчиком его требования к системе. Как правило, заказчик весьма смутно представляет конечную цель. Задача разработчиков вытащить из заказчика всю необходимую информацию. Прежде всего, человек, с которым общается разработчик, должен быть профессионалом, знающим предметную область, для которой пишется программный продукт. Очевидно, что попытки обсуждать с генеральным директором программу для бухгалтерии обречены на провал. Человек должен разбираться в проблемах, стоящих перед ними, и в том, как они хотели бы их решить с помощью обсуждаемого ПО. Обсуждение идет по принципу «от крупного к мелкому». Сначала обсуждается задача в общих чертах, потом она разбивается на подзадачи. И так далее. Целесообразно остановиться, когда каждая задача займет ориентировочно один день разработки. Когда все требования таким образом сформированы, целесообразно зафиксировать данные требования в письменном виде. Таким образом исключаются дальнейшие разногласия. После этого, заказчик определяет приоритеты. Причем приоритеты могут включать части различных задач. В этом случае задачи разбиваются на подзадачи. В соответствии с определенными приоритетами формируется очередность выполнения задач. После того, как приоритеты расставлены производится временная оценка. При выполнении временной оценки необходимо учитывать следующие особенности. Во-первых, затраты времени на задачу корректно может оценивать лишь тот, кто будет ею непосредственно заниматься. Это связано с тем, что каждый человек индивидуален.  Один разработчик может сделать задачу быстрее, другой разработчик сделает задачу за более долгий срок.  Причем, точная оценка временных затрат при обсуждении задач с заказчиком сделана быть не может. Во-вторых, разработчики работают в разных ситуациях. В одном случае разработчик может целый день не отрываться от задачи. В другой ситуации, разработчик может половину дня потратить на консультации других разработчиков, исследования и т.п. Заранее предсказать ситуации не всегда возможно. Как правило, на разработку из-за отвлекающих факторов тратится больше времени, чем было предусмотрено изначально. Потому в XP принято понятие «идеальное время». Под идеальным временем понимается оценка работы при условии, что разработчик будет сконцентрирован исключительно на задаче, что его ничто не будет отвлекать, что он будет работать с максимальной продуктивностью. Время, потраченное на разработку в действительности, называется «реальным временем». Отношение этих времен, усредненное за определенный промежуток времени (например, за 8 циклов разработки), называется коэффициентом загрузки (load factor). Таким образом, разработчики оценивают идеальное время выполнения задачи, после чего, умножив его на коэффициент загрузки, можно получить реальную оценку выполнения задачи. И именно эта оценка должны фигурировать в описании задачи. Принято считать, что коэффициент загрузки в начале работы команды равен 3. После того, как команда уже втянулась в проект, скорость разработки начинает повышаться. Для профессиональной команды, хорошо сработавшейся друг с другом и с заказчиком, коэффициент загрузки по мнению экспертов примерно равен 1.7-1.8. После того, как расставлены приоритеты и выполнена временная оценка, обсуждаются все детали, касающиеся разработки. Такое обсуждение заставляет заказчика продумать до мелочей его требования к системе. Следовательно, сильно уменьшается вероятность того, через какое-то время, заказчик поменяет свои требования на противоположные. Кроме того, часто оказывается, что часть изначальных требований заказчику не нужна, а нужно ему что-то совсем другое. Если бы заказчик, следуя обычной технологии, написал техническое задание, а потом бы его реализовали, то пришлось бы переделывать очень много. В случае же технологией экстремального программирования заказчик с гораздо большей вероятностью получает именно то, что он хочет. Характерно, что при реализации Planning game, если какая-то функциональность вызвала затруднения в реализации и все, что запланировано, не удается реализовать, то сокращается объем реализуемой функциональности. Следовательно, не отодвигается срок выполнения, а уменьшается функциональность. В этом случае, убирается из запланированной функциональности то, что считается наименее критичным. Решить вопрос об уменьшении функциональности должен заказчик. Примечательно, что часть функциональности, таким образом, вообще отсеивается. Следовательно, данная функциональность изначально не была нужна. В результате использования приема реализации Planning game, разработчик получает четкий план работы на ближайшую версию. Таким образом, планирование нужно производить для каждой версии, для того, чтобы скорректировать оценки, основываясь на текущем положении вещей. Основной прием экстремального программирования, который называется «Заказчик всегда рядом (Whole team, Onsite customer)». Данный прием основан на той особенности, что каким бы тщательным ни было планирование, некоторые вопросы все равно всплывут непосредственно в процессе реализации. Программист изначально не может знать особенности требований заказчика. Следовательно, самым простым способом решать возникшие вопросы заключается в возможности задать данные вопросы непосредственно заказчику. Таким образом, насколько быстро и полно разработчик пообщается с заказчиком, зависит скорость реализации задачи. Часто имеющийся вопрос блокирует дальнейшую работу. Следовательно, разработчик программного продукта будет простаивать. В этом случае, варианты общения через электронную почту или телефон не являются эффективным выходом. Письмо может быть прочитано не сразу.  По телефону затруднительно описать схему или картинку. Кроме того, может не иметь времени или возможности своевременно ответить на заданный вопрос. Таким образом, для достижения максимальной скорости разработки представитель заказчика должен в период работы над системой находится в команде разработчиков. Причем требования к квалификации представителя заказчика являются достаточно высокими. В том случае, если заказчик не согласился предоставить своего представителя достаточно высокой квалификации, то проект попадает в группу высокого риска. Если привлечь заказчика или его представителя не удается, то иногда оказывается целесообразным временный наем специалиста в разрабатываемой области. Такой шаг сократит неясности в работе, повысит скорость разработки и приблизит проект к тому, что желает получить заказчик. При реализации приема «Заказчик всегда рядом» необходимо учитывать, что в экстремальном программировании заказчиком считается не тот, кто оплачивает счета, а конечный пользователь программного продукта. Кроме того, как правило, существует большая разница между тем, что в действительности нужно заказчику, и тем, что заказчик себе представляет. Следовательно, своевременное выяснение подробностей сбережет много сил, средств, времени и нервов. Основной прием экстремального программирования, который называется «Парное программирование (pair programming)». Парное программирование предполагает, что весь код создается парами программистов, работающих за одним компьютером. Один из программистов работает непосредственно с текстом программы, другой программист просматривает за работой первого программиста. При необходимости клавиатура свободно передаётся от одного программиста к другому программисту. В течение работы над проектом пары программистов не фиксированы. В соответствии с технологией экстремального программирования, рекомендуется менять состав пар, чтобы каждый программист в команде имел достаточное представление о всей разрабатываемой системе. Следовательно, необходимо размещать группу программистов в одном месте. По-видимому, легче всего это сделать на территории заказчика.  Таким образом, парное программирование не только повышает качество кода, но и обеспечивает более тесное общение, неявную передачу знаний, более эффективное использование рабочего времени, позволяет выявлять глобальные ошибки на ранних стадиях. Важной особенностью парного программирования является то, что каждый человек мыслит по-своему.  Следовательно, при возникновении проблемы существует большая вероятность, что каждый из программистов разные варианты решения проблемы. Таким образом, появляется возможность выбрать наиболее оптимальный вариант решения. Кроме того, возможно, что из двух вариантов решения будет сформирован один, который будет включать лучшие элементы каждого из предложенных вариантов.  Очевидно, что при таком подходе оптимальность и ясность программного кода резко возрастает. Соответственно, падает количество ошибок. Другое преимущество парного программирования, заключается в том, что при написании программного кода вдвоем, данный код досконально знают оба программиста. Таким образом, знания о работе кода лучше сохраняется.  В том случае, когда программный код пишет один программист, потеря программного кода представляет серьезную проблему. Третье преимущество парного программирования, заключается в том, что при работе в паре разработчики, фактически, подстегивают друг друга. В результате этого повышается скорость работы каждого из них. Однако, соответственно, возрастает нагрузка, которую не каждый человек может выдержать.  Для снижения нагрузки, можно применять параллельное программирование. Параллельное программирование отличается от парного программирования тем, что разработчики работают над одной задачей на двух компьютерах, расположенных рядом. В этом случае, у программистов сохраняется возможность совместного обсуждения задачи. Но даже это способно дать лучший эффект, чем программирование порознь. Важно отметить, что исследования парного программирования показывают, что затраты на разработку программного продукта при использовании парного программирования за счет экономии времени разработки остаются приблизительно на том же уровне, что и при традиционных технологиях. Следовательно, получается, что затраты на разработку одни и те же, однако качество программного кода и скорость работы заметно повышается. Основной прием экстремального программирования, который называется «Непрерывная интеграция (Continuous Integration)» В традиционных методиках интеграция, как правило, выполняется в самом конце работы над продуктом, когда считается, что все составные части разрабатываемой системы полностью готовы. В экстремальном программировании интеграция кода всей системы выполняется несколько раз в день, после того, как разработчики убедились в том, что все тесты модулей корректно срабатывают. Такой подход позволяет быть уверенным, что программный продукт не сломан последними изменениями. Следовательно, появляется возможность быстро отреагировать на возникающие проблемы. По мнению разработчиков технологии экстремального программирования, интеграция новых частей системы должна происходить как можно чаще. Принципиально важно, что интеграцию можно производить исключительно в том случае, если все юнит-тесты проходят успешно. Если юнит-тесты не проходят, то программист должен предварительно внести исправления в программный код модуля и лишь затем интегрировать составные части системы. Существует правило, что, если в созданной части системы имеется хотя бы одна ошибка, то интеграцию производить нельзя. Таким образом, частая интеграция позволяет быстрее получить готовую систему. Не маловажно то, что при постоянной интеграции кода есть уверенность в том, что в любое время можно взять программный код, и система будет работать. Основной прием экстремального программирования, который называется «Рефакторинг (Refactoring)» Рефакторинг или реорганизация программного кода представляет собой процесс изменения внутренней структуры программы, не затрагивающий её внешнего поведения и имеющий целью облегчить понимание её работы. В основе рефакторинга лежит последовательность небольших эквивалентных преобразований. Поскольку каждое преобразование маленькое, программисту легче проследить за его правильностью. С другой стороны, вся последовательность может привести к существенной перестройке программы и улучшению её согласованности и четкости. При выполнении рефакторинга реализуется постоянная работа по упрощению кода. Сохраняя код прозрачным и определяя его элементы всего один раз, программисты сокращают число ошибок, которые впоследствии придется устранять. При реализации каждого нового свойства системы программист должен подумать над тем, можно ли упростить существующий код и как это поможет реализовать новое свойство. Кроме того, нельзя совмещать рефакторинг с разработкой нового кода. Если создается новый код, то рефакторинг необходимо отложить. Следует учитывать, что программное обеспечение очень быстро развивается. Следовательно, невозможно предугадать, что понадобится через год. Попытки реализовать будущие потребности могут привести к тому, что будет реализовано очень много того, что с большой вероятностью не понадобится. Разумеется, задел на будущее необходим, но он не должен быть слишком большим. Естественно, что через некоторое время появятся новые требования к программному продукту. В этом случае, наиболее разумным вариантом является переработка старого решения таким образом, чтобы имеющееся решение отвечало новым требованиям. В основном рефакторинг является следствием эволюции системы, то есть ее естественного развития. Рефакторинги жизненно необходимы в любой эволюционирующей системе. Особенно важны рефакторинги при использовании технологии экстремального программирования, которая изначально ориентирована на гибкую разработку. Переработка кода позволяет адекватно и немедленно реагировать на каждое изменение. Рефакторниг представляет собой мощный инструмент обеспечения качества программы. Основной прием экстремального программирования, который называется «Частые небольшие релизы (Small Releases)» Версии (releases) продукта должны поступать в эксплуатацию как можно чаще. Работа над каждой версией должна занимать как можно меньше времени. При этом каждая версия должна быть достаточно осмысленной с точки зрения полезности для пользователя. Чем раньше выпускается первая рабочая версия продукта, тем раньше заказчик начинает получать за счёт неё дополнительную прибыль. Следует помнить, что деньги, заработанные сегодня, стоят дороже, чем деньги, заработанные завтра. Чем раньше заказчик приступит к эксплуатации продукта, тем раньше разработчики получат от него информацию о том, что соответствует требованиям заказчика. Эта информация может оказаться чрезвычайно полезной при планировании следующего выпуска. Ни один аналитик, даже самый квалифицированный, не поймет потребности заказчика лучше, чем сам заказчик, после того, как попользуется готовым продуктом некоторое время. Таким образом, если выпустить очередную версию быстрее, то у заказчика появится возможность определиться со своими потребностями раньше. При реализации экстремального программирования, разрабатываемую систему запускают в эксплуатацию не дожидаясь окончательного разрешения всех поставленных проблем. Периодичность выпуска новых версий может в значительной степени варьироваться. Полностью протестировать систему за данный период не всегда получается. Таким образом, заказчик фактически выступает в роли бета-тестера. Важно, что в случае экстремального программирования тестирование оконченной версии и проработка технического задания для следующей версии происходит одновременно с разработкой текущей версии. В том случае, если получается так, что разработчики не успевают закончить в очередном релизе все, что запланировано, то необходимо сократить объем функциональности, но не переносить выпуск очередной версии. В случае переноса выпуска очередного релиза, новый релиз будет затягиваться, раздуваться, и его будет сложнее тестировать. Единственный случай, когда релиз может быть перенесен это ситуация, когда переноса срока требуют тестировщики. Выпустить продукт, содержащий ошибки, является худшим вариантом, чем перенос срока выпуска очередного релиза. Основной прием экстремального программирования, который называется «Простота (Simple design)» Технология экстремального программирование исходит из того, что в процессе работы условия задачи могут неоднократно измениться. Следовательно, доработку проекта необходимо выполнять постоянно в течение всего времени работы над проектом. В каждый момент времени следует пытаться использовать наиболее простое решение текущей задачи, и менять решение по мере того, как условия задачи меняются. Очевидно, что простую программу легче поддерживать, в нее легче вносить изменения, она менее подвержена ошибкам. Принимается первое наипростейшее работающее решение и реализуется необходимый уровень функциональности на данный момент. Для этого, необходимо писать просто, но при этом качественно. Как было доказано ещё при разработки технологии структурного программирования, сложность написанного программного кода не является признаком профессионализма. Прием “Simple design” неразрывно связано с основным приемом рефакторинга. Если писать просто, но не корректировать систему под текущие требования, то результат не будет хорошим. Если корректировать, но писать при этом очень сложно, то также хорошего результата достичь не удастся. Таким образом, если писать просто, и постоянно при этом корректировать программный код, то можно достичь требуемого результата. Основной прием экстремального программирования, который называется «Метафора системы (System metaphor)» Метафора системы (system metaphor) дает представление о компонентах системы и их взаимосвязях между собой. Метафора системы даёт разработчикам возможность понять, каким образом система работает в настоящее время, и в каких местах необходимо добавить новые компоненты. Общий вид системы определяется при помощи метафоры или набора метафор, над которыми совместно работают заказчик и программисты. С помощью метафоры системы, экстремальное программирование обеспечивает программистов простым, но эффективным инструментарием для освоения разрабатываемой системы. В частности, первое представление о системе может быть получено посредством метафоры. Основной прием экстремального программирования, который называется «Коллективное владение кодом (Collective code ownership) или выбранными шаблонами проектирования (Collective patterns ownership)» Коллективное владение кодом означает, что каждый член команды несёт ответственность за весь исходный код. Таким образом, каждый член команды вправе вносить изменения в любой участок программы. Парное программирование поддерживает возможность коллективного владения кодом. Работая в разных парах, все программисты знакомятся со всеми частями кода системы. Важное преимущество коллективного владения кодом заключается в том, что данный прием ускоряет процесс разработки. Очевидно, что при появлении ошибки данную ошибку может устранить любой программист из команды. Таким образом, автором программного кода является вся команда разработчиков. Однако следует учитывать, что право каждого программиста изменять исходный код ведёт к риску появления ошибок, вносимых программистами. Может возникнуть ситуация, что программист считает, что он знают, что делает, однако не рассматривает некоторые зависимости. Данная проблема решается при помощи использования юнит-тестов, которые позволяют выявить возникающие ошибки. При использовании технологии экстремального программирования существует четкое правило, по которому автор изменений ответственен за приведение кода в рабочее состояние. Причем разработчик не имеет права заниматься чем-либо другим до тех пора, пока не исправит внесенные им ошибки. Основной прием экстремального программирования, который называется «Стандарты кодирования (Coding standard or Coding conventions)» Все члены команды в ходе работы должны соблюдать требования общих стандартов кодирования. При использовании технологии экстремального программирования команда разработчиков формирует набор правил кодирования, которым должен следовать каждый член команды. Перечень правил не является исчерпывающим или слишком большим. Задача состоит в том, чтобы сформулировать общие указания, благодаря которым код станет понятным для каждого из членов команды. Стандарт кодирования поначалу должен быть простым, затем он может постепенно усложняться по мере наработки опыта группой разработчиков. Таким образом, не целесообразно тратить слишком много времени на предварительную разработку стандарта. Стандарты кодирования нужны для обеспечения других основных приемов экстремального программирования, таких как, коллективное владение кодом, парное программирования и рефакторинг. Без единого стандарта выполнять эти приемы экстремального программирования практически невозможно, так как команда программистов будет работать в режиме постоянной нехватки времени. Следует обратить внимание на то, что детальные стандарты не требуются. Целесообразно стандартизировать исключительно важные аспекты. Причем, определение наиболее важных аспектов стандартизации в XP субъективно. Основной прием экстремального программирования, который называется «Социальная защищенность программиста (Programmer welfare, Sustainable pace)». Социальная защищенность программиста, с точки зрения экстремального программирования, включает, во-первых, «Programmer welfare», т.е. комфортные условия труда программиста; во-вторых, «Sustainable pace», т.е. достойную оплату. Опыт работы программистов показывает, что программист, ради дела способен на многое. Если надо, то программист может задержаться на работе; выйти на работу в выходные; отказаться от отпуска; несколько суток не спать, сидя за клавиатурой. Однако технология экстремального программирования категорически против такого самопожертвования и нарушения принятых норм трудового права. Данный подход продиктован, в первую очередь, необходимостью повышения эффективности работы и строгой организации. Технология экстремального программирования рассчитана на слаженную работу всей команды разработчиков. Очевидно, что эффективное применение такого приема экстремального программирования, как, например, парное программирование, возможно лишь при синхронизации эффективности работы обоих членов пары. Очевидно, что такая синхронизация невозможна, если один программист из пары будет приходить на работу к девяти часам, а второй программист к двенадцати часам. Однако главное заключается в том, что человеку, чтобы сохранить здоровье и работоспособность, необходим полноценный отдых. Во многих западных фирмах поздний уход с работы расценивается как неуспеваемость или неспособность правильно распорядиться своим рабочим временем.