В одном из недавних комментариев Андрей написал о наболевшем:

И, наверное, документирование надо рассматривать как еще одну _невключаемую_обычно_ в план работ задачу.

“У нас нет времени писать юнит-тесты. Сделаете это потом”. Звучит знакомо, не правда ли? Попав в ситуацию дефицита времени, сложно бороться с искушением сэкономить время за счет юнит-тестов, ревью, документации, любой другой работы, которая вроде бы не обязательна для получения работающего кода. Что ж, многие и не борются с искушением, а смело срезают углы. Думаю, не надо объяснять, почему это плохая идея. На следующем же проекте, наученные горьким опытом, разработчики будут понимать истинную цену такой “экономии”.

Но что же делать, если сэкономить время на необходимых работах хочет ваш заказчик? Это гораздо более неприятная ситуация. В срыве сроков и плохом качестве виновата будет все равно ваша команда. Да и заказчики реже учатся на своих ошибках, чем разработчики.

Убедить типичного заказчика в необходимости юнит-тестов практически невозможно. Поэтому не стоит и пытаться этого делать. Хотите найти время на юнит-тесты, code review и документацию – сделайте эти задачами обязательными этапами разработки любой новой функции. И не говорите о них вашему руководству или заказчику. Никогда. Просто включайте дополнительное время в оценку трудоемкости разработки основных функций.

В статье “Секрет Айсберга” Джоэль Спольски приводит отличный пример на эту тему:

Когда клиент или нетехнический менеджер очень хочет принять участие в проекте, дайте ему несколько версий графического дизайна, чтобы они могли выбрать. Меняйте расположение некоторых вещей, изменяйте вид, шрифты, двигайте логотип, делайте его то больше, то меньше. Дайте им почувствовать себя важными, предоставляя возможность поиграть с малозначимыми вещами. В этом случае они не нанесут вреда срокам. Хороший дизайнер интерьера постоянно приносит эскизы клиенту и вещи, из которых он может выбрать. Но они никогда не обсуждают с клиентом расположение умывальника. Он находится рядом с канализационной трубой и не важно, чего хочет клиент. Нет смысла тратить время на обсуждения, где должен находится умывальник – он должен быть рядом с трубой, даже не начинайте разговор об этом; пусть клиенты изливают свои дизайнерские потуги делая какие-то безвредные вещи вроде изменения своего мнения 200 раз о том, нужно ли использовать для столешницы итальянский гранит или мексиканскую плитку, или норвежскую древесину.

Отличный совет. То же самое нужно делать с процессом разработки. Готовый код должен быть покрыт тестами, отрецензирован и документирован. Не важно чего хочет ваш руководитель или заказчик. Если он не эксперт по процессу разработки ПО, то у него нет права голоса.

Разумеется, будет непросто создать и поддерживать подобную ситуацию, а особенно не испортить при этом отношения со спонсором проекта (что гораздо опаснее, чем разрабатывать продукт без юнит-тестов). Но если вы менеджер проекта, то это, черт побери, ваша работа. Займитесь ей, а не пытайтесь выжать из программистов рекордную производительность.

Материалы по теме:

  • Перевод статьи Дэйва Томаса и Энди Ханта “Учимся любить юнит-тесты”. В ней, помимо прочего, авторы проехались катком по аргументу “У нас нет времени, чтобы писать тесты”