Екстремальне програмування

Размещено на http://www.allbest.ru

Размещено на http://www.allbest.ru

Реферат

Екстремальне програмування

Зміст

Вступ

Стратегія планування

Часта зміна версій

Метафора системи

Найпростіший дизайн та прості проектні рішення

Розробка на основі тестування

Постійна переробка

Програмування парами

Колективне володіння кодом

Постійно триваюча інтеграція

Включення замовника в команду

Стандарти кодування

Переваги та недоліки

Література

Вступ

Екстремальне програмування (Extreme Programming, ХР) - це спрощена методика організації виробництва для невеликих та середніх за кількістю спеціалістів команд, які займаються розробкою програмного продукту в умовах неясних чи змінних вимог.

Ця методика отримала свою назву тому, що вона доводить використання багатьох загальноприйнятих та широко використовуваних принципів програмування до екстремального рівня.

Використовуючи дуже коротки цикли розробки XP пропонує швидкий, реальний і постійний зворотний зв'язок.

У рамках XP використовується гнучкий графік реалізації
функціональностей, завдяки чому поліпшується реакція на зміну вимог замовника.

XP базується на обміні інформацією, тестах і вихідному коді. Три цих інструменти використовуються для обміну відомостями про структуру системи та її поведінку.

XP базується на автоматичних тестах, розроблених як програмістами, так і замовниками. Завдяки цим тестам вдається стежити за процесом розробки, забезпечувати коректне еволюціонування системи і без зволікання виявляти всі існуючі дефекти системи.

У рамках XP використовується поступове планування, в результаті чого загальний план проекту виникає досить швидко, але цей план еволюціонує протягом усього часу життя проекту.

XP базується на процесі еволюціонування дизайну, який триває стількі, скільки існує сама система.

Методика XP призначена для роботи над проектами, над якими можуть працювати від двох до десяти програмістів, у яких вся необхідна робота, пов'язана з тестуванням, може бути виконана протягом одного дня.

Стратегія планування

Планування - це процес припущення, як буде виглядати процес розробки програмного продукту для замовника. Його завдання - як найшвидше визначити обсяг робіт, які потрібно зробити до наступної версії програмного забезпечення. Рішення приймається, в першу чергу, наоснові пріоритетів замовника (тобто його потреб, того, що потрібно йому від системи для більш успішного ведення свого бізнесу) і, в другу,на основі технічних оцінок (тобто оцінок трудомісткості розробки , сумісності з іншими елементами системи та ін.) Плани змінюються, як тільки вони починають розходитися з дійсністю чи побажаннями замовника. Впродовж процесу плануванння визначається список задач, які необхідно реалізувати в наступній версії продукту:

Визначається обсяг робіт - потрібно визначити, якого обсягу буде недостатньо і який обсяг буде надмірним.

Визначити пріоритет - потрібно визначити, яку з можливостей реалізовувати першою.

Оцінка - визначити скільки часу потрібно, щоб реалізувати ту чи іншу можливість.

Детальний графік робіт - визначити, що повинно бути реалізованим в першу чергу в рамках роботи над черговою версією продукту.

Терміни випуску версій - визначити, в які важливі дати чергові версії програмного продукту повинні з'являтися у виробництві.

Процес - визначити, як буде організована команда розробників і як буде організована робота цієї команди.

Частота зміна версій

Найперша працююча версія повинна з'явитися якомога швидше і тут же повинна почати використовуватися. Наступні версії готуються через досить короткі проміжки часу (від декількох годин при невеликих змінах в невеликій програмі, до місяця-двох при серйозній переробці великої системи).

Кожна версія має бути настільки маленькою, наскільки це можливо. У ній мають бути реалізовані найбільш цінні для замовника вимоги. Загалом версія повинна бути логічно завершеною і працездатною. Ми не можемо реалізувати деяку можливість тільки наполовину і впровадити її у виробництво тільки для того, щоб скоротити час роботи над версією.

Краще планувати на місяць або два вперед, ніж планувати на півроку або рік вперед. Компанія, яка за один раз передає в руки замовника досить великий програмний продукт, не може випускати чергові версії цього продукту досить часто. Ця компанія повинна скоротити час роботи над черговою версією настільки, наскільки це можливо.

Метафора системи

Кожен програмний проект ХР направляється за допомогою єдиної метафори. У XP метафора багато в чому заміняє собою те, що інші люди називають терміном «архітектура». Проблема полягає в тому, що архітектура - це, як правило, величезна за розмірами схема системи, яка не дає уявлення про її цілісність. Архітектура - це великі прямокутники та з'єднання між ними.

Архітектура формується для того, щоб ми могли надати кожному учаснику проекту зв'язну історію про будову і функціонування системи. Ця історія повинна бути викладена мовою, зрозумілою як програмістам, так і бізнесменам. В рамках цієї історії буде здійснюватися робота над проектом. Запитавши про метафору, ми отримуємо у відповідь відомості про архітектуру, причому ці відомості передаються нам в такій формі, яка є зручною для спілкування та обдумування.

