Я часто задумываюсь о том, какая инженерная практика для меня самая важная и приносит больше всего пользы. В разное время я думал по-разному. Сейчас однозначно считаю, что это TDD (Test Driven Development). Этот подход к дизайну и разработке приложения дает возможность разрабатывать готовую функциональность гораздо быстрее. Меньше времени уходит на запуск самого приложения, отладку, поиск проблем, написание ненужного кода, построение решений на будущее и т.д.

Но еще важнее то, что TDD способствует внедрению других инженерных практик. Даже не способствует, а требует. Модульное тестирование применяется по умолчанию. Так как вы пишете много тестов, то вам нужно их регулярно запускать. И вы просто обязаны установить инструмент для CI (Continuous Integration) и начать им пользоваться. Небольшие законченные кусочки кода дают вам уверенность в коммите и вы начинаете следовать практике CI, интегрируя свой код как можно чаще. Вы натыкаетесь на участки кода, которые тяжело тестировать. И, чтобы написать тест, вам приходится рефакторить эти участки кода. Рефакторинг также является неотъемлемой частью самой практики TDD. Не все умеют хорошо работать по TDD. Поэтому вы обращаетесь к помощи коллег. Они помогают вам написать тесты и код (парное программирование), а потом просто просматривают ваш код (Code Review), чтобы убедиться в правильности применения TDD. Долго поработав по TDD, вы начинаете чувствовать себя некомфортно без тестов. Это толкает вас к переносу TDD на уровень выше и вы приходите к ATDD (Acceptance Test Driven Development) или BDD (Behavior Driven Development).

Вот и получается, что, следуя TDD, вы автоматически начинаете внедрять все остальные практики. Это своего рода ядро, которое со временем обрастает и превращается в целую инфраструктуру инженерных практик. Поэтому при подготовке программы тренингов для конференции XP Days Ukraine мы уделили большое внимание именно TDD. Мы пригласили опытных тренеров по нескольким наиболее популярным языкам программирования (Java, .NET, PHP), чтобы провести тренинги, затрагивая специфику языка и применяемых в нем инструментов. Это даст возможность участникам получить практический опыт применения TDD и начать внедрение этой полезной практики в своем проекте. Выбирайте наиболее подходящий тренинг, регистрируйтесь и повышайте свой уровень!

Мы долго вынашивали идею этого мероприятия и рады сообщить, что официально начали подготовку конференции XP Days Ukraine. Конференция XP Days Ukraine будет целиком посвящена Agile инженерным практикам. Это больше чем просто конференция. Планируется масштабное мероприятие длительностью в несколько дней, которое будет насыщено разнообразными тренингами, мастер-классами, встречами и докладами. Дата конференции еще точно не определена, но это будет точно первая половина декабря. Состоится мероприятие в Киеве.

В последнее время многие жалуются на Agile конференции за наличие докладов только по командным и управленческим практикам, лидерству, Scrum и отсутствию серьезных докладов, непосредственно касающихся разработки. Мы решили исправить эту несправедливость и сделать конференцию практической направленности. Тематика инженерных практик и подходов выбрана не случайно, ведь большую часть процесса разработки составляет именно написание кода. Методология XP (eXtreme Programming) предлагает набор инженерных практик, которые помогают делать качественные продукты быстро и с меньшими рисками.

Мы приложим максимум усилий для того, чтобы привезти на конференцию известных докладчиков и тренеров, которые стояли у истоков современных инженерных подходов. Это даст участникам возможность получить информацию из первых уст. Будут освещены основные инженерные практики: Unit Testing, TDD, Continuous Integration, BDD, Code Review, Refactoring, Acceptance Testing и другие. Также будут обсуждаться вопросы архитектуры в Agile проектах, борьбы с технической задолженностью (Technical Debt), взаимоотношений разработчиков и тестировщиков, а также многие другие проблемы современной разработки.

Регистрация еще не открыта, так как конференция находится на этапе подготовки. В ближайшее время откроется этап ранней регистрации. Количество участников конференции будет ограничено. Мы планируем собрать не более 500 человек. Это будут разработчики, тестировщики, лидеры команд, менеджеры и все остальные непосредственные участники процесса разработки. Каждый найдет для себя что-то интересное. Присоединяйтесь к нашей группе в LinkedIn, Facebook или Google Groups, где вы сможете получать последнюю информацию о конференции и принимать участие в обсуждениях по ее подготовке. Чтобы получать последние новости о конференции вы можете подписаться на RSS, email рассылку или следить за нами в Twitter.

Мы приглашаем докладчиков, имеющих большой практический опыт в применении Agile инженерных практик, принять участие в конференции. Если вы чувствуете в себе силы и желание поделиться опытом с другими, то присылайте нам свое предложение о выступлении. Предложения принимаются до 1 ноября. Мы также будем рады любым рекомендациям с вашей стороны по поводу докладчиков, которых вы бы хотели увидеть на конференции.

