Екстремальне програмування - або, скорочено, XP (eXtreme Programming) - є відповіддю співтовариства програмістів на настання формальних підходів до створення програмних продуктів і покликане повернути в середу розробників дух творчості.

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

Протистояти тиску формалізму в роботі програмістів покликана ініціатива групи розробників, які об'єдналися під гаслом Екстремального Програмування, або XP.

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

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

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

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

Екстремальний цикл

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

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

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

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

Методологія розробки програмного забезпечення eXtreme Programming(винахідник - Kent Beck) отримує все більше визнання завдяки максимальному спрощенню процесів проектування і безпосередньої розробки програмних продуктів у середовищі з вимогами, що швидко змінюються.

Існує лише 5 цінностей екстремального програмування: простота, спілкування, зворотний зв'язок, сміливість і повага ("повага" додалося в останній редакції XP). На реалізацію цих основних цінностей і спрямовано 12 практичних методик XP. Розглянемо їх у невеликому наближенні. Крім відомих багатьом істин, додам свої коментарі з приводу практик, ґрунтуючись на своєму практичному досвіді.

Процес планування (planning game).У XP планування – це основна частина розробки. Те, що плани можуть раптово змінитись, враховується ще на самому початку. Апетит замовника приходить під час їди і потрібно завжди тримати ситуацію під контролем. Спілкування із замовником має відбуватися якнайчастіше. Це дозволить точніше оцінити терміни виконання завдань та внести необхідні корективи у разі потреби.

Швидкий випуск версій (Small Releases).Як би красиво не був описаний продукт, всю красу його використання можна зрозуміти тільки працюючи з ним. Методика швидкого випуску версій дозволяє зрозуміти, чого хоче замовник, забезпечуючи ранній випуск робочих версій продукту.

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

Метафора (metaphor).Людині набагато легше запам'ятати відмінності між двома подібними предметами, ніж знати будову предмета повністю. Методика метафора пропонує порівнювати систему (або один з її модулів) з її аналогами для зручності спілкування всередині команди та глибшого розуміння системи загалом.

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

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

Випереджаюче тестування (test-driven development).Екстремальне програмування рекомендує перевіряти існуючий код якнайчастіше. Саме тому і практикується ця методика. Тести пишуться ще до того, як буде написано шмат коду. Це дозволяє краще розуміти поставлені завдання та надає можливість перевірити код одразу, як тільки він буде написаний.

Коментар: Такий підхід має масу плюсів.

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

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

По-третє, тести посилюють впевненість програмістів у собі, коли вони виникає бажання зробити рефакторинг.

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

Коментар: Не забувайте про цінність "сміливість" і не бійтеся поламати систему під час рефакторингу. Тести покажуть, що зламалося, і ви швидко виправите помилки. Навіть якщо тести не покривали деякі аспекти, і ви не помітите якісь потенційні проблеми – нічого страшного, все завжди можна виправити. Головне, що дизайн системи став простіше і зрозуміліше, а складна система - це джерело куди жахливіших помилок, ніж помилки, що виникли в результаті рефакторингу.

Парне програмування (pair programming).Періодичний перегляд чужого коду позитивно впливає його якість. Цей принцип є основою парного програмування. Полягає воно в тому, що два програмісти одночасно працюють за одним комп'ютером. Як не дивно, витрати на розробку не збільшуються вдвічі, а залишаються приблизно на тому ж рівні. З іншого боку, при парному програмуванні підвищується якість коду, здійснюється неявна і явна передача знань, а також відбувається постійне спілкування між розробниками.

Спільне володіння кодом (collective code ownership).Найчастіше розробки програмних продуктів за певну частину коду відповідає одна людина. Відпустка, звільнення або хвороба (вибач, Господи) одного з програмістів може сильно загальмувати розробку продукту. Саме тому в XP за один шматок коду відповідає не менше двох осіб і будь-який програміст може внести зміни до будь-якучастина програмного коду.

Продовжується інтеграція (continuous integration).Команди XP-програмістів створюють нові білди продукту кілька разів на день. Це дозволяє всім програмістам бути в курсі того, що відбувається, і запобігти проблемам інтеграції з іншими продуктами та частинами коду.

