Инструменты, без которых нельзя обойтись — продолжение

Вторым действительно необходимым инструментом, без которого нельзя заниматься разработкой программ, является средство отслеживания ошибок aka багтрекер.

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

Ещё более удивительно, что так считают и сами программисты. Впрочем, Фредерик Брукс уже больше тридцати лет назад заявил, что оптимизм — это профессиональная болезнь программистов.

Этот оптимизм, в частности, является источником следующих безапелляционных утверждений:

• Багов в этой версии нет.
• Это не баг, это фича.
• Этот баг заполз случайно: менеджер отвлекал и мешал сосредоточиться.
• Баг будет исправлен через пять минут (включая перекур).
• Исправленный баг никогда не повторится (не зря же мы за ним две недели гонялись!)
• Это был последний баг (багов в этой версии нет).

  Что интересно, эти заявления повторяются от версии к версии. Оптимизм программистов неизлечим.

  Багтрекер
  

  Так зачем же необходим багтрекер? А необходим он для того, чтобы наше представление о состоянии программы было ближе к реальности. Я беру на себя смелость утверждать: если вы не используете багтрекер, то популяция критических багов, пожирающих изнутри вашу программу, будет непрерывно расти, пока не убьёт её окончательно.

  Назначение багтрекера, в общем-то, простое. После регистрации ошибки появляется шанс, что вы о ней уже не забудете, и в этом состоит его главная функция.

  Если в описании ошибки вы укажете, как её воспроизвести, то сэкономите программисту значительное время при поиске бага. Это, пожалуй, самая важная из дополнительных функций.

  Но этим список возможностей багтрекера, конечно, не ограничивается. По мере его использования у вас будет появляться всё больше и больше идей о том, как извлекать пользу из накапливаемой в его базе информации.

• Если багтрекер позволяет вести историю бага (а он должен позволять, иначе это не багтрекер), то программист может записывать в него свои идеи о возможных путях поиска ошибки и сохранять там же результаты своих исследований. (Что вы смеётесь? Честно, я знаю одного такого программиста! Ей-богу, не вру. Я сам так делаю. Иногда.)
• Если вы часто выпускаете версии с относительно небольшими доработками (как это делаем мы), то поле "Исправить в версии" позволит вам распланировать исправление ошибок на несколько версий вперёд.
• После накопления некоторой критической массы записей об обнаруженных ошибках у вас, возможно, появится идея классификации их причин, чтобы выявить слабые места процесса разработки. (Да, я знаю, что для приверженцев Agile слово "процесс" является ругательным. Но я пока не нашёл для него политкорректного синонима.)

  Я перечислил только те способы, которые использую сам. У вас наверняка появится множество других идей. Главное, чтобы ваш багтрекер позволял их реализовать.

  И вот здесь во весь рост встаёт вопрос: какой же багтрекер выбрать? Я не буду оригинальным и опять отвечу вам: не знаю. И тем самым соригинальничаю, потому что все остальные хором скажут: BugZilla. Хотя некоторые, возможно, порекомендуют Mantis.

  Я бы, может, присоединился к большинству, если бы смог установить эту багзиллу пять лет назад, когда вопрос выбора багтрекера стоял и передо мной. Но я смог сделать это только на прошлой неделе, уже просто из принципа.

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

  Хорошо, если у вас есть свой серверный чулан, в котором живёт собственный ручной системный администратор. Тогда эту работу можно поручить ему. У меня такого чулана не было, и мне пришлось пойти по самому простому пути. А именно, написать свой собственный движок багтрекера. (Кстати, на нём работает и этот сайт.)

  Движок с самого начала обеспечивал только две функции: регистрация бага и добавление комментариев к его описанию. Довольно много времени я потратил на выбор необходимых атрибутов, взяв в качестве образцов скриншоты популярных багтрекеров и силясь разобраться в различиях между всеми этими priority и severity, assigned to и belongs to и т. п. В конце концов плюнул и реализовал единственный атрибут "Статус". С двумя значениями: "Open" и "Closed". Но оставив при этом возможность добавления новых атрибутов по мере необходимости и руководствуясь принципом "прежде чем добавить информацию, подумай о том, кому и зачем она нужна".

  Этот подход полностью себя оправдал. Пару лет вообще не возникало необходимости в каких-то дополнительных атрибутах. Но когда число проектов и, соответственно, багов, выросло, стал вопрос о приоритетах исправления ошибок. Тогда я добавил атрибут "Важность".

  Потом мы приняли более формализованный подход к выпуску релизов, и в трекере появились поля "Принято к исправлению" и "Исправлено в версии".

  Самая свежая идея, которую я уже упоминал, — это классификация причин ошибок, анализ которых поможет выявить узкие места в разработке. На сегодняшний день эта классификация выглядит так:

• Неадекватность архитектуры
• Неопределённость требований
• Ошибка кодирования
• Недостаточность тестирования

  А вот и пример записи из нашего багтрекера.

  

  Конечно, программисты норовят не регистрировать ошибки в багтрекере. По той же причине, по которой они не любят помещать исходники в репозиторий: это не является программированием.

  Они, в общем-то, и не должны этого делать. Плохо, если они втягивают в это преступление тестировщиков или техническую поддержку, то есть тех, кто первым в команде узнаёт о баге, и для кого регистрация ошибки является прямой обязанностью. "Да чего там регистрировать, я уже всё исправил", — эта фраза звучит намного чаще, чем можно предположить. И наивные (или ленивые) суппортеры на неё часто ведутся. Вот за это нужно бить по рукам. Линейкой. Металлической. Вот такой.

  Бить по рукам нужно, конечно, тестировщиков и техническую поддержку, а не программиста. Руки программиста — это его главное орудие труда. Поэтому программиста нужно бить по голове. Шютка. (Мне можно, я сам программист.)