Nastavniky.ru

Обучение онлайн
0 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Экстремальное программирование разработка через тестирование

Обучение программированию через тестирование или TDD

Еще в XIX веке шотландский автор Самуэль Смайлс написал: «Мы учимся мудрости на ошибках гораздо быстрее, чем на успехах». Этому утверждению созвучны многие методологии разработки, где особое место уделяется тестированию, — например, DevOps и Agile. Лучшей считается та проверка, которая быстро находит ошибки. Если баги не обнаружены — цикл неудачный.

В школах и вузах нас сначала учат многочисленным правилам и ограничениям и лишь потом подпускают к практике. Даже если цена ошибки копеечная, «разрушительная» самодеятельность карается, а не поощряется. И так в любой области.

Программирование показывает, насколько несостоятелен такой подход. В качественном редакторе кода, совершая ошибку, вы получаете указатель на нее, код и ссылку в документации. Так вы понимаете, какие действия в данной задаче эффективны или запрещены. Но если код компилируется без ошибок, то это не гарантирует его качество. При этом вы лишаетесь возможности подробно, на примере, выявить «бутылочное горлышко».

Это не означает, что обучение через одну лишь практику эффектно. Необходима правильная градация. Такая, где на первом месте — анализ возможных ошибок. Это Test-Driven Development (TDD), или разработка через тестирование — частное направление экстремального программирования. Суть этого принципа сводится к следующему:

  1. Составляется тест для небольшого отрывка кода, описывающего «базу».
  2. Создается код, прогоняется тест.
  3. По мере увеличения объема кода тест прогоняется повторно, каждый раз подтверждая правильность.

Отметим плюсы такого подхода:

  1. Пошаговый рефакторинг кода. При классическом подходе программист часто увлекается разработкой отдельных модулей или всего кода в целом, упуская частности.
  2. Разработка исходит из анализа возможных ошибок. Это заставляет внимательно изучать, откуда берутся баги, а также помогает трезво расширять функциональность. Если вы не можете гарантировать работоспособность участка кода — придется или отказаться от него, или плотнее взяться за теорию.
  3. Разработчик рассматривает больше вариантов реализации. Пошагово увеличивая сложность кода с учетом уже созданного теста, вы изучаете варианты решений, чтобы выбрать простое или гарантированно работающее.

Профессионала легко отличить от новичка по умению находить чужие ошибки и отвечать, почему код не работает. Именно для такой тренировки мозга мы шерстим форумы, участвуем в олимпиадах, проходим тестирования. Поэтому TDD или разработка через тестирование действительно позволяет быстрее достичь продвинутого уровня в программировании.

Чтобы погрузиться в тему TDD, почитайте классные вводные статьи:

И несколько книг:

И не забывайте, что важнейшее правило в программировании через тестирование — максимум практики. Только погружаясь в реальный код, вы получите реальные знания.

Еще в XIX веке шотландский автор Самуэль Смайлс написал: «Мы учимся мудрости на ошибках гораздо быстрее, чем на успехах». Этому утверждению созвучны многие методологии разработки, где особое место уделяется тестированию, — например, DevOps и Agile. Лучшей считается та проверка, которая быстро находит ошибки. Если баги не обнаружены — цикл неудачный.

В школах и вузах нас сначала учат многочисленным правилам и ограничениям и лишь потом подпускают к практике. Даже если цена ошибки копеечная, «разрушительная» самодеятельность карается, а не поощряется. И так в любой области.

Программирование показывает, насколько несостоятелен такой подход. В качественном редакторе кода, совершая ошибку, вы получаете указатель на нее, код и ссылку в документации. Так вы понимаете, какие действия в данной задаче эффективны или запрещены. Но если код компилируется без ошибок, то это не гарантирует его качество. При этом вы лишаетесь возможности подробно, на примере, выявить «бутылочное горлышко».

Это не означает, что обучение через одну лишь практику эффектно. Необходима правильная градация. Такая, где на первом месте — анализ возможных ошибок. Это Test-Driven Development (TDD), или разработка через тестирование — частное направление экстремального программирования. Суть этого принципа сводится к следующему:

  1. Составляется тест для небольшого отрывка кода, описывающего «базу».
  2. Создается код, прогоняется тест.
  3. По мере увеличения объема кода тест прогоняется повторно, каждый раз подтверждая правильность.