Мы приглашаем спонсоров помочь провести конференцию на высоком качественном уровне и сделать участие в конференции доступным для широкой аудитории. Также спонсорская помощь поможет пригласить известных докладчиков и сделать программу конференции более насыщенной. Если у вас есть желание стать спонсором конференции, то мы с радостью рассмотрим ваше предложение. Предусмотрены различные спонсорские пакеты.

Благодаря совместным усилиям Алименкова Николая и нашего нового тренера Ивана Мосева, мы рады представить вашему вниманию новый тренинг «TDD в PHP».

Test Driven Development (TDD) без сомнения является одной из наиболее полезных, но в то же время трудных для внедрения, инженерных практик. TDD предлагает писать тесты до того как реальный код появится в приложении, благодаря чему вы получаете лучший дизайн, больше фокусируетесь на функционале, имеете возможность проверить состояние своей работы и понять когда вы закончили. Но написание тестов перед кодом требует от разработчика изменения мышления и наличия большого опыта в тестировании.

Данный тренинг предназначен для PHP команд или индивидуальных PHP разработчиков. Он поможет вам понять преимущества внедрения TDD на вашем проекте, сложности и пути их преодоления. Тренинг посвящён использованию модульного тестирования для улучшения процесса проектирования и разработки приложений на PHP. Будут расcмотрены инструменты, которые применяются для тестирования в PHP, и весь технологический процесс разработки, непрерывной интеграции и поставки web-приложения на PHP на примере практического задания, которое будет разрабатываться в процессе тренинга. Также будут рассмотрены полезные практики и инструменты для облегчения работы по TDD.

Первый тренинг пройдет в Новосибирске 19 февраля, а следующий – в Киеве 18-19 марта. Регистрация уже открыта и продлится до 14 марта. Продолжительность тренинга 2 дня, стоимость участия – 1600 гривен (обеды включены). Торопитесь, максимальный размер группы – 10 участников!

Сегодня я хотел бы затронуть очень интересное и новое понятие – «задолженность по дефектам» (bug debt). Много разговоров ведется про другой вид задолженности – «техническую задолженность» (technical debt). Но они обе очень важны. Понимание этих терминов увеличивает шансы проекта на успех.

Дефекты в коде появляются по разным причинам: недопонимание требований, несовершенство технических инструментов, невнимательность или спешка, недостаток опыта или технических навыков, и так далее. Дефекты пагубно влияют на работу всей команды. Прежде всего, они требуют времени тестировщиков на нахождение, анализ и описание. Причем, так как чаще всего тестировщики работают через пользовательский интерфейс, а не напрямую с источником проблем (программным кодом), то затраченное время увеличивается в разы. Также, по мере нахождения, дефекты нужно исправлять. Этот процесс требует вовлечения разработчиков, которые тратят время на анализ, исправление и дополнительные активности по проверке и предотвращению дефекта в будущем. На этом все не заканчивается – тестировщикам необходимо проверить исправленный дефект и внести изменения в различные системы (система управления дефектами, система хранения тестовых сценариев и другие). Таким образом, каждый дефект стоит команде очень дорого. И чем позже он будет найден и исправлен, тем выше стоимость.

У дефектов есть еще одно интересное свойство. Если система не покрыта «сетью безопасности» в виде автоматизированных тестов, то исправление одних дефектов часто приводит к порождению других. И образуется замкнутый круг. Все больше и больше дефектов скапливается в системе, на их исправление не отводится времени, потому что нужно разрабатывать новую функциональность. Некоторые дефекты живут в системе очень давно и превращаются в ограничения. Благодаря таким ограничениям, разработчикам приходится идти на хитрости и во многих случаях вставлять костыли. Труднее всего тестировщикам, потому что им приходится анализировать зависимости между дефектами, расставлять приоритеты и мириться с их существованием. Мотивация всей команды падает и многие начинают поговаривать о полном переписывании системы.

В то же время, наличие открытых дефектов запускает в действие принцип «разбитых окон». Никто не задумывается при добавлении в систему очередного сомнительного кода – ведь и так уже куча дефектов. Этот же принцип распространяется и на архитектурные решения. И системе становится все хуже и хуже… А мы еще не коснулись таких проблем как наличие стабильной сборки системы, блокирующих дефектов, недовольство заказчика и конечных пользователей, а также многих других.

Agile принципы говорят нам о том, что продукт должен быть рабочим и именно это есть главная метрика прогресса. Одно из основных преимуществ Agile подходов – это предсказуемость. Но наличие дефектов сводит предсказуемость на нет, потому что найденные дефекты нужно исправлять, что сильно влияет на продуктивность команды, а значит и на результаты для заказчика. Как следствие, теряется доверие и начинает разваливаться процесс разработки.