Коментар: У наш час ця практика у молодих фахівців викликає усмішку або навіть нерозуміння, адже є svn, perforce, cvs та ще багато чого. Це раніше двоє дядьків сідали біля головного комп'ютера і вручну мерзли з основною гілкою проекту.

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

40-годинний тиждень (forty hour week).Заради справи люди здатні багато на що, але екстремальне програмування категорично проти самопожертви розробників. Людина має відпочивати, саме тоді вона досягне максимальної продуктивності у робочий час.

Основні прийоми XP

Дванадцять основних прийомів екстремального програмування (за першим виданням книги Extreme programming explained) можуть бути об'єднані в чотири групи:

• Короткий цикл зворотного зв'язку (Fine scale feedback)
  • Розробка через тестування (Test driven development)
  • Гра у планування (Planning game)
  • Замовник завжди поряд (Whole team, Onsite customer)
  • Парне програмування (Pair programming)
• Безперервний, а не пакетний процес
  • Безперервна інтеграція (Continuous Integration)
  • Рефакторинг (Design Improvement, Refactor)
  • Часті невеликі релізи (Small Releases)
• Розуміння, що поділяється всіма
  • Простота (Simple design)
  • Метафора системи (System metaphor)
  • Колективне володіння кодом (Collective code ownership) або вибраними шаблонами проектування (Collective patterns ownership)
  • Стандарт кодування (Coding standard or Coding conventions)
• Соціальна захищеність програміста (Programmer welfare):
  • 40-годинний робочий тиждень (Sustainable pace, Forty hour week)

Тестування

У XP особлива увага приділяється двом різновидам тестування:

• тестування модулів (unit testing);
• приймальне тестування (acceptance testing).

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

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

Для XP пріоритетнішим є підхід, званий TDD (Test Driven Development) - спочатку пишеться тест, який не проходить, потім пишеться код, щоб тест пройшов, а вже після робиться рефакторинг коду.

Гра в планування

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

Замовник завжди поруч

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

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

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

Безперервна інтеграція

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

Рефакторинг

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

Часті невеликі релізи

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

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

Простота дизайну

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

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

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

Метафора системи (system metaphor) – це аналог того, що в більшості методик називається архітектурою. Метафора системи дає команді уявлення про те, яким чином система працює в даний час, в яких місцях додаються нові компоненти та яку форму вони мають набути.

Підбір хорошої метафори полегшує для групи розробників розуміння того, як влаштована система. Іноді це зробити не просто.

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

Усі члени команди в ході роботи повинні дотримуватись вимог загальних стандартів кодування. Завдяки цьому:

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

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

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

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

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

Література

• Кент Бек: Екстремальне програмування- Пітер, 2002, ISBN 5-94723-032-1.
• Кент Бек, Мартін Фаулер: Екстремальне програмування: планування- Пітер, 2003, ISBN 5-318-00111-4.
• Кент Бек: Екстремальне програмування: розробка через тестування- Пітер, 2003, ISBN 5-8046-0051-6.
• Кен Ауер, Рой Міллер: «Екстремальне програмування: постановка процесу з перших кроків і до переможного кінця» - Пітер, 2003, ISBN 5-318-00132-7.

Див. також

Посилання

• Ward Cunningham Wiki (англ.) – «передній край» XP.
• XProgramming.com (англ.) - сайт Рона Джеффріза: статті та ресурси з XP та суміжних питань, огляди книг.
• Extreme Programming: A gentle introduction (англ.) - "Ненав'язливе введення в XP" Дона Уеллса.
• MAXKIR.COM (укр.) - переклади статей батьків-засновників та ідеологів XP
• www.agiledev.ru (рус.) - Сайт гнучких методик розробки
• TopCoder (англ.) – змагання зі спортивного програмування
• Електронна бібліотечка книг з екстремального програмування (рус.)
• Екстремальне програмування - реальність та міфи (рус.)
• Тестування у світлі екстремального програмування. Частина 1 (рус.)
• IT та психологія. Людський фактор у парному програмуванні: чому багато хто не отримує бажаного від його впровадження? (рус.)

