Лучшие практики на практике
DESCRIPTION
Это обзор опыта применения лучших практик разработки программного обеспечения на разных проектах от госзаказов до видеоконференций в командах от 5 до 50 человек. В докладе будут описаны не только практики, но и то, как они применяются на реальных проектах и какие выгоды они действительно приносят. Видео: http://www.ustream.tv/recorded/22131704TRANSCRIPT
Опыт применения
лучших практик
Денис Тучин
руководитель группы разработки ПО
i-Sys
Об авторе
• Коммерческая разработка с 2004
• Применение best practices с 2006
• Внедрение best practices с 2009
• Agile evangelist с 2009
Работодатели и заказчики Agile консалтинг
Лучшие практики
• Система контроля версий• Итерации + демонстрации• Заказчик рядом• База знаний (Wiki)• Code review• Коллективное владение кодом• Модульное и интеграционное тестирования• Автоматизированная сборка и
непрерывная интеграция• Стандарты кодирования• Ретроспективы• Метафора системы
Система контроля версий
• Совместная работа с одним кодом
• Возможность определить, кто, когда и какие изменения внёс
• Хранение истории изменений и старого кода
• Возможность сравнить свой код с работающим
• Возможность более продуктивно поддерживать несколько версий продукта (ветки)
• Разграничение прав (чтение/запись)
Хорошие практики работы с системой контроля версий
Итерации + демонстрации
• Есть обратная связь от заказчика:
o то ли делаем, что нужно?
o так ли делаем как нужно?
• Заказчик видит, что мы всё-таки что-то делаем
• Можно брать $ с заказчика за реализованный функционал
• У заказчика есть возможность менять приоритеты и требования походу безболезненно для команды
Заказчик рядом
• Всегда можно задать вопросы по требованиям
• Показать какой-то критичный функционал до демонстрации
• Заказчик видит, что мы всё-таки что-то делаем :)
• Технические вопросы заказчику (субподряд)
* Рядом не обязательно, но желательно очно
База знаний (Wiki)• Решение типовых проблем
o При деплое ошибка «…»
o Неверная кодировка в HTTP request
• Решение нетривиальных проблем, возникавших >1 раза (в целом в команде)
• Описание работы самописных библиотек и фреймворков
• Лучшие практики использования сторонних библиотек
• Инструкции по развёртыванию и настройке…
Требования в Wiki
• Иерархическая структура
• Проще поиск информации по разделам
• Комменты o Вопросы (уточнение требований)
o Замечания: некорректность или конфликты
• Совместное редактированиеo Если несколько аналитиков
o Или если кросс-функциональная команда
• Оповещение об изменениях конкретного раздела требований
Матрица участников в Wiki
• Матрица компетенций участников проекта
o Java, BPEL, Тестирование, Банковский софт
• Матрица ответственности участников проекта
o Своевременность и актуальность требований
o Работоспособность тестового стеда
o План на итерацию…
• Информация по тому как нужно общаться с каждым из представителей заказчика *
* Стоит закрыть для заказчика этот раздел :)
Матрица участников в Wiki
Аудит кода (Code review)
• Опытные коллеги поправляют менее опытных
• Опытные коллеги учат, как правильно, менее опытных
• Коллеги находят баги и несовершенства у других в коде
• Review Board
o Оповещение о коде на проверку
o Выделение кода для добавления комментария и отправка письма автору
Review Board
Коллективное владение кодомБенефты
• Все знают, как работает система
• Более эффективная интеграция
• Каждый может подменить другогоo болезньo отпускo увольнениеo уход с проекта
• «Автоматический» аудит кода (code review)
• Каждый несёт ответственность за весь код
Коллективное владение кодомПринципы
• Каждый может вносить изменения в любую
часть программы
• За работоспособность кода несёт
ответственность последний, кто его изменял
• Если такового найти сложно,
работоспособность
восстанавливает «кто считает
себя более вежливым и
воспитанным»
Модульные тесты
• Обнаружение ошибок раньше и быстрее тестеров
• Возможность избежать поиска труднонаходимых
багов
• Контроль того, что кто-то постфактум внёс баги
(регрессии)
• Архитектура неизбежно приобретает большую
модульность
• Тестирование функционала происходит «с низу»,
что существенно упрощает интеграцию
Модульные тесты
Интеграционные тесты
* После модульного
+ Проверка, что разные модули/слои приложения правильно работают совместно
Системное тестирование:Автоматизированное тестирование UI
Автоматизированная сборка
• Компиляция исходного кода в бинарный код
• Сборка бинарного кода в приложение
• Выполнение тестов
• Разворачивание на testing и production платформы
Apache Maven
• Один скрипт для всех платформ: Win, Linux, Mac
• Один скрипт для всех целей *:
• Для разработчиков
• Для стенда тестирования
• Для Production версии
• Сервер непрерывной интеграции (Continuous Integration)
• Управлением версиями модулей системы и сторонних библиотек
• Нет необходимости дублирования библиотек
* Возможно сделать разные профили, для разных целей сборки
Sonatype Nexus
• Единый репозитарий артефактов
• Одинаковые библиотеки у всех:• у разработчиков• на стенде тестирования• в Production версии• на сервере непрерывной интеграции
• Храним самописные библиотеки в одном месте
• Не нужно каждый раз искать, где скачать
• Экономим трафик
• Решаем проблемы шаринга платных библиотек внутри компании
Непрерывная интеграция (CI)
• Быстро всем видно, если сборка упала и кто в этом виноват
• Автоматическое разворачивание для альфа-тестирования
• Возможность запускать ресурсоемкие тесты
• Возможность автоматического разворачивания на стенд разработки, если он общий
Стандарты кодирования
• Код однообразен
• Код более удобочитаем в целом
• Код обычно более документирован (Javadocs)
• Позволяет избежать досадных ошибок (типа if без скобок)
• Позволяет исключить неоптимальные практики
• Разработчики не тратят время холивары
Стандарты кодирования:Плагины к среде разработки
Даже если вы забыли все соглашения, плагин напомнит:
• Выделит цветом
• Предупредит перед комитом (check-in)
Стандарты кодирования:
Плагины к серверу CI
• Даже если у вас не включён плагин в IDE
• Continuous Integration (CI) сервер скажет вам всё, что он про вас думает :)
• Можно ввести рейтинг по комитерам:
• Количество удачных/неудачных сборок после комита
• Количество внесённых браков
• Количество исправленных браков
РетроспективыЦели
• Можно увидеть не очевидные проблемы
• Понять, что «безобидные вещи» являются существенными проблемами
• Предупредить назревающие конфликты
Формат
• Мозговой штурм
• Голосование
• План действий
РетроспективыЧто прошло хорошо/Что можно улучшить
• Проблема
• Голосов
• Что сделать?
• Кто?
• Когда?
Метафора системы
= +
• Все разработчики понимают систему одинаково
• Разработчики и заказчик говорят на одном языке
• Разработчики и тестировщики говорят на одном языке
Метафора системыПример
Метафора системыПример
Электронный кошелёк!
О чём не рассказал?
Test Driven Development (TDD)Разработка через тестирование
Planning Poker
Парное программирование
• Повышение дисциплины
• Лучший код
• Гибкий поток работы
• Высокий боевой дух
• Коллективное владение кодом
• Командный дух
• Высокое качество дизайна
• Обратная связь
• Непрерывный аудит кода
• Обучение
Рефакторинг
• Нужно добавить новую функцию, которая плохо укладывается в архитектуру
• Нужно исправить ошибку, причины возникновения которой сразу не ясны
• Сложная логика программы• Дублирование кода• Длинный метод• Большой класс• Много параметров в методе• «Завистливые» функции• Избыточные временные переменные• Классы данных
YAGNI Вам это не понадобится
• В 50% случаев код написанный про запас не используется вообще
• В 49% - дорабатывается или перерабатывается
40-часовая рабочая неделя
• Производительность разработчиков сильно падает, если они вынуждены работать подолгу.
• Падает настолько, что за 10 часов они начинают делать столько, сколько раньше делали за 6
60<40
* В сочетании с описанными практиками
*
Шаблоны проектирования(Design Patterns)
Так же почитать
• Слайдкаст «Ведение проектной документации IT-специалистами»
• Экстремальное программирование в Википедии
• Обзор методологии SCRUM
• Про каждую из практик в Википедии
Спасибо за внимание
Блог: IT-Improver.LiveJournal.com
E-mail: [email protected]
Skype: Denis.Tuchin
Вебинары: IT-Webinars.LiveJournal.com