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

03.07.2008 19:36:57

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

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

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

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

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

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

    Багтрекер


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


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

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

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

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

  • Если вы часто выпускаете версии с относительно небольшими доработками (как это делаем мы), то поле "Исправить в версии" позволит вам распланировать исправление ошибок на несколько версий вперёд.

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

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

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

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

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

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

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

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

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

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

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



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

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

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






    Добавлено: 25.02.2009 19:26:19
    Добавил(а): Squisher
    Григорий, зашел из дома. Прямой доступ (на работе прокся стоит), куки включены, проблем с другими сайтами относительно их нет. Хеллоу робат!

    Добавлено: 24.02.2009 12:06:56
    Добавил(а): Greesha
    Hello robot выдаётся (по крайней мере, должно выдаваться) в том случае, если отключены cookies.

    С помощью дампа базы можно снять слепок текущей модели, при этом пропадает главное преимущество движка - гибкость. В общем, я пока не готов выкладывать его в публичный доступ.

    Но если интересны какие-то подробности - пишите на greesha@mail.ru.

    Добавлено: 24.02.2009 09:08:35
    Добавил(а): Squisher
    Выдавалась ошибка при попытке подписаться на РСС рассылку, а вот какая точно ошибка выдавалась уже не помню, потому как сейчас даже ссылки не осталось (вместо нее вроде бы написано "привет робот").

    >требуется масса ручной работы с базой MySQL

    Не совсем понятно какого рода работы, непосредственно специфическая настройка MySQL (производительность, доп-модули) или просто работа с данными (в последнем случае дамп базы вроде должен решать все проблемы)?

    Добавлено: 20.02.2009 20:26:35
    Добавил(а): Greesha
    Squisher, этот движок написал я сам, и он не очень удобен для сопровождения: чтобы настроить его, требуется масса ручной работы с базой MySQL. Пока он не соответствует минимальным требованиям ни OpenSource, ни тем более коммерческого продукта.

    Но я над ним постоянно работаю, сейчас он разросся до системы управления проектами, и мысль "довести его до ума и выложить" меня уже, конечно, посещала.

    А что не так с RSS? Я получаю извещения в ленту каждый раз, когда что-то сюда выкладываю. Только на комментарии RSS не распространяется (хотя можно прикрутить, но я не видел в этом необходимости).

    Добавлено: 19.02.2009 15:56:05
    Добавил(а): Squisher
    Григорий, а не было у Вас в планах выложить данный багтреккер для страждущщих?

    зы. подписка рсс как то не очень работает :(

    Добавлено: 10.07.2008 13:44:22
    Добавил(а): Илья
    "То есть вам нужно запастись трёхкилграммовым брикетом кофе, шаманским бубном и толстым каналом в интернет, чтобы быть в состоянии шарить по десяткам форумов в поисках ответов на неизбежные вопросы, возникающие в процессе установки, в то время как Perl качает бесконечный поток компонентов, без которых багзилла отказывается работать."

    ахаха, в точку. :) Очень знакомо. :)) Тоже из-за этого не смог поставить. :)

    Добавлено: 07.07.2008 11:01:07
    Добавил(а): Greesha
    Спасибо за спасибо. :)

    Движок, кстати, не дотестирован: не сохранял имя автора комментария. :(
    Тестирую исправление этим постом.

    Добавлено: 04.07.2008 17:58:06
    Добавил(а):
    Читаю и наслаждаюсь! ДА! Так оно и есть на самом деле! (у нас только статусов больше у багов)
    Отдельное спасибо за лаконичный дизайн и юмор :-)