Найпростіший дизайн та прості проектні рішення

У кожен момент часу система повинна бути сконструйована настільки просто, наскільки це можливо. Не треба додавати функції заздалегідь - тільки після явної прохання про це. Вся зайва складність віддаляється, як тільки виявляється.

У кожен момент часу правильним є дизайн системи, в рамках якого:

Виконуються всі тести.

Немає дублюючої логіки.

Виражається кожна з ідей, важливих для програмістів.

Існує найменша можлива кількість класів і методів.

Кожен фрагмент дизайну системи повинен довести своє право на існування на підставі всіх перерахованих правил. Простий дизайн програмної системи можна сформувати так: приберіть із системи усі елементи, які можите прибрати, не порушуючи при цьому правил 1-3.

Розробка на основі тестування

Будь-яка можливість програми, для якої немає автоматичних тестів, просто не існує. Програмісти пишуть тести модулів, завдяки чому їхня впевненість у правильності функціонування програми стає частиною самої програми. Замовники пишуть функціональні тести, завдяки чому їхня впевненість у функціонуванні програми також стає частиною програми. В результаті загальна впевненість в працездатності програми з часом все зростає і зростає. Ця впевненість виражена в наборі тестів, кількість яких збільшується і які продовжують функціонувати в міру продовження роботи над програмою. Завдяки цьому з часом програма стає не менш, а більш пристосованою для внесення до неї змін.

Немає необхідності писати тести для кожного розроблювального нами методу, перевіряти треба тільки виробничі методи, які можуть не спрацювати. Іноді ми витрачаємо зусилля тільки на те, щоб зрозуміти, чи можливо в процесі функціонування коду виникнення тієї чи іншої ситуації. Протягом півгодини ми аналізуємо код. Так, це можливо. Тепер ми відкидаємо код і починаємо писати його заново - починаючи з тестів.

Постійна переробка

Коли програмісти приступають до реалізації деякої можливості програми, вони завжди задаються питанням, чи існує спосіб зміни наявної програми для того, щоб спростити додавання в неї необхідної нової можливості? Після того як можливість додана, програмісти запитують себе, чи можна тепер спростити програму і при цьому забезпечити виконання всіх тестів? Це і називається переробкою коду.

Це означає, що іноді нам треба зробити більше роботи, ніж це насправді необхідно для того, щоб додати в програму нову можливість. Проте, працюючи в цьому ключі, забезпечується зниження витрат, пов'язаних з додаванням до програми подальших можливостей. Переробивши код, ми спрощуємо його подальшу модернізацію. Ми не виконуємо переробку виходячи з попередніх нечітких міркувань, навпаки, переробляємо код тоді, коли система має потребу в цьому. Коли при додаванні нової можливості дублюється код, це означає, що система просить нас виконати переробку.

