Видео: http://www.youtube.com/watch?v=vz0U3jQpHSM Это обзор опыта применения лучших практик разработки программного обеспечения на разных проектах от госзаказов до видеоконференций в командах от 5 до 50 человек. В докладе будут описаны не только практики, но и то, как они применяются на реальных проектах и какие выгоды они действительно приносят.

1. Опыт применения
лучших практик
Денис Тучин
руководитель группы разработки ПО
i-Sys

2. Об авторе
• Коммерческая разработка с 2004
• Применение best practices с 2006
• Внедрение best practices с 2009
• Agile evangelist с 2009
Работодатели и заказчики Agile
консалтинг

3. Лучшие практики
• Система контроля версий
• Итерации + демонстрации
• Заказчик рядом
• База знаний (Wiki)
• Code review
• Коллективное владение кодом
• Модульное и интеграционное тестирования
• Автоматизированная сборка и
непрерывная интеграция
• Стандарты кодирования
• Ретроспективы
• Метафора системы

4. Система контроля версий
• Совместная работа с одним кодом
• Возможность определить, кто, когда и какие
изменения внѐс
• Хранение истории изменений и старого кода
• Возможность сравнить свой код с работающим
• Возможность более продуктивно поддерживать
несколько версий продукта (ветки)
• Разграничение прав (чтение/запись)

5. Хорошие практики работы
с системой контроля версий

6. Итерации + демонстрации
• Есть обратная связь от заказчика:
o то ли делаем, что нужно?
o так ли делаем как нужно?
• Заказчик видит, что мы всѐ-таки
что-то делаем
• Можно брать $ с заказчика за реализованный
функционал
• У заказчика есть возможность менять приоритеты
и требования походу безболезненно для команды

7. Заказчик рядом
• Всегда можно задать вопросы по требованиям
• Показать какой-то критичный функционал до
демонстрации
• Заказчик видит, что мы всѐ-таки что-то делаем :)
• Технические вопросы заказчику (субподряд)
* Рядом не обязательно, но желательно очно

8. База знаний (Wiki)
• Решение типовых проблем
o При деплое ошибка «…»
o Неверная кодировка в HTTP request
• Решение нетривиальных проблем,
возникавших >1 раза (в целом в команде)
• Описание работы самописных библиотек и
фреймворков
• Лучшие практики использования
сторонних библиотек
• Инструкции по развѐртыванию и настройке…

9. Требования в Wiki
• Иерархическая структура
• Проще поиск информации по разделам
• Комменты
o Вопросы (уточнение требований)
o Замечания: некорректность или конфликты
• Совместное редактирование
o Если несколько аналитиков
o Или если кросс-функциональная команда
• Оповещение об изменениях конкретного раздела
требований

10. Матрица участников в Wiki
• Матрица компетенций участников проекта
o Java, BPEL, Тестирование, Банковский софт
• Матрица ответственности участников проекта
o Своевременность и актуальность требований
o Работоспособность тестового стеда
o План на итерацию…
• Информация по тому как нужно общаться с
каждым из представителей заказчика *
* Стоит закрыть для заказчика этот раздел :)

11. Матрица участников в Wiki

12. Аудит кода (Code review)
• Опытные коллеги поправляют менее опытных
• Опытные коллеги учат, как правильно, менее
опытных
• Коллеги находят баги и несовершенства у других
в коде
• Review Board
o Оповещение о коде на проверку
o Выделение кода для добавления комментария и
отправка письма автору

13. Review
Board

14. Коллективное владение кодом
Бенефты
• Все знают, как работает система
• Более эффективная интеграция
• Каждый может подменить другого
o болезнь
o отпуск
o увольнение
o уход с проекта
• «Автоматический» аудит кода (code review)
• Каждый несѐт ответственность за весь код

15. Коллективное владение кодом
Принципы
• Каждый может вносить изменения в любую часть
программы
• За работоспособность кода несѐт ответственность
последний, кто его изменял
• Если такового найти сложно,
работоспособность
восстанавливает «кто считает
себя более вежливым и
воспитанным»

16. Модульные тесты
• Обнаружение ошибок раньше и быстрее тестеров
• Возможность избежать поиска труднонаходимых
багов
• Контроль того, что кто-то постфактум внѐс баги
(регрессии)
• Архитектура неизбежно приобретает большую
модульность
• Тестирование функционала происходит «с
низу», что существенно упрощает интеграцию

17. Модульные тесты

18. Интеграционные тесты
* После модульного
+ Проверка, что разные модули/слои приложения
правильно работают совместно

