Хенрик Книберг - Scrum и XP - заметки с передовой

Недавно мы начали практиковать его в одной из наших команд. Как ни удивительно, работает довольно-таки хорошо. Большинство других наших команд до сих пор не очень много программирует парно, однако, попробовав эту практику в одной из наших команд для нескольких спринтов, я вдохновился идеей внедрить парное программирование и в других командах.

Вот пока несколько выводов после применения парного программирования:

• Парное программирование действительно улучшает качество кода.

• Парное программирование действительно увеличивает сосредоточенность команды (например, когда напарник говорит: «Слушай, а эта штуковина точно нужна для этого спринта?»)

• Удивительно, но многие разработчики, которые выступают против парного программирования, на самом деле не практиковали его, однако раз попробовав — быстро понимают все преимущества.

• Парное программирование выматывает, так что не стоит заниматься им целый день.

• Частая смена пар даёт хороший результат.

• Парное программирование действительно способствует распространению знаний внутри команды, заметно ускоряя этот процесс.

• Некоторые люди чувствуют себя некомфортно, работая в парах. Не стоит избавляться от хорошего программиста, только потому, что ему не нравится парное программирование.

• Ревью кода — хорошая альтернатива парному программированию.

• У «штурмана» (человека, который не пишет код) должен также быть свой компьютер, но не для разработки, а для выполнения мелких задач, когда это необходимо — просмотра документации, если «водитель» (человек, который пишет код) запнулся и так далее.

• Не навязывайте парное программирование людям. Вдохновите их, дайте необходимые инструменты и позвольте самим дойти до этого.

Наконец-то! Разработка через тестирование для меня важнее, чем Scrum и XP вместе взятые. Можете отнять у меня дом, телевизор, собаку, но только попробуйте запретить использование TDD! Если вам не нравится TDD, тогда просто не подпускайте меня близко, иначе я всё равно привнесу его в проект втихую:)

Курс TDD за 10 секунд:

Разработка через тестирование означает, что вы сначала должны написать автоматизированный тест (который не проходит — прим. переводчика). После этого надо написать ровно столько кода, чтобы тест прошёл. Затем необходимо провести рефакторинг, в основном, чтобы улучшить читабельность кода и устранить дублирование. При необходимости повторить .

Несколько фактов о TDD:

• Разработка через тестирование — это непросто . На деле оказывается, что демонстрировать TDD программисту практически бесполезно — часто единственный действенный способ заразить его TDD заключается в следующем. Программиста надо обязать работать в паре с кем-то, кто в TDD хорош. Но как только программист вник в TDD, то он уже заражен серьезно и о разработке другим способом даже слышать не хочет.

• TDD оказывает глубокое положительное влияние на дизайн системы.

• Чтобы TDD стало приносить пользу в новом проекте, необходимо приложить немало усилий. Особенно много тратится на интеграционные тесты методом «черного ящика». Но эти усилия окупаются очень быстро .

• Потрать достаточно времени, но сделай так, чтобы писать тесты было просто . То есть надо получить необходимый инструментарий, обучить персонал, обеспечить создание правильных вспомогательных и базовых классов и т. д.

Мы используем следующие инструменты для разработки через тестирование:

• jUnit / httpUnit / jWebUnit. Мы присматриваемся к TestNG и Selenium.

• HSQLDB в качестве встроенной БД в памяти (in-memory) для тестовых целей.

• Jetty в качестве встроенного web-контейнера в памяти (in-memory) для тестовых целей.

• Cobertura для определения степени покрытия кода тестами.

• Spring framework для написания различных типов тестовых фикстур (в т. ч. с использованием моков (mock-object) и без, с внешней БД и БД в памяти (in-memory) и т. д.)

В наших наиболее сложных продуктах (с точки зрения TDD) у нас реализованы автоматизированные приёмочные тесты методом «черного ящика». Эти тесты загружают всю систему в память, включая базы данных и web-сервера, и взаимодействуют с системой только через внешние интерфейсы (например, через

HTTP).

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