Опыт применения

лучших практик

Денис Тучин

руководитель группы разработки ПО

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: DenisTuchin@gmail.com

Skype: Denis.Tuchin

Вебинары: IT-Webinars.LiveJournal.com