Отметим плюсы такого подхода:

  1. Пошаговый рефакторинг кода. При классическом подходе программист часто увлекается разработкой отдельных модулей или всего кода в целом, упуская частности.
  2. Разработка исходит из анализа возможных ошибок. Это заставляет внимательно изучать, откуда берутся баги, а также помогает трезво расширять функциональность. Если вы не можете гарантировать работоспособность участка кода — придется или отказаться от него, или плотнее взяться за теорию.
  3. Разработчик рассматривает больше вариантов реализации. Пошагово увеличивая сложность кода с учетом уже созданного теста, вы изучаете варианты решений, чтобы выбрать простое или гарантированно работающее.

Профессионала легко отличить от новичка по умению находить чужие ошибки и отвечать, почему код не работает. Именно для такой тренировки мозга мы шерстим форумы, участвуем в олимпиадах, проходим тестирования. Поэтому TDD или разработка через тестирование действительно позволяет быстрее достичь продвинутого уровня в программировании.

Чтобы погрузиться в тему TDD, почитайте классные вводные статьи:

И несколько книг:

И не забывайте, что важнейшее правило в программировании через тестирование — максимум практики. Только погружаясь в реальный код, вы получите реальные знания.

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

Возвращение знаменитого бестселлера. Изящный, гибкий и понятный код, который легко модифицировать, который корректно работает и который не подкидывает своим создателям неприятных сюрпризов. Неужели подобное возможно? Чтобы достичь цели, попробуйте тестировать программу еще до того, как она написана. Именно такая парадоксальная идея положена в основу методики TDD (Test-Driven-Development – разработка, основанная на тестировании). Бессмыслица? Не спешите делать скороспелые выводы. Рассматривая применение TDD на примере разработки реального программного кода, автор демонстрирует простоту и мощь этой методики. В книге приведены два программных проекта, целиком и полностью реализованных с использованием TDD. За рассмотрением примеров следует обширный каталог приемов работы в стиле TDD, а также паттернов и рефакторингов, имеющих отношение к TDD. Книга будет полезна для любого программиста, желающего повысить производительность своей работы и получить удовольствие от программирования.

Читать еще:  Как программировать на андроид

Оглавление

  • Предисловие
  • Благодарности
  • Введение
  • Часть I. На примере денег

Из серии: Библиотека программиста (Питер)

Приведённый ознакомительный фрагмент книги Экстремальное программирование. Разработка через тестирование (Кент Бек, 2003) предоставлен нашим книжным партнёром — компанией ЛитРес.

Однажды рано утром в пятницу к Уорду Каннингэму зашел босс и представил его Питеру, перспективному заказчику системы WyCash. Эта система предназначалась для управления портфелем облигаций, ее разработкой и продажей занималась компания Уорда. «Возможности вашей системы впечатляют, – сказал Питер. – Но вот в чем проблема: я собираюсь открыть новый фонд облигаций. Как я понял, ваша система поддерживает облигации, номинированные только в долларах США. Мне же понадобится система, поддерживающая разные валюты». Босс повернулся к Уорду и спросил: «Мы сможем это сделать?»

Вот он, кошмарный сценарий для любого разработчика. Все шло хорошо, пока события развивались по намеченному плану, и вдруг все меняется. Надо сказать, это было кошмаром не только для Уорда – босс, съевший собаку на управлении программными проектами, тоже не знал, что ответить.

Система WyCash была разработана небольшой командой программистов за пару лет. Она позволяла работать с большинством ценных бумаг с фиксированным доходом, имеющих хождение на американском рынке. Более того, она поддерживала некоторые редкие инструменты рынка ценных бумаг, например гарантированные инвестиционные контракты (Guaranteed Investment Contracts), и этим выгодно отличалась от конкурентов.

В основу разработки WyCash легли объектно-ориентированные технологии, также была использована объектная база данных. Базовой абстракцией системы был класс Dollar, класс, который отвечал за вычисления и форматирование результатов. В самом начале работы над системой его разработку поручили отдельной группе хороших программистов.

В течение последних шести месяцев Уорд и остальные члены команды постепенно уменьшали количество обязанностей класса Dollar. Оказалось, что числовые классы языка Smalltalk вполне подошли для реализации вычислений, а для округления до трех десятичных знаков был написан специальный код. Результаты вычислений становились все точнее и точнее, и в конце концов сложные алгоритмы тестирования, выполнявшие сравнение величин с учетом погрешности, были заменены простым сравнением реального и ожидаемого результатов.

