Технологии разработки ПО

1,987 views

Published on

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

Published in: Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,987
On SlideShare
0
From Embeds
0
Number of Embeds
1,089
Actions
Shares
0
Downloads
15
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Технологии разработки ПО

  1. 1. Технологии разработки ПО Кривовязь Глеб 1
  2. 2. Мотивация Профессиональная разработка ≠ просто написание кода 2
  3. 3. Инфраструктура разработки 3
  4. 4. Основные проблемы  Как организовать совместную работу с кодом?  Как систематизировать задачи?  Где и в каком виде хранить всю информацию по проекту?  Как оформлять код?  Как создавать документацию?  Как контролировать качество кода?  … 4
  5. 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. 6. Системы контроля версий (VCS, Version Control Systems) 6
  7. 7. 7
  8. 8.  Создан в 2005 г. для оптимизации разработки ядра Linux  Построен по принципу файловой системы  Большинство операций – локальные и очень быстрые («the gods of speed have blessed Git with unworldly powers»  )  Идеально подходит для активной работы с ветками  Обладает всеми преимуществами распределенных систем 8
  9. 9.  Каждый commit – «слепок» файловой системы (snapshot)  Актуальные версии файлов хранятся целиком (blobs) 9
  10. 10.  Вся история разработки – граф commit’ов  Ветка (branch) = указатель на commit (41 байт!). HEAD – текущая ветка 10
  11. 11.  Находимся в ветке master 11
  12. 12.  Создаем ветку dev 12
  13. 13.  Делаем checkout ветки dev 13
  14. 14.  Делаем commit 14
  15. 15.  Возвращаемся в ветку master (делаем checkout) 15
  16. 16.  Делаем commit 16
  17. 17. http://git-scm.com/book 17
  18. 18. Системы трекинга задач и дефектов (Issue trackers)  Цель – организация задач, расстановка приоритетов  Issue – может быть task, bug, improvement и т.д.  Типичные характеристики issue: o Description o Reporter o Assignee o Project o Priority o Due date o … 18
  19. 19. Системы хранения знаний  Цель – хранение полезной информации по проекту: o o Описания алгоритмов o Отчеты o  Документация Планы Полезные возможности: o Поддержка версионности документов o Рассылка уведомлений об изменениях 19
  20. 20. Стандарты кодирования (Coding standards, style guildelines) vs 20
  21. 21. Стандарты кодирования (Coding standards, style guildelines)  Не важно какие, главное – чтобы были  Код 1 раз пишется, но 100 раз читается  Пример - Google C++ Style Guide http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml 21
  22. 22. Документирование кода   Ручное написание комментариев Системы автоматической генерации документации, например, Doxygen http://www.stack.nl/~dimitri/doxygen/index.html 22
  23. 23. Doxygen - пример Код: 23
  24. 24. Doxygen - пример HTML-документация (фрагмент): 24
  25. 25. Ревью кода (Code review) Цель – выявление дефектов и потенциальных проблем на как можно более ранней стадии, улучшение процесса разработки, контроль качества кода 25
  26. 26. Ревью кода (Code review) Возможны разные формы:  Формальные проверки  Неформальный контроль  Совместное программирование 26
  27. 27. Формальные ревью кода  Пример – Review Board http://www.reviewboard.org/ Review Board Repository Reviewed commit Initial commit Author Reviewer 27
  28. 28. Тестирование и контроль качества ПО 28
  29. 29. Основные проблемы     Как убедиться, что разрабатываемая система делает то, что должна? Как проверить, что исправления известных дефектов не породили новые? Как контролировать изменения характеристик работы системы в результате вносимых исправлений? … 29
  30. 30. Уровни тестирования Тестирование в процессе написания кода Модульное и интеграционное тестирование Регрессионные тесты Ручное тестирование 30
  31. 31. Модульное тестирование (Unit tests)  Цель – тестирование отдельных функций и компонентов системы, а также их взаимодействия (интеграционные тесты)  Тесты пишутся разработчиками  Для C++ - Google Test: http://code.google.com/p/googletest/  Иногда поддерживается на уровне языка 31
  32. 32. Модульное тестирование (Unit tests) Вопрос - какой это язык программирования? 32
  33. 33. Модульное тестирование (Unit tests) Язык D! http://dlang.org 33
  34. 34. Модульное тестирование (Unit tests) Пример (C++) 34
  35. 35. Test-Driven Development Идея – сначала пишем тест, потом реализуем функциональность 35
  36. 36. Test-Driven Development  Достоинства: o Требования прописываются заранее, а не «на ходу» o Ошибки выявляются на самом раннем этапе o Сильно упрощается рефакторинг o  Тесты служат полноценной документацией (например, в D это выведено на уровень языка) Критика: o o Написание теста не всегда тривиально При хорошем покрытии объем тестового кода сопоставим с объемом кода самой системы, а иногда и значительно превышает его 36
  37. 37. Регрессионное тестирование (Regression tests)  Цели: o o o Убедиться, что то, что работало, не сломалось Убедиться, что результат работы системы соответствует спецификации Контроль результатов работы алгоритмов, батч-тесты  Тесты создаются как разработчиками, так и тестерами  Могут быть как автоматическими, так и ручными 37
  38. 38. Непрерывная интеграция (Continuous integration) Идея – регулярная (непрерывная) сборка актуальной версии продукта и контроль изменений 38
  39. 39. Непрерывная интеграция (Continuous integration) Основные принципы:  Наличие единого репозитория кода  Полная автоматизация сборки  Каждая сборка должна подвергаться набору тестов  Регулярные небольшие commit’ы, не «ломающие» сборку   Легкий доступ к результатам каждой сборки (инсталляторы, отчеты и т.п.) Автоматическое развертывание 39
  40. 40. Организация процесса разработки 40
  41. 41. Основные проблемы  Какой методологии разработки придерживаться?  Как организовать процесс выпуска стабильного релиза?   Как обеспечить эффективную работу каждого члена команды и команды в целом? … 41
  42. 42. Методологии разработки ПО  Водопадная модель (waterfall model)  Спиральная модель (spiral model)  Итерационная модель (iterative model)  Гибкая разработка (agile development) 42
  43. 43. Водопадная модель Все спланировали – и реализовали 43
  44. 44. Спиральная модель Постепенное уточнение требований путем прототипирования, потом реализация 44
  45. 45. Итерационная модель Постепенное наращивание функциональности, итерация за итерацией 45
  46. 46. Гибкая разработка Целая философия, основанная на итерационной модели. Частые итерации (спринты), кросс-функциональные команды, работа в условиях постоянно меняющихся требований 46
  47. 47. Гибкая разработка Основные постулаты («Agile manifesto»): • Люди и взаимодействие важнее процессов и инструментов; • Работающий продукт важнее исчерпывающей документации; • Сотрудничество с заказчиком важнее согласования условий контракта; • Готовность к изменениям важнее следования первоначальному плану. Примеры: • SCRUM • Kanban • Extreme programming 47
  48. 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. Напоследок 49
  50. 50. Что отличает лучших разработчиков  Умение выдавать законченный результат  Кругозор o o o  Знание различных языков, инструментов и технологий Умение находить правильные подходы к возникающим задачам, использовать подходящие инструменты Стремление постоянно поддерживать свои знания в актуальном состоянии Понимание высокоуровневых целей и умение мыслить в терминах «business value»  Инициативность  Самостоятельность  Умение оценивать сроки и выдерживать их  Умение общаться с людьми (коллегами, заказчиками, пользователями)  Умение четко и структурированно рассказывать о своей работе 50
  51. 51. Удачной разработки! 51

×