Розробка програмного забезпечення
Відомі діячі
Процес
Концепція
Напрями
Моделі розробки
Інші моделі
Інше

Wikimedia Foundation. 2010 .

Дивитись що таке "Екстремальне програмування" в інших словниках:

екстремальне програмування- одна з методологій розробки ПЗ. Тематика інформаційних технологій в цілому EN extreme programmingXP … Довідник технічного перекладача

Ця стаття має бути повністю переписана. На сторінці обговорення можна пояснити. Цей термін має й інші значення, див. Програми … Вікіпедія

Екстремальне управління проектами (англ. Extreme project management, XPM) метод управління дуже складними чи невизначеними проектами. Від традиційних методів керування проектами XPM відрізняється відкритим, гнучким та ... Вікіпедія

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

Присвячується Сінді: крилам моєї душі

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

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

ISBN 978-0321146533 англ.

ISBN 978-5-496-02570-6

© 2003 by Pearson Education, Inc.

© Переклад російською мовою ТОВ Видавництво «Пітер», 2017

© Видання російською мовою, оформлення ТОВ Видавництво «Пітер», 2017

© Серія «Бібліотека програміста», 2017

Передмова

Чистий код, який працює(clean code that works), – у цій короткій, але змістовній фразі, придуманій Роном Джеффрізом (Ron Jeffries), криється весь зміст методики розробки через тестування (Test-Driven Development, TDD). Чистий код, який працює, – це мета, якої варто прагнути тому, що

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

Дає шанс засвоїти уроки, які подає код. Якщо ви скористаєтеся першою ж ідеєю, яка спала на думку, у вас не буде шансу реалізувати другу, кращу ідею;

Поліпшує життя користувачів ваших програм;

Дозволяє вашим колегам розраховувати на вас, а вам розраховувати на них;

Писати такий код приємніше.

Але як отримати чистий код, який працює? Багато сил заважають нам отримати чистий код, а іноді не вдається навіть отримати код, який просто працює. Щоб позбутися багатьох проблем, ми розроблятимемо код, спираючись на автоматизоване тестування. Такий стиль програмування називається розробкою через тестування. Відповідно до цієї методики

Новий код пишеться тільки після того, як буде написано автоматичний тест, що завершується невдачею;

Будь-яке дублювання усувається.

Два простих правила, чи не так? Однак вони генерують складну індивідуальну та групову поведінку з безліччю технічних наслідків:

У процесі проектування ми постійно запускаємо код та отримуємо уявлення про його роботу, це допомагає приймати правильні рішення;

Ми самі пишемо тести, тому що не можемо чекати, що хтось інший напише для нас тести;

Наше середовище розробки повинне швидко реагувати на невеликі модифікації коду;

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

Два згадані правила TDD визначають порядок етапів програмування.

1. Червоний – напишіть невеликий тест, який не працює, а можливо навіть не компілюється.

2. Зелений – змусіть тест працювати якнайшвидше, при цьому не думайте про правильність дизайну та чистоту коду. Напишіть стільки коду, щоб тест спрацював.

3. Рефакторинг – усуньте з написаного коду будь-яке дублювання.

Червоний – зелений – рефакторинг – це мантра TDD.

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

При досить низькій щільності дефектів команда контролю якості (QA) зможе перейти від реагування на помилки до їх попередження;

Зі зменшенням кількості неприємних сюрпризів менеджери проекту зможуть точніше оцінити трудовитрати та залучити замовників до процесу розробки;

Якщо теми технічних дискусій будуть чітко визначені, програмісти зможуть взаємодіяти одне з одним постійно, а чи не щодня чи щотижня;

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

Отже, ідея проста, але в чому наш інтерес? Чому програміст має взяти на себе додатковий обов'язок писати автоматизовані випробування? Навіщо програмісту рухатися вперед малесенькими кроками, коли його мозок може продумати набагато складнішу структуру дизайну? Хоробрість.

Хоробрість

TDD – це спосіб управління страхом у процесі програмування. Я не маю на увазі страху падіння зі стільця або страху перед начальником. Я маю на увазі страх перед завданням, «настільки складним, що я поки що поняття не маю, як його вирішити». Біль – це коли природа каже нам: «Стоп!», а страх – це коли природа каже нам: «Будь обережним!» Обережність – це зовсім не погано, проте, крім користі, страх надає на нас деякий негативний вплив:

Страх змушує нас завчасно та ретельно обмірковувати, до чого може привести ту чи іншу дію;

Страх змушує нас менше спілкуватися;

Страх змушує нас лякатися відгуків про нашу роботу;

Страх робить нас дратівливими.

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

Не намагатися передбачити майбутнє, а негайно розпочати практичне вивчення проблеми;

Не відгороджуватися від решти світу, а підвищити рівень комунікації;

Не уникати відгуків, а, навпаки, встановити надійний зворотний зв'язок і з його допомогою ретельно контролювати результати своїх дій;

(З роздратуванням ви повинні впоратися самостійно).

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

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

Читачі книги Extreme Programming Explaine, мабуть, звернули увагу на різницю в тоні між екстремальним програмуванням (Extreme Programming, XP) та розробкою через тестування (Test-Driven Development, TDD). На відміну від XP, методика TDD не є абсолютною. XP каже: «щоб рухатися далі, ви повинні освоїти це і це». TDD – менш конкретна методика. TDD передбачає наявність інтервалу між прийняттям рішення та отриманням результатів, і пропонує інструменти керування тривалістю цього інтервалу. «Що, якщо протягом тижня я проектуватиму алгоритм на папері, а потім напишу код, використавши підхід “спочатку тести”? Чи відповідатиме це TDD?» Звичайно буде. Ви знаєте величину інтервалу між прийняттям рішення та оцінкою результатів та усвідомлено контролюєте цей інтервал.

Більшість людей, які освоїли TDD, стверджують, що їхня практика програмування змінилася на краще. Інфіковані тестами(Test infected) - таке визначення придумав Еріх Гамма (Erich Gamma), щоб описати дану зміну. Освоївши TDD, ви виявляєте, що пишете значно більше тестів, ніж раніше, і рухаєтеся вперед малесенькими кроками, які раніше здалися б вам безглуздими. З іншого боку, деякі програмісти, познайомившись з TDD, вирішують повернутися до використання колишніх практик, зарезервувавши TDD для особливих випадків, коли звичайне програмування не призводить до бажаного прогресу.

Безперечно, існують завдання, які неможливо (принаймні, на даний момент) вирішити лише за допомогою тестів. Зокрема, TDD не дозволяє механічно продемонструвати адекватність розробленого коду з погляду безпеки даних та надійності виконання паралельних операцій. Безумовно, безпека ґрунтується на коді, в якому не повинно бути дефектів, проте вона ґрунтується також на участі людини у процедурах захисту даних. Тонкі проблеми паралельного виконання операцій неможливо з упевненістю відтворити, просто запустивши певний код.

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

Насамперед, що таке XP? В Інтернеті можна знайти безліч визначень та описів
цього терміна. У принципі, кожне з них більш-менш адекватно відбиває суть
явища, але різноманіття визначень може заплутати розробника. Тому потрібно
розуміти, що XP це набір методик, вироблених для того, щоб підпорядкувати
процес розробки програмного забезпечення чотирма базовими принципами. А саме:

• спілкування;
• простота;
• Зворотній зв'язок;
• хоробрість.

Зазвичай, у матеріалах XP ці методики конкретизуються. Ось найбільш
типовий їх перелік:

• Гра у планування;
• Тестування на початок розробки;
• Парне програмування;
• Постійна переробка;
• Простота розробки;
• Колективне володіння кодом;
• Інтеграція, що триває;
• Замовник на робочому майданчику;
• Швидкий випуск версій;
• Сорокагодинний робочий тиждень;
• Стандарти кодування;
• Метафора системи.

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

Гра в планування Ідея цієї методики є досить простою. Розробники разом з
замовниками збираються разом та програють деякі можливі ситуації (у
ідеалі всі), які можуть виникнути при вирішенні завдання у житті. Такі збори
бажано влаштовувати перед початком розробки кожної підсистеми, тобто робити
це регулярно протягом усього процесу розробки. Це дозволяє не
займатися розробкою за жорстким планом, а своєчасно адаптуватися до
змін у предметній галузі.

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

