Технологии разработки ПО Кривовязь Глеб

1

Мотивация

2

Профессиональная разработка ≠ просто написание кода

Инфраструктура разработки

3

Основные проблемы

4

Как организовать совместную работу с кодом?

Как систематизировать задачи?

Где и в каком виде хранить всю информацию по проекту?

Как оформлять код?

Как создавать документацию?

Как контролировать качество кода?

…

Системы контроля версий (VCS, Version Control Systems)

5

Централизованные o CVS

o StarTeam

o Subversion (SVN)

o Perforce

o MS Team Foundation

Распределенные o Git

o Mercurial

o Bazaar

Системы контроля версий (VCS, Version Control Systems)

6

7

8

Создан в 2005 г. для оптимизации разработки ядра Linux

Построен по принципу файловой системы

Большинство операций – локальные и очень быстрые («the

gods of speed have blessed Git with unworldly powers» )

Идеально подходит для активной работы с ветками

Обладает всеми преимуществами распределенных систем

9

Каждый commit – «слепок» файловой системы (snapshot)

Актуальные версии файлов хранятся целиком (blobs)

10

Вся история разработки – граф commit’ов

Ветка (branch) = указатель на commit (41 байт!). HEAD –

текущая ветка

11

Находимся в ветке master

12

Создаем ветку dev

13

Делаем checkout ветки dev

14

Делаем commit

15

Возвращаемся в ветку master (делаем checkout)

16

Делаем commit

17

http://git-scm.com/book

Системы трекинга задач и дефектов (Issue trackers)

18

Цель – организация задач, расстановка приоритетов

Issue – может быть task, bug, improvement и т.д.

Типичные характеристики issue: o Description

o Reporter

o Assignee

o Project

o Priority

o Due date

o …

Системы хранения знаний

19

Цель – хранение полезной информации по проекту: o Документация

o Описания алгоритмов

o Отчеты

o Планы

Полезные возможности: o Поддержка версионности документов

o Рассылка уведомлений об изменениях

Стандарты кодирования (Coding standards, style guildelines)

20

vs

Стандарты кодирования (Coding standards, style guildelines)

21

Не важно какие, главное – чтобы были

Код 1 раз пишется, но 100 раз читается

Пример - Google C++ Style Guide

http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml

Документирование кода

22

Ручное написание комментариев

Системы автоматической генерации документации, например, Doxygen http://www.stack.nl/~dimitri/doxygen/index.html

Doxygen - пример

23

Код:

Doxygen - пример

24

HTML-документация (фрагмент):

Ревью кода (Code review)

25

Цель – выявление дефектов и потенциальных проблем на как можно более ранней стадии, улучшение процесса разработки, контроль качества кода

Ревью кода (Code review)

26

Возможны разные формы: Формальные проверки

Неформальный контроль

Совместное программирование

Формальные ревью кода

27

Пример – Review Board http://www.reviewboard.org/

Review Board Repository

Author

Reviewer

Initial commit Reviewed commit

Тестирование и контроль качества ПО

28

Основные проблемы

29

Как убедиться, что разрабатываемая система делает то, что должна?

Как проверить, что исправления известных дефектов не породили новые?

Как контролировать изменения характеристик работы системы в результате вносимых исправлений?

…

Уровни тестирования

30

Тестирование в процессе написания кода

Модульное и интеграционное тестирование

Регрессионные тесты

Ручное тестирование

Модульное тестирование (Unit tests)

31

Цель – тестирование отдельных функций и компонентов системы, а также их взаимодействия (интеграционные тесты)

Тесты пишутся разработчиками

Для C++ - Google Test: http://code.google.com/p/googletest/

Иногда поддерживается на уровне языка

Модульное тестирование (Unit tests)

32

Вопрос - какой это язык программирования?

Модульное тестирование (Unit tests)

33

Язык D! http://dlang.org

Модульное тестирование (Unit tests)

34

Пример (C++)

Test-Driven Development

35

Идея – сначала пишем тест, потом реализуем функциональность

Test-Driven Development

36

Достоинства: o Требования прописываются заранее, а не «на ходу»

o Ошибки выявляются на самом раннем этапе

o Сильно упрощается рефакторинг

o Тесты служат полноценной документацией (например, в D это выведено на уровень языка)

Критика: o Написание теста не всегда тривиально

o При хорошем покрытии объем тестового кода сопоставим с объемом кода самой системы, а иногда и значительно превышает его

Регрессионное тестирование (Regression tests)

37

Цели: o Убедиться, что то, что работало, не сломалось

o Убедиться, что результат работы системы соответствует спецификации

o Контроль результатов работы алгоритмов, батч-тесты

Тесты создаются как разработчиками, так и тестерами

Могут быть как автоматическими, так и ручными

Непрерывная интеграция (Continuous integration)

38

Идея – регулярная (непрерывная) сборка актуальной версии продукта и контроль изменений

Непрерывная интеграция (Continuous integration)

39

Основные принципы:

Наличие единого репозитория кода

Полная автоматизация сборки

Каждая сборка должна подвергаться набору тестов

Регулярные небольшие commit’ы, не «ломающие» сборку

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

Автоматическое развертывание

Организация процесса разработки

40

Основные проблемы

41

Какой методологии разработки придерживаться?

Как организовать процесс выпуска стабильного релиза?

Как обеспечить эффективную работу каждого члена команды и команды в целом?

…

Методологии разработки ПО

42

Водопадная модель (waterfall model)

Спиральная модель (spiral model)

Итерационная модель (iterative model)

Гибкая разработка (agile development)

Водопадная модель

43

Все спланировали – и реализовали

Спиральная модель

44

Постепенное уточнение требований путем прототипирования, потом реализация

Итерационная модель

45

Постепенное наращивание функциональности, итерация за итерацией

Гибкая разработка

46

Целая философия, основанная на итерационной модели. Частые итерации (спринты), кросс-функциональные команды, работа в условиях постоянно меняющихся требований

Гибкая разработка

47

Основные постулаты («Agile manifesto»): • Люди и взаимодействие важнее процессов и инструментов; • Работающий продукт важнее исчерпывающей

документации; • Сотрудничество с заказчиком важнее согласования условий

контракта; • Готовность к изменениям важнее следования

первоначальному плану. Примеры: • SCRUM • Kanban • Extreme programming

Жизненный цикл релиза (Release life cycle)

48

Release manager – специальный человек, отвечающий за процесс выпуска релиза

time

Release 1.7

active development bug fixing,

code stabilization emergency fixes only

feature freeze

code freeze

Nightly bui ld 1

Nightly bui ld N

…

Feature complete

Release candidate

Release 1.8

development branch

release branch

Напоследок

49

Что отличает лучших разработчиков

50

Умение выдавать законченный результат

Кругозор o Знание различных языков, инструментов и технологий

o Умение находить правильные подходы к возникающим задачам, использовать подходящие инструменты

o Стремление постоянно поддерживать свои знания в актуальном состоянии

Понимание высокоуровневых целей и умение мыслить в терминах «business value»

Инициативность

Самостоятельность

Умение оценивать сроки и выдерживать их

Умение общаться с людьми (коллегами, заказчиками, пользователями)

Умение четко и структурированно рассказывать о своей работе

51

Удачной разработки!