Презентация Технология и процесс разработки ПО. Лекция 5 онлайн

Содержание слайда:

Содержание слайда: Ежедневная сборка (build) и непрерывная интеграция Интеграция программного проекта означает: взять все созданные компоненты проекта, скомпилировать их совместно и выполнить тесты (регрессионный набор). Наиболее заметным продвижением в этом направлении стала "ежедневная сборка", введенная в Майкрософт в восьмидесятые годы. Идея была проста. В конце каждого дня собираются все изменения, "введенные" (официально подписанные) разработчиками; система компилируется, прогоняются все тесты. Как отмечает менеджер Майкрософт [Cusumano 1995]: Создание ежедневных сборок – одно из самых болезненных дел в мире, но это и самая величайшая вещь в мире, по-скольку вы получаете мгновенную обратную связь. Правила agile, в частности XP, идут дальше и вместо "ежедневной сборки" рекомендуют "непрерывную интеграцию". Правило Бека [Beck 2005]: Интегрируйте и тестируйте изменения не реже, чем через несколько часов.

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

Содержание слайда: Повышение дисциплины Программисты в паре чаще «делают то, что нужно» и реже устраивают длинные перерывы. Лучший код Партнёры в паре менее склонны к неудачным решениям и производят более качественный код. Высокий боевой дух Коллективное владение кодом (пары меняются)

Содержание слайда: Недостатки

Содержание слайда: РАБОТАТЬ В ПАРЕ

Содержание слайда: Создаем эффективную пару

Содержание слайда:

Содержание слайда:

Содержание слайда:

Содержание слайда:

Содержание слайда:

Содержание слайда:

Содержание слайда:

Содержание слайда:

Содержание слайда:

Содержание слайда: ЦИФРЫ

Содержание слайда:

Содержание слайда:

Содержание слайда:

Содержание слайда: Пинг-понг программирование

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

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

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

Содержание слайда: Признаки плохого кода дублирование кода длинный метод; большой класс; длинный список параметров; «жадные» функции — это метод, который чрезмерно обращается к данным другого объекта; классы данных; комментарии

Содержание слайда: Разработка "Вначале Тест" и разработка, управляемая тестами TDD (Test Driven Development). Разработка TDD является следствием TFD (Test First Development) – "Вначале Тест" разработки.

Содержание слайда: Цикл TDD

Содержание слайда:

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

Содержание слайда: Оценка TFD и TDD TDD — это процесс итеративного, непрерывного, параллельного написания тестов и рабочего кода, с обязательными фазами рефакторинга. каждый новый код должен сопровождаться новыми тестами". Не так уж критично, что раньше – код или тест, никогда не создавайте одно без другого.

Содержание слайда: TDD за и против Зависимоть от ТЗ

Содержание слайда: КНИГИ Вот список книг, которые любой TDD-практик просто обязан прочитать (must read) и иметь в любой момент на своем столе: Э. Гамма и др. «Design patterns» М. Фаулер «Refactoring: Improving the Design of Existing Code» М. Фаулер «Patterns of Enterprise Applications Architecture» Р. Мартин «Agile software development»

Содержание слайда: BEHAVIOR-DRIVEN DEVELOPMENT BDD (Behavior-driven development, Разработка через поведение) - техника разработки, при котором рассматривается не результат выполнения какого-либо модуля, а та работка, которую он выполняет. Этот принцип можно рассматривать как продолжение TDD. Создателем техники считается ДенНорт

Содержание слайда: Принципы BDD Тестируемая разработка - это методология разработки программного обеспечения, которая по существу утверждает, что для каждой единицы программного обеспечения разработчик программного обеспечения должен: Сначала определить тестовый набор для устройства; Сделать тесты неудачными; Затем реализовать устройство; Наконец, убедитесь, что реализация блока делает тесты успешными.

Содержание слайда: Отличие TDD от BDD This class should do something Используйте слово «поведение», а не «тест» BDD дает «доступный всем язык» для анализа

Содержание слайда: Общеупотребительный язык Для того, заказчик и разработчик могли составлять сценарии вместе, используется концепция общеупотребительных языков (ubiquitous language) Общеупотребительный язык – Набор базовых терминов предметной области. Является общим для заказчика и разработчика.

Содержание слайда: Системы для программной поддержки TDD и BDD JUnit – фреймворк, применяющийся для разработки на Java. В нем тестовые методы начинаются со слова test и наследуются от тест-класса TestCase. Nunit – открытая среда юнит-тестирования приложений для .NET. Она была портирована с языка Java (библиотека JUnit). Первые версии NUnit были написаны на J#, но затем весь код был переписан на C# с использованием таких новшеств .NET, как атрибуты.

Содержание слайда: Системы для программной поддержки TDD и BDD Cucumber - среда разработки наязыке программирования Ruby. Разработчик описывает необходимое поведение в обычном тексте. Specflow BDD-синтаксис Given, When, Then интуитивно понятен. Рассмотрим элементы синтаксиса: Given предоставляет контекст выполнения сценария тестирования, например, точки вызова сценария в приложении, а также любые необходимые данные. When определяет набор операций, инициирующих тестирование, таких как действия пользователей или подсистем. Then описывает ожидаемый результат тестирования.

Содержание слайда: Пример разработки системы с использованием BDD Начнем с того, что определим нашу функциональность. Feature: Show logged in user name In order to logged in as a user called “Username" I want to see page header displays the caption "Здравствуйте, Username!" Здесь мы задаем на понятном нам языке, что мы хотим увидеть от нашей функциональности.

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

Содержание слайда: Написание сценария Напишем сценарий, который будет основой для работы cucumber’а Scenario: Show logged in user name Given I am logged in as a user called “Username" When I visit the homepage Then the page header displays the caption "Здравствуйте, Username!“ Scenario – имя сценария. Given… - Начальное условие (две категории и их описание) When.. – Если я на странице с категориями… Then – Я должен увидеть…

Содержание слайда: Написание сценария Для каждого действия также пишем соответствующие функции: Given /I am logged in as a user called "(.*)"/ do |name| create_user(name) sign_in_as(name) end Then /the page header displays the caption "(.*)"/ do |caption|page_header.should_contain(caption) end Таким образом Cucumber или SpecFlow сможет интерпретировать каждый шаг, вычленить с помощью регулярных выражений параметры и запустить соответствующие тесты.