За форматирование результатов в действительности отвечали классы пользовательского интерфейса, а не класс Dollar. Так как соответствующие тесты были написаны на уровне этих классов, в частности для подсистемы отчетов [2] , поэтому предполагаемые изменения не должны были их коснуться. В результате, спустя шесть месяцев, у объекта Dollar осталось не так уж много обязанностей…

Один из наиболее сложных алгоритмов, вычисление средневзвешенных величин, также постепенно менялся. Вначале существовало много различных реализаций этого алгоритма, разбросанных по всему коду. Однако позже, с появлением подсистемы отчетов, стало очевидно, что существует только одно место, где этот алгоритм должен быть реализован, – класс AveragedColumn. Именно этим классом и занялся Уорд.

Если бы удалось внедрить в этот алгоритм поддержку работы с несколькими валютами, система в целом смогла бы стать «мультивалютной». Центральная часть алгоритма отвечала бы за хранение количества денег «в столбце». При этом алгоритм должен быть достаточно абстрактным для вычисления средневзвешенных величин любых объектов, которые поддерживали арифметические операции. К примеру, с его помощью можно было бы вычислять средневзвешенное календарных дат.

Выходные прошли как обычно – за отдыхом, а в понедельник утром босс поинтересовался: «Ну как, мы сможем это сделать?» – «Дайте мне еще день, и я скажу точно», – ответил Уорд.

В вычислении средневзвешенной величины объект Dollar как бы являлся переменной. В случае наличия нескольких валют потребовалось бы по одной переменной на каждый тип валюты, нечто вроде многочлена. Только вместо 3×2 и 4y3 – 15 USD и 20 °CHF [3] .

Быстрый эксперимент показал, что при вычислениях можно работать не с объектом Dollar (доллар), а с более общим объектом – Currency (валюта). При этом, если выполнялась операция над двумя различными валютами, значение следовало возвращать в виде объекта PolyCurrency (мультивалютный). Сложность заключалась в том, чтобы добавить новую функциональность, не сломав при этом то, что уже работает. А что, если просто прогнать тесты?

После добавления к классу Currency нескольких (пока нереализованных) операций большинство тестов все еще успешно выполнялось; к концу дня проходили все тесты. Уорд интегрировал новый код в текущую версию и пошел к боссу. «Мы сможем это сделать», – уверенно сказал он.

Давайте задумаемся над этой историей. Через пару дней потенциальный рынок для системы WyCash увеличился в несколько раз, соответственно подскочила ее ценность. Важно, что возможность создать значительную бизнес-ценность за такое короткое время не была случайной. Свою роль сыграли следующие факторы:

• Метод – Уорду и команде разработки WyCash потребовался опыт в пошаговом наращивании проектных возможностей системы, с хорошо отработанным механизмом внесения изменений.

• Мотив – Уорду и его команде было необходимо четкое представление о значимости поддержки мультивалютности в WyCash, а также потребовалась смелость взяться за такую на первый взгляд безнадежную задачу.

• Возможность – сочетание всеохватывающей, продуманной системы тестов и хорошо структурированной программы; язык программирования, обеспечивающий локализацию проектных решений и тем самым упрощающий идентификацию ошибок.

Мотив – это то, чем вы не можете управлять; сложно сказать, когда он у вас появится и заставит заняться техническим творчеством для решения бизнес-задач. Метод и возможность, с другой стороны, находятся под вашим полным контролем. Уорд и его команда создали метод и возможность благодаря таланту, опыту и дисциплине. Значит ли это, что, если вы не входите в десятку лучших разработчиков планеты и у вас нет приличного счета в банке (настолько приличного, чтобы попросить босса погулять, пока вы занимаетесь делом), такие подвиги не для вас?

Читать еще:  Язык программирования для андроид игр

Нет, вовсе нет. Всегда можно развернуть проект так, чтобы работа над ним стала творческой и интересной, даже если вы обычный разработчик и прогибаетесь под обстоятельства, когда приходится туго. Разработка через тестирование (Test-Driven Development, TDD) – это набор способов, ведущих к простым программным решениям, которые может применять любой разработчик, а также тестов, придающих уверенность в работе. Если вы гений, эти способы вам не нужны. Если вы тугодум – они вам не помогут. Для всех остальных, кто находится между этими крайностями, следование двум простым правилам поможет работать намного эффективнее:

• перед тем как писать любой фрагмент кода, создайте автоматизированный тест, который поначалу будет терпеть неудачу;

Как конкретно следовать этим правилам, какие существуют в данной области нюансы и какова область применимости этих способов – все это составляет тему книги, которую вы сейчас читаете. Вначале мы рассмотрим объект, созданный Уордом в момент вдохновения, – мультивалютные деньги (multi-currency money).

Оглавление

  • Предисловие
  • Благодарности
  • Введение
  • Часть I. На примере денег

Из серии: Библиотека программиста (Питер)

Приведённый ознакомительный фрагмент книги Экстремальное программирование. Разработка через тестирование (Кент Бек, 2003) предоставлен нашим книжным партнёром — компанией ЛитРес.

Экстремальное программирование. Разработка через тестирование — Кент Бек (2003)

Экстремальное программирование. Разработка через тестирование — Кент Бек читать онлайн бесплатно полную версию книги

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

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

ISBN 978-0321146533 англ.

© 2003 by Pearson Education, Inc.

© Перевод на русский язык ООО Издательство «Питер», 2017

© Издание на русском языке, оформление ООО Издательство «Питер», 2017

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

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

• это предсказуемый способ разработки программ. Вы знаете, когда работу можно считать законченной и не беспокоиться о длинной череде ошибок;

• дает шанс усвоить уроки, которые преподносит код. Если вы воспользуетесь первой же идеей, которая пришла в голову, у вас не будет шанса реализовать вторую, лучшую идею;

• улучшает жизнь пользователей ваших программ;

• позволяет вашим коллегам рассчитывать на вас, а вам – рассчитывать на них;

• писать такой код приятнее.

Но как получить чистый код, который работает? Многие силы мешают нам получить чистый код, а иногда не удается даже получить код, который просто работает. Чтобы избавиться от множества проблем, мы будем разрабатывать код, опираясь на автоматизированное тестирование. Такой стиль программирования называется разработкой через тестирование. Согласно этой методике

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

• любое дублирование устраняется.

Два простых правила, не правда ли? Однако они генерируют сложное индивидуальное и групповое поведение со множеством технических последствий:

• в процессе проектирования мы постоянно запускаем код и получаем представление о его работе, это помогает принимать правильные решения;

• мы сами пишем тесты, так как не можем ждать, что кто-то другой напишет тесты для нас;

• наша среда разработки должна быстро реагировать на небольшие модификации кода;

• дизайн программы должен базироваться на использовании множества автономных, слабо связанных компонентов, чтобы упростить тестирование кода.

Два упомянутых правила TDD определяют порядок этапов программирования.

1. Красный – напишите небольшой тест, который не работает, а возможно, даже не компилируется.

2. Зеленый – заставьте тест работать как можно быстрее, при этом не думайте о правильности дизайна и чистоте кода. Напишите ровно столько кода, чтобы тест сработал.

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

Красный – зеленый – рефакторинг – это мантра TDD.

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

• при достаточно низкой плотности дефектов команда контроля качества (Quality Assurance, QA) сможет перейти от реагирования на ошибки к их предупреждению;

Экстремальное программирование или управление: как не путаться в терминах

Чтобы вы не терялись и не путались, рассказываем, что такое экстремальное программирование и почему экстремальное управление — не методология.

Разработчики хотят упростить жизнь себе и коллегам по цеху: создают новые методологии разработки, например, экстремальное программирование. Менеджеры не отстают, смотрят по сторонам, обобщают опыт и придумывают свои методы управления. Так, например, появился экстремальный менеджмент.

Читать еще:  Язык программирования javascript скачать

Экстремальное управление и программирование — не одно и то же

Термин «экстремальное управление проектами» придумал эксперт по менеджменту Дуг ДеКарло в 2004 году. На самом деле он просто собрал опыт разных компаний, проанализировал, выделил самое лучшее и получил авторский метод менеджмента. Весь процесс управления по ДеКарло основан на принципах экстремального программирования (Extreme Programming).

Экстремальное программирование (XP) — гибкая методология разработки программного обеспечения. По сути, это все — лучшие практики Agile, но используемые по максимуму. XP сформулировал и впервые использовал американский разработчик Кент Бек в конце 90-х годов.

Главная особенность XP — методология применима только в сфере разработки программного обеспечения. Ее не использовать там, где нет никакого digital-продукта.

Ценности и практики экстремального программирования