Якщо програміст бачить деякий `черновий' спосіб забезпечити виконання теста, для реалізації якого потрібна одна хвилина, але крім цього, він також бічить інший, більш елегантнтй спосіб забезпечити виконання тесту, передбачаючий також спрощення дизайну, але для реалізації якого потрібно десять хвилин, програміст має обрати другий спосіб. На щастя, в рамках ХР ви маєте можливість вносити в дизайн системи будь-які, навіть найрадикальніші зміни, роблячи це невиликими, малоризикованими кроками.

Програмісти постійно переробляють систему для усунення зайвої складності, збільшення зрозумілості коду, підвищення його гнучкості, але без змін в його поведінці, що перевіряється прогоном після кожної переробки тестів. Прицьому перевага віддається більш елегантним і гнучким рішенням, у порівнянні з просто дають потрібний результат. Невдало перероблені компоненти повинні виявлятися при виконанні тестів і відкочуватися до останнього цілісного стану (разом з залежними від них компонентами).

Програмування парами

Весь код системи аж до її впровадження у виробництво пишеться парами програмістів, кожна з яких працює на одному комп'ютері, з однією клавіатурою і однією мишею.

У кожній парі існують дві ролі. Один партнер, в руках якого знаходиться клавіатура і миша, думає про те, як прямо зараз реалізувати певний метод найкращим чином. Другий партнер думає більш стратегічно:

Чи спрацює використовуваний підхід в цілому?

Якими можуть бути інші, ще не розглянуті тестові випадки?

Чи існують які-небудь способи спростити всю систему таким чином, щоб поточна проблема просто зникла?

Склад пар змінюється динамічно. Партнери, які вранці входили до складу однієї пари, пізніше можуть стати членами зовсім інших пар.

Колективне володіння кодом

Будь-який член команди, який бачить можливість додати що-небудь у будь-який розділ коду системи, може зробити це в будь-який відповідний для цього момент часу.

Колективне володіння краще, ніж наприклад повна вісутність володіння чи індивідуалене володіння. Раніше різними шматками коду программи ніхто не володів. Будь-хто мігзмінити код за своїм бажанням. Результатом був хаос.

Щоб краще володіти ситуацією, програмісти стали використовувати індивідуальне володіння кодом. Єдиною людиною, хто мав право змінювати код, був офіціальний власник коду. Якщо хто-небудь інший бажав внести зміни в деякий фрагмент коду, він мав звернутися з проханням до власника коду. В результаті цей підхід став набувати бюрократичного виду - програмісти почали уникати звертатися до власника коду, замість цього вони працювали з тим що є.

У рамках XP відповідальність за весь код системи лежить на всіх членах команди. Не можна сказати, що кожен добре знає кожну частину коду, проте можна сказати, що кожен знає, принаймні щось про кожну частину. Якщо пара програмістів працює над розв'язанням деякої задачі і бачить, що для спрощення роботи потрібно внести модифікації в деяку частину коду, тим самим поліпшивши цей код, зміни вносяться негайно, завдяки чому завдання цієї пари спрощується.

Постійно триваюча інтеграція

Код інтегрується і тестується кожну годину, мінімум один раз в день. Для того щоб забезпечити це, простіше за все виділити для цієї мети окремий комп'ютер. Коли цей комп'ютер звільняється, пара, яка має код, який підлягає інтеграції, сідає за інтеграційний комп'ютер, завантажує поточну версію системи, додає до неї свої власні зміни (перевіряючи і усуваючи будь-які невідповідності і конфлікти) і запускає тести до тих пір, поки всі вони не спрацюють.

Інтеграція одного набору змін за один раз відмінно спрацьовує, оскільки стає очевидним, хто саме повинен виправити тест, який не спрацював, - ми повинні, так як, мабуть, саме ми його зламали. Це пов'язано з тим, що попередня пара, яка виконувала інтеграцію, домоглася спрацьовування всіх 100% тестів. І якщо ми не доб'ємося спрацювання всіх 100% тестів, ми повинні викинути з системи все, що написали, і почати розв'язувати задачу заново, оскільки очевидно, що в цьому випадку, приступаючи до розв'язку, ми просто не знали всього того, що потрібно для розробки необхідного коду.

Включення замовника в команду

Для відповідей на запитання, вирішення суперечок та встановлення дрібномасштабних пріоритетів поруч з командою розробників повинен постійно перебувати реальний замовник. Під терміном «реальний замовник» мається на увазі людина, яка дійсно буде користуватися системою, коли ця система працюватиме у виробничих умовах.

Основною перешкодою для втілення цього правила є та обставина, що реальні користувачі майбутньої системи обходяться для замовника занадто дорого в сенсі робочого часу. Інколи менеджерам замовника шкодажертвувати одним із службовців компанії тількі для того, щобвін постійно знаходився разом з розробниками та відповідав на їх питання. Менеджерам потрібно вирішити що важливіше - прискорення та підвищення якості розробки фбо робочий час одного аба двух процівників.

Недоліком такого підходу є те, що у випадку, якщо проект таки помирає, то сотні годин, які працівник підприємства-замовника витратив на допомогу та консультації розробників, виявляються часом, витраченим даремно. XP робить все можливе для того, щоб проект не вмирав.

Стандарти кодування

Якщо ми збираємося перекидати програмістів з розробки однієї частини системи на розробку іншої частини системи, забезпечувати постійну зміну партнерів в парах по кілька разів на день, забезпечувати постійну переробку коду програмістами, які цей код не писали, ми просто не можемо дозволити собі використовувати в рамках одного проекту застосування кількох різних стилів кодування. Через деякий час роботи над системою вже не можна буде сказати точно, який саме член команди написав той чи інший код.

Стандарт повинен вимагати від розробників програми мінімально можливих зусиль для реалізації тієї чи іншої можливості. Він має сприяти втіленню на практиці правила трьох О - Once and Only Once (заборона на дублювання коду). Стандарт повинен сприяти комунікації. Нарешті, стандарт має бути добровільно сприйнятий всією командою розробників.

Переваги та недоліки

програма тестування код команда

Велика гнучкість

Можливість швидко і акуратно вносити зміни в ПО у відповідь на зміни вимог і окремі побажання замовників

Нижча вартість

Нездійсненність в такому стилі досить великих і складних проектів

Неможливість планувати терміни і трудомісткість проекту на досить довгу перспективу і чітко передбачити результати тривалого проекту в термінах співвідношення якості результату і витрат часу і ресурсів

Непристосованість XP для тих випадків, в яких можливі рішення не знаходяться відразу наоснові раніше отриманого досвіду, а вимагають проведення попередніх досліджень

Ризик збою у робочому процесі обслуговування клиентів

Ризик наслідків від неправильного рішення

Ризик отримати не те що замовляли

Програмування парами - непотрібне витрачання людських ресурсів

Література

Кент Бек: Экстремальное программирование - Питер, 2002.

Кент Бек, Мартин Фаулер: Экстремальное программирование: планирование - Питер, 2003.

Кент Бек: Экстремальное программирование: разработка через тестирование - Питер, 2003.

Кен Ауэр, Рой Миллер: Экстремальное программирование: постановка процесса с первых шагов и до победного конца - Питер, 2003.

Размещено на www.allbest.