Что же делать чтобы не допустить всего описанного? Главная задача – сфокусироваться на качестве кода, на предотвращении дефектов. Для этого, конечно же, тоже понадобится время. Начать можно с автоматизации сборки системы, потому что без этого шага тяжело будет выполнить другие. На рынке существует огромное количество инструментов для решения этой задачи (Ant, Maven, NAnt, MSBuild, Gradle и другие), выберите подходящий и вперед.

Вторым шагом является подключение и настройка статических анализаторов кода. Они помогут вам избежать многих ошибок, а также предоставят детальную статистику по состоянию вашего кода. Большая часть из таких анализаторов (FxCop, FindBugs, PMD, Sonar, JSLint и другие) очень просто установить и начать использовать. Я рекомендую изначально включать все возможные проверки, а по мере использования отключать или настраивать те, которые вам не подошли. Делать это нужно осознанно и централизованно, а не просто скрывать имеющиеся проблемы. Важным шагом является настройка работы с результатами анализа в IDE, так как это упрощает работу разработчиков.

Дальше необходимо позаботиться о том, чтобы сборки и анализ кода проходили регулярно и как можно чаще. Для этого вам понадобится Continuous Integration сервер. На данный момент существует множество бесплатных и платных решений (TeamCity, Bamboo, Hudson, CruiseControl и другие), есть из чего выбирать. На установку и начальную настройку у вас не уйдет много времени. По ходу использования вы расширите настройки, подключите необходимые модули и установите дополнительные приложения.

Теперь можно переходить к следующему шагу – созданию «сети безопасности». Начните писать модульные и интеграционные тесты. Лучший способ начать – это обязательно писать их для нового кода, а также для кода, в котором найден дефект или проводится изменение. Не стоит торопиться, добиться полного покрытия всего кода быстро вам не удастся. Так что нужно запастись терпением. Помните главное правило бойскаутов: «Когда вы покидаете место привала, вы должны постараться хоть как-то улучшить его». Точно также поступайте со своим кодом – старайтесь при каждом изменении хотя бы немного его улучшить. Тогда вы будете медленно и уверенно двигаться в сторону улучшения всего кода системы.

Следующий шаг направлен на контроль выполнения предыдущих шагов и поиск новых улучшений. Этот шаг предполагает внедрение практики Code Review. Эта практика помогает убедиться в том, что все необходимые действия над кодом выполнены успешно и он соответствует стандартам, принятым на проекте. Для того, чтобы внедрить эту практику, вам необходимо обсудить и принять список требований к коду (критерии готовности). Такой список должен составляться с участием всех членов команды. Пункты списка подлежат обязательному контролю, постарайтесь изменить процесс управления задачами так, чтобы было невозможно миновать стадию Code Review.

Теперь, когда вы приложили массу усилий для того, чтобы избежать дефектов, осталось совсем немного. Необходимо уменьшить цикл обработки дефекта. Для этого требуется уменьшить все циклы обратной связи. Тестировщики могут давать обратную связь на завершенные части работы разработчиков, как только они готовы. Размер итерации стоит сделать как можно меньше, чтобы заказчик мог давать обратную связь по законченной функциональности. Должно измениться отношение к дефектам. Дефект на свежую функциональность, найденный в итерации, должен быть исправлен как можно быстрее. Для этого можно использовать визуальные инструменты, чтобы избежать траты времени на «официальное» проведение дефекта через все системы контроля. Это не означает, что системы контроля не нужны. В конце итерации открытые дефекты обязательно заносятся в них, чтобы ими можно было управлять наряду с другими задачами. Для еще большей экономии времени стоит поменять коммуникационный протокол, используемый для дефектов. При нахождении нового дефекта тестировщик может записывать автоматизированный сценарий с помощью инструментов тестирования (TestComplete, QTP, Selenium, Watir и другие). Этот тест заменит разработчику многострочное описание дефекта и ускорит его работу. Описание же добавится по необходимости, если дефект не удастся быстро исправить.

Вот и все. Было не так уж трудно? Теперь ваши тестировщики начинают меньше времени тратить на дефекты, у них появляется время на тестирование методом свободного поиска, нахождение потенциальных улучшений для продукта, другие виды тестирования. Разработчики не занимаются бесконечными сессиями по исправлению дефектов, они занимаются реализацией новой функциональности. Ваш процесс разработки предсказуем и заказчики знают когда и что могут ожидать от вашей команды. Вы все довольны своими успехами и пользователи благодарны вам за продукт, в котором практически нет дефектов. Это миф? Нереально? А вы попробуйте…

Презентации «Kanban VS Scrum» от Алименкова Николая и «XP Injection» от Алименкова Николая и Алексея Солнцева опубликованы в разделе ресурсов.