XP — это agile-методология, но она опирается на свои ценности.

Основные ценности XP

Упрощение кода и процесса работы.

Не быть отшельником, а взаимодействовать с коллегами, чтобы быстрее искать решения проблем.

Постоянно общаться с заказчиком и следить за изменениями требований.

Не бояться рисковать и использовать новые непроверенные практики.

Уважать себя, коллег, правила и цели проекта.

Как и у любой другой методологии, у XP есть свой набор практик, на которых строится вся работа.

Основные практики

Парное программирование

Два разработчика садятся за один компьютер и пишут код. Не каждый свою версию, а вместе работают над одной функцией продукта. Сначала решение предлагает один разработчик, второй наблюдает и по ходу комментирует и исправляет ошибки. Потом программисты меняются местами и процесс повторяется.

Из двух решений в процессе работы выбирают лучшее и чистят код до идеального состояния. Работает принцип — две головы лучше, чем одна. Но это вызывает много споров среди разработчиков, так как они привыкли работать и отвечать за результат в одиночку.

Разработка через тестирование

Подготовка к тестированию начинается еще до начала написания кода. Программист сначала пишет тесты и только потом — код.

Свободный доступ к коду

Любой разработчик может править код, который написал его коллега по команде.

Единое оформление кода

Чтобы код выглядел одинаково, даже если его писали пять разных программистов, команда использует единый стиль. Если все работают над одним проектом, то заранее оговаривают фреймворки, которые будут задействованы.

Непрерывная интеграция

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

Общее видение системы

Чтобы программисты одинаково понимали результат, который должны получить, используется метафора. Систему сравнивают с чем-то, что понятно и знакомо всем в команде. Так формируется единое видение.

Никаких переработок

Для высокой продуктивности важно физическое и эмоциональное состояние команды. Поэтому переработки в XP не приветствуются. Норма работы — не более40 часов в неделю. Это дает возможность команде выложиться по максимуму, но не перегореть.

Как работает команда

Все начинается с выяснения требований и планирования. Задачи записывают на карточки, выясняют у заказчика последовательность, в которой он хочет получать функционал продукта. Карточки располагают по приоритетности. По схожей системе работают команды в Scrum и Kanban.

Команда анализирует информацию, оценивает время на каждую задачу. Согласовывает все с заказчиком и начинает работу над проектом. Требования часто меняются, поэтому процесс делят на короткие этапы с частыми релизами, как и в Scrum.

Прежде чем начать, команда создает тесты, которые будет использовать для проверки готового кода. Когда тесты готовы, разработчики пишут первую часть кода. Тестируют ее, а потом приступают ко второй. Постепенно появляется все больше маленьких частей кода, которые в процессе добавляют в единую систему. Части кода и функции будущего продукта наращивают постепенно, как снежный ком. После каждого релиза команда собирает обратную связь, чтобы двигаться дальше.

Как применить идеи экстремального программирования в управлении

XP и экстремальный менеджмент — части одной большой системы. Они взаимосвязаны, так как когда-то принципы методологии разработки повлияли на способ управления проектами. И теперь идеи XP можно применять не только к процессу написания кода, но и к работе менеджера. Как это сделать?

  • Использовать практики XP для сложных и запутанных проектов, когда требования быстро меняются и надо успевать держать все под контролем.
  • Делать только то, что нужно сейчас, а не пытаться угадать, что потребуется в будущем.
  • Постоянно улучшать и упрощать не только код, но и процессы работы команды.
  • Всегдавыбирать самую актуальную проблему и применять одну из практик для ее решения. Потом следующую проблему. И так — пока все не будет идеально.

XP — только одна из гибких методологий, принципы которых активно используют в управлении проектами. Она не так популярна, как, например, Scrum. Только небольшой процент команд использует весь комплекс практик XP в работе над проектом. Чаще выбирают одну или несколько, которые больше всего подходят и могут реально упростить процесс.

Заключение

Если вы решили сочетать несколько разных методологий, то важно не пытаться вместить в один проект все и сразу и думать, что так быстрее заработает. Нужно понимать, что и для каких целей вы хотите использовать. И помнить: если это помогло вашему конкуренту, это не значит, что и у вас будет хороший результат. Все может получиться наоборот. Если есть сомнения, лучше учиться проектным менеджерским трюкам и жонглированиям методологиями у мастеров со стажем и большим практическим опытом.

Ссылка на основную публикацию
Adblock
detector