Обзор инструментов и технологий промышленной разработки программного обеспечения

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

2. Мотивация
Профессиональная разработка ≠ просто написание кода
2

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

4. Основные проблемы

Как организовать совместную работу с кодом?

Как систематизировать задачи?

Где и в каком виде хранить всю информацию по проекту?

Как оформлять код?

Как создавать документацию?

Как контролировать качество кода?

…
4

5. Системы контроля версий
(VCS, Version Control Systems)

Централизованные
o
o
StarTeam
o
Subversion (SVN)
o
Perforce
o

CVS
MS Team Foundation
Распределенные
o
Git
o
Mercurial
o
Bazaar
5

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

7. 7

8. 
Создан в 2005 г. для оптимизации разработки ядра Linux

Построен по принципу файловой системы

Большинство операций – локальные и очень быстрые («the
gods of speed have blessed Git with unworldly powers»  )

Идеально подходит для активной работы с ветками

Обладает всеми преимуществами распределенных систем
8

9. 
Каждый commit – «слепок» файловой системы (snapshot)

Актуальные версии файлов хранятся целиком (blobs)
9

10. 
Вся история разработки – граф commit’ов

Ветка (branch) = указатель на commit (41 байт!). HEAD –
текущая ветка
10

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

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

13. 
Делаем checkout ветки dev
13

14. 
Делаем commit
14

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

16. 
Делаем commit
16

17. http://git-scm.com/book
17

18. Системы трекинга задач и дефектов
(Issue trackers)

Цель – организация задач, расстановка приоритетов

Issue – может быть task, bug, improvement и т.д.

Типичные характеристики issue:
o
Description
o
Reporter
o
Assignee
o
Project
o
Priority
o
Due date
o
…
18

19. Системы хранения знаний

Цель – хранение полезной информации по проекту:
o
o
Описания алгоритмов
o
Отчеты
o

Документация
Планы
Полезные возможности:
o
Поддержка версионности документов
o
Рассылка уведомлений об изменениях
19

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

21. Стандарты кодирования
(Coding standards, style guildelines)

Не важно какие, главное – чтобы были

Код 1 раз пишется, но 100 раз читается

Пример - Google C++ Style Guide
http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml
21

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

23. Doxygen - пример
Код:
23

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

25. Ревью кода
(Code review)
Цель – выявление дефектов и потенциальных проблем на как
можно более ранней стадии, улучшение процесса разработки,
контроль качества кода
25

26. Ревью кода
(Code review)
Возможны разные формы:

Формальные проверки

Неформальный контроль

Совместное программирование
26

27. Формальные ревью кода

Пример – Review Board
http://www.reviewboard.org/
Review Board
Repository
Reviewed commit
Initial commit
Author
Reviewer
27

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

29. Основные проблемы




Как убедиться, что разрабатываемая система делает то, что
должна?
Как проверить, что исправления известных дефектов не
породили новые?
Как контролировать изменения характеристик работы
системы в результате вносимых исправлений?
…
29

30. Уровни тестирования
Тестирование в процессе написания
кода
Модульное и интеграционное
тестирование
Регрессионные тесты
Ручное тестирование
30

31. Модульное тестирование
(Unit tests)

Цель – тестирование отдельных функций и компонентов
системы, а также их взаимодействия (интеграционные тесты)

Тесты пишутся разработчиками

Для C++ - Google Test: http://code.google.com/p/googletest/

Иногда поддерживается на уровне языка
31

32. Модульное тестирование
(Unit tests)
Вопрос - какой это язык программирования?
32

33. Модульное тестирование
(Unit tests)
Язык D!
http://dlang.org
33

34. Модульное тестирование
(Unit tests)
Пример (C++)
34

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

36. Test-Driven Development

Достоинства:
o
Требования прописываются заранее, а не «на ходу»
o
Ошибки выявляются на самом раннем этапе
o
Сильно упрощается рефакторинг
o

Тесты служат полноценной документацией (например, в D это
выведено на уровень языка)
Критика:
o
o
Написание теста не всегда тривиально
При хорошем покрытии объем тестового кода сопоставим с
объемом кода самой системы, а иногда и значительно превышает
его
36

37. Регрессионное тестирование
(Regression tests)

Цели:
o
o
o
Убедиться, что то, что работало, не сломалось
Убедиться, что результат работы системы соответствует
спецификации
Контроль результатов работы алгоритмов, батч-тесты

Тесты создаются как разработчиками, так и тестерами

Могут быть как автоматическими, так и ручными
37

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

39. Непрерывная интеграция
(Continuous integration)
Основные принципы:

Наличие единого репозитория кода

Полная автоматизация сборки

Каждая сборка должна подвергаться набору тестов

Регулярные небольшие commit’ы, не «ломающие» сборку


Легкий доступ к результатам каждой сборки (инсталляторы,
отчеты и т.п.)
Автоматическое развертывание
39

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

41. Основные проблемы

Какой методологии разработки придерживаться?

Как организовать процесс выпуска стабильного релиза?


Как обеспечить эффективную работу каждого члена команды
и команды в целом?
…
41

42. Методологии разработки ПО

Водопадная модель (waterfall model)

Спиральная модель (spiral model)

Итерационная модель (iterative model)

Гибкая разработка (agile development)
42

43. Водопадная модель
Все спланировали – и реализовали
43

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

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

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

47. Гибкая разработка
Основные постулаты («Agile manifesto»):
• Люди и взаимодействие важнее процессов и инструментов;
• Работающий продукт важнее исчерпывающей
документации;
• Сотрудничество с заказчиком важнее согласования условий
контракта;
• Готовность к изменениям важнее следования
первоначальному плану.
Примеры:
• SCRUM
• Kanban
• Extreme programming
47

48. Жизненный цикл релиза (Release life cycle)
development branch
release branch
active development
Ni ghtly
bui ld 1
Rel ease
1.7
…
Ni ghtly
bui ld N
bug fixing,
code stabilization
emergency
fixes only
feature
freeze
Fea ture
compl ete
Rel ease
ca ndidate
time
code
freeze
Rel ease
1.8
Release manager – специальный человек, отвечающий за процесс выпуска
релиза
48

49. Напоследок
49

50. Что отличает лучших разработчиков

Умение выдавать законченный результат

Кругозор
o
o
o

Знание различных языков, инструментов и технологий
Умение находить правильные подходы к возникающим задачам,
использовать подходящие инструменты
Стремление постоянно поддерживать свои знания в актуальном состоянии
Понимание высокоуровневых целей и умение мыслить в терминах
«business value»

Инициативность

Самостоятельность

Умение оценивать сроки и выдерживать их

Умение общаться с людьми (коллегами, заказчиками, пользователями)

Умение четко и структурированно рассказывать о своей работе
50

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