19. Системное тестирование:
Автоматизированное тестирование UI

20. Автоматизированная сборка
• Компиляция исходного кода в бинарный код
• Сборка бинарного кода в приложение
• Выполнение тестов
• Разворачивание на testing и production
платформы

21. Apache Maven
• Один скрипт для всех платформ: Win, Linux, Mac
• Один скрипт для всех целей *:
• Для разработчиков
• Для стенда тестирования
• Для Production версии
• Сервер непрерывной интеграции (Continuous Integration)
• Управлением версиями модулей системы и
сторонних библиотек
• Нет необходимости дублирования библиотек
* Возможно сделать разные профили, для разных целей сборки

22. Sonatype Nexus
• Единый репозитарий артефактов
• Одинаковые библиотеки у всех:
• у разработчиков
• на стенде тестирования
• в Production версии
• на сервере непрерывной интеграции
• Храним самописные библиотеки в одном месте
• Не нужно каждый раз искать, где скачать
• Экономим трафик
• Решаем проблемы шаринга платных библиотек
внутри компании

23. Непрерывная интеграция (CI)
• Быстро всем видно, если сборка упала и кто в
этом виноват
• Автоматическое разворачивание для
альфа-тестирования
• Возможность запускать ресурсоемкие тесты
• Возможность автоматического разворачивания
на стенд разработки, если он общий

24. Стандарты кодирования
• Код однообразен
• Код более удобочитаем в целом
• Код обычно более документирован (Javadocs)
• Позволяет избежать досадных ошибок
(типа if без скобок)
• Позволяет исключить неоптимальные практики
• Разработчики не тратят
время холивары

25. Стандарты кодирования:
Плагины к среде разработки
Даже если вы забыли все соглашения, плагин
напомнит:
• Выделит цветом
• Предупредит перед
комитом (check-in)

26. Стандарты кодирования:
Плагины к серверу CI
• Даже если у вас не включѐн плагин в IDE
• Continuous Integration (CI) сервер скажет вам
всѐ, что он про вас думает :)
• Можно ввести рейтинг по комитерам:
• Количество удачных/неудачных сборок после комита
• Количество внесѐнных браков
• Количество исправленных браков

27. Ретроспективы
Цели
• Можно увидеть не очевидные проблемы
• Понять, что «безобидные вещи» являются
существенными проблемами
• Предупредить назревающие конфликты
Формат
• Мозговой штурм
• Голосование
• План действий

28. Ретроспективы
Что прошло хорошо/Что можно улучшить
• Проблема
• Голосов
• Что сделать?
• Кто?
• Когда?

29. Метафора системы
= +
• Все разработчики понимают систему одинаково
• Разработчики и заказчик говорят на одном языке
• Разработчики и тестировщики говорят на одном
языке

30. Метафора системы
Пример

32. Метафора системы
Пример
Электронный кошелёк!

33. О чѐм не рассказал?

34. Test Driven Development (TDD)
Разработка через тестирование

35. Planning Poker

36. Парное программирование
• Повышение дисциплины
• Лучший код
• Гибкий поток работы
• Высокий боевой дух
• Коллективное владение кодом
• Командный дух
• Высокое качество дизайна
• Обратная связь
• Непрерывный аудит кода
• Обучение

37. Рефакторинг
• Нужно добавить новую функцию, которая плохо
укладывается в архитектуру
• Нужно исправить ошибку, причины возникновения
которой сразу не ясны
• Сложная логика программы
• Дублирование кода
• Длинный метод
• Большой класс
• Много параметров в методе
• «Завистливые» функции
• Избыточные временные переменные
• Классы данных

38. YAGNI
Вам это не понадобится
• В 50% случаев код написанный про запас не
используется вообще
• В 49% - дорабатывается или перерабатывается

39. 40-часовая рабочая неделя
• Производительность разработчиков сильно
падает, если они вынуждены работать подолгу.
• Падает настолько, что за 10 часов они начинают
делать столько, сколько раньше делали за 6
60<40 *
* В сочетании с описанными практиками

40. Шаблоны проектирования
(Design Patterns)

41. Так же почитать
• Слайдкаст «Ведение проектной документации IT-специалистами»
• Экстремальное программирование в Википедии
• Обзор методологии SCRUM
• Про каждую из практик в Википедии

42. Спасибо за внимание
Блог: IT-Improver.LiveJournal.com
E-mail: DenisTuchin@gmail.com
Skype: Denis.Tuchin
Вебинары: IT-Webinars.LiveJournal.com