Метафора системи. Продукти, що розробляються, або фрагменти коду порівнюються, з
будь-якими аналогічними продуктами чи явищами. Будуються метафори. Це
спрощує розуміння завдання, а, відповідно, прискорює розробку.

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

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

Тепер давайте подивимося, як підходи ХР можуть бути використані на практиці
наших умовах. Однією з моїх на роботі завдань є автоматизація навчального
процесу. Власне кажучи, я протягом досить великого відрізку часу
займаюся написанням програми, що здійснює (принаймні за задумом
автора:)) комплексне вирішення цієї проблеми. Бюджет у проекту мізерний, а обсяг
робіт – пристойний. Ще одним, чи не вирішальним фактором було постійне
видозміна предметної галузі. Регулярно змінюються форми звітної
документації, та методика їх отримання. Склалася ситуація, коли проект перестав
встигати за вимогами користувача. І одного разу настав момент, коли в силу
об'єктивних та суб'єктивних причин, розробку можна було сміливо ховати. Однак
несподівано переді мною було поставлено конкретне завдання визначення
завантаженості аудиторного фонду на семестр На цей момент із трьох учасників
проекту залишився я один, а ця підсистема не була реалізована та реалізація її
навіть не стояла у найближчих планах розвитку проекту. Про такі дрібниці як
грамотна постановка завдання, підрахунок трудомісткості робіт, виділення
додаткових ресурсів ніхто навіть не задумався. На виконання завдання було
відведено два тижні. При цьому мої аргументи щодо неможливості виконання
даної задачі не розглядалися у принципі. Першим моїм рішенням було підшукати
собі іншого роботодавця, тому що за два тижні я повинен був написати не тільки
модуль аналізу завантаженості аудиторного фонду, а також систему введення розкладу
занять, контролю накладок та багато іншого. Автономно, це завдання не вирішується
в принципі - потрібні вихідні дані. І не просто вихідні дані, а коректні
вихідні дані, звідки і витікають усі вищезазначені завдання. Проте,
не знаю чому, але я взявся до вирішення цього завдання.

Звичайно, що говорити про розробку класичними методами в даному випадку
недоречно. Ось тут і знадобилися підходи ХР. Загальне уявлення про завдання я
вже мав, проте було безліч нюансів, які потенційно могли
значно збільшити обсяги робіт. Почав роботу я з того, що набрав номер
навчального відділу і став засипати зняв слухавку масою питань, відповіді на
які я не міг знайти самостійно або в яких я не був певен.
.
Я запустив Rational Rose і приступив до складання моделі. До кінця робочого дня
я накидав модель, що здалася мені більш-менш адекватною. Після роботи я
зробив ще один крок, який відповідає ідеології ХР. Я витягнув свого приятеля,
працюючого у навчальному відділі попити пива. У процесі цього, важливого у всіх
відносинах заходу, я виклав йому своє бачення програми, її інтерфейсу та
логіки роботи. Він, у свою чергу, приймався розповідати про необхідність
вирішення деяких локальних підзадач. До вечора я вже чіткіше усвідомив, що ж
все ж таки потрібно зробити в рамках даного проекту (я вже не сумнівався, що завдання
слід розглядати як окремий проект). Тим не менш, не було вирішено ще один
Важливе питання – вибір засобів розробки. Коли відбувалися описувані
події, я починав активно вивчати технологію MDA. Коротко, суть її така:
фрагменти коду програми та структури даних генеруються автоматично, виходячи
з UML моделі, що дозволяє суттєво скоротити час розробки. У рамках
даної статті я не детально описуватиму принципи роботи MDA, але хочу
акцентувати вашу увагу на тому, що використання цієї технології повністю
відповідає "духу XP". Пов'язано це з тим, що однією з умов, за якої
методики XP будуть успішно працювати, це зниження вартості змін, що вносяться в
додаток на пізніх стадіях розробки. Серед факторів, що сприяють
досягненню цього, не маловажним є використання різних нових
технологій програмування. Зауважу, що простота рефакторингу MDA
додатків є однією з основних переваг цієї технології. Взагалі, на
сьогодні існує досить багато реалізацій MDA, я зупинив свій вибір на
Bold for Delphi.

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

Альтернативним варіантом було написання «звичайного» Delphi програми. Я запустив
ICQ і написав повідомлення своєму знайомому – адепту Bold. Після того як я
коротко виклав йому суть проблеми, я запитав, як би він на моєму місці вчинив.
Він відповів приблизно так: «Або занурюватися з головою в Bold, або
ти ніколи не освоїш його. Зробити серйозний проект – найкращий спосіб вивчити
технологію». Власне, іншої відповіді я й не очікував.

З ранку я взяв існуючу модель і почав будувати програму. Саме, будувати. До
кодування я не приступав, а просто накидав інтерфейс користувача, багато хто
елементи якого практично одразу заробили. На перекур я намагався виходити в
компанії співробітників навчального відділу, це дозволяло мені затягнути чергову
"жертву" до екрану свого монітора і (не без деякої частки гордості) показував
проміжні результати. Отже, реалізовувався принцип зворотний зв'язок.
Ви можете справедливо помітити: «А як парне програмування?». Так,
дійсно, як програміст у проекті брав участь я один. Але тут я
згадаю ще про один щасливий збіг обставин. У той час,
коли відбувалися описувані події, я, разом із групою розробників —
ентузіастів розвивав Інтернет-проект, присвячений саме MDA. І ось, коли я
підійшов до найскладнішого місця у своїй розробці, цей проект приніс
абсолютно несподівані результати.

Протягом кількох днів я писав код процедури, що реалізує відображення занять
на екрані. Стандартні елементи керування не дозволяли вивести на екран усі
дані, у тій формі, в якій вони зазвичай надаються. Мені ж хотілося, що
б кінцевий користувач хоча б приблизно розумів, що робить програма
і як із нею працювати. Я написав свій компонент на основі звичайного TStringGrid.
Я не був впевнений, що це було гарне рішення, але код працював. У форумі
нашого проекту я виклав своє рішення, очікуючи отримати якусь оцінку протягом
досить тривалого проміжку часу. Однак буквально за 15-20 хвилин прийшов
перша відповідь. Пропонувався альтернативний варіант рішення, а ще за 10 хвилин
прийшов тестовий приклад, та не один, а одразу два, від двох авторів. Якщо
замислитися над тим, чому розробники з таким ентузіазмом почали вирішувати
чуже завдання, то можна дійти простого висновку. По-перше, їм просто було
цікаво знайти деяке універсальне рішення, яке потім можна
використовувати у своїх проектах. А по-друге, їм був цікавий сам процес
спілкування. Слід зазначити, що з таким же ентузіазмом вирішувалися й інші завдання
різного рівня складності. Звичайно, це не є парним програмуванням у
звичайному розумінні. Скоріше, це якийсь сурогат, але, тим не менш, у цьому є і
свої плюси. Скажімо, всі думки, що висловлюються, і ідеї автоматично
документувалися, і до них можна було звернутися будь-якої миті.

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

Як я вже казав, я не намагався суворо дотримуватись методик екстремального
програмування. А у прочитаних мною книгах недвозначно стверджувалося, що
написання тесту – один із найважливіших моментів у XP, і без цього інші
методики спрацювати не повинні. Чому ж у результаті я досяг позитивного
результату? Все виявилося досить просто. Відповісти на це запитання мені допоміг
саме цей приклад із зеленими та червоними лампочками. Справа в тому, що в Bold
є можливість показати, чи відповідає цей об'єкт моделі. І
робиться це саме за допомогою подібних «лампочок». Буквально два рядки,
які я майже відразу вставив у код програми, дозволяли мені побачити, в якому
місці відбувається невідповідність (якщо така є). Саме це й замінило
мені тестування. Можливо, такий підхід і не зовсім відповідав
оригінальною ідеєю «тестування до початку розробки», але це спрацювало.

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

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

http://xprogramming.com.ua/ - світ
екстремального програмування

http://www.xprogramming.ru/ -
екстремальне програмування російською

http://www.maxkir.com/ - про розробку
програмного забезпечення

http://xprogramming.com/ - сайт
ідеолога XP